Why Lego Technic™ is the microservices architecture of toys
Like many bigger IT teams do, within the Jumbo Tech Campus we often talk about the development of our IT architecture. What parts do we want to develop ourselves, which parts would we like to develop in collaboration with our partners. And with whom do we want to do what. In my experience companies have a growth path when talking about technology, organisation and partnering. In the last 2 or 3 decades most companies have made steps in their development. Recognising those phases helps in defining where your IT currently is and what to do to improve it.
To illustrate the phases in which companies can be in their architecture and the relation with their partners, I made some pictures of toys of my daughter. They visualise the evolution of Lego, which , funny enough, nicely relate to the evolution of IT landscapes in many companies.
Phase 1, DIY software
Early in my career having a sourcing strategy for an IT team was simple. My team was part of the telecommunications company of the Netherlands, KPN. Because KPN had a monopoly on telephony, you could actually say we were “the” telecommunications company.
It was before 2000 and we were building the website and webshop for KPN, one of the first in the Netherlands. Many things were new and difficult, but one thing we didn’t need to spend a lot of time on was our build/buy decision. Should we buy a standard webshop and customise it to our own needs? Or should we build a platform ourselves?
The choice was quite simple, standard software for a webshop wasn’t available and therefore, we had to build it ourselves. Most companies did this, when they needed software, they had to specify the functionalities, make a functional and technical design and the software was specially built for that purpose. Often this was done in-house by a few developers in the technology they happened to know. This works fine as long as not too many processes within the company are automated; not too much functionality is required with enough money to invest in IT.
I promised to make a comparison with the toys. Historically toys were hand-made often from wood and every toy was made separately by a craftsman. With the advent of the industrial revolution, factories began to manufacture cheaper, standardized toys. The most famous example of this is probably the Lego factory in Denmark. This brings us to phase 2 in our journey, standardisation.
Phase 2, Standard products
Before phase 2 every company had to build its own IT. Building software solutions from the ground up can be valid, but needless to say it is expensive and risky as well. Also as the technology wasn’t evolved as it is nowadays, it was quite difficult to code in general. On top of that the majority of processes were actually not specific to the company that had to develop them. This caused a big gap for companies. The market could definitely benefit from shared solutions that just covered the basics, so their developers could focus on the processes that made these companies unique.
One of the most straightforward examples is accounting software. Innovative software companies started filling this gap. The business case of such a company was very simple, they made a software product which was flexible enough to support several types of companies and sold those software products to these companies. This was beneficial for all players in the market: the suppliers could sell their product and for the customers their IT product became cheaper. Most code only had to be built once and could be used by different players.
At this moment in time for most companies buy/build decisions were still rather simple. If it was possible to buy the software you needed and if it wasn’t available you had to build it yourself.
Phase 3, Customize, Customize, Customize
So far, so good. The ability to leverage standard products gave a great boost both to the toys market and to the technology market. For toys it resulted in increased sales and a lot of happy children. But at a certain moment the growth couldn’t only come from replacing hand-made toys by more standard ones anymore. So the toys industry started to innovate. This was done in many ways, Lego chose to customise toys. Duplo for little children, special puppets who looked like movie stars, special Lego for girls etc. Again this was a great success and the market kept growing.
The software vendors were in a great position in this market, a lot of companies were dependent on them for (parts of) their software landscape and they were willing to pay for extra functionality. So software companies started to customise their software for the different clients, making a lot of money while doing that. This collaboration led to specific solutions that made it increasingly hard to switch vendor. This vendor lock was evidently beneficial for the vendor since it added to the longevity of their contracts. This, however, led to the next problem.
Phase 4, Help! It is getting too complex
All these highly customised solutions managed by our vendors slowly but surely became more troublesome than could be seen upfront.
This way-of-working slowly put us in trouble. Both the IT Suppliers as their customers had to deal with more and more complex landscapes. Despite the innovations the information technologies went through, development cycles started slowing down instead of speeding up. Code became increasingly unmaintainable and many customised landscapes became so complex that it became impossible to innovate any further on top of them.
We had to solve this problem from a technological perspective, and we started layering and decoupling our software. We added services and later microservices to disentangle big monolithic solutions. And finally, we divided our software to logically clustered business domains and still support the expected functionality, data handling etc. Even though this sounds like a pure technical difference, we actually had to restructure our organisational model to make this transition possible.
Many technical challenges to make this transition can only be overcome when different technical disciplines work closely together. This was harder to do with a lot of outsourced work. So after years of outsourcing software, we started insourcing again. Good news for those among us who can code, since now every company wants you to work for them!
It’s hard to transition your organisational model when the majority of your proposition is outsourced. For the IT Suppliers, the urgency to move towards a microservices based architecture is low. Why would they invest in that? Going to a Service oriented architecture (SOA) has an initial complexity boundary to overcome, which many aren’t willing to take. Many vendors value rigidness over flexibility, because the vendor lock made them so much money earlier.
I believe many bigger (Dutch?) companies are nowadays in phase 4. Parts of our technological landscape are improving from an architectural perspective, but outsourced parts remain poor and hard to maintain.
Phase 5, the future
Finally, I believe, all enterprise software will convert to an architecture with isolation per business domain on a relatively fine granularity. I also believe this will take a while, like a lot of changes in IT take a while. Think about the mainframes that are outdated for many years and some of them are still running. Fortunately, you can do a lot to speed this process up by smartly organising your IT. Don’t wait for your suppliers to change their software, start building parts yourself. While doing that, try to implement best of breed, single purpose, well designed standard software wherever applicable. Preferably open-source, for which the developer base and longevity of the solution is bigger than for proprietary software. This means that you need less specific knowledge, easier recruiting, quicker security patches and longer community support. And I believe that this will bring you results in the short/mid-term. Well, at least it did for us within the Jumbo Tech Campus.
Going back to our Lego analogy, besides all the customising, Lego also innovated by developing Lego Technic. This also made it possible to make cooler toys that have more functionality than the original Lego bricks. But since Lego Technic is again based on small parts, that just could do more, it is very possible to make many toys with the same bricks. Making it the microservices solution of Lego.
Hope this story helps you with thinking about your own landscape, feel free to pay us a visit in Silicon Veghel :)
