Recently we had a great day at our HQ with Nasry Angel from Forrester discussing our Roadmap and Visions. During the discussion, we talked about different approaches to architecting software.
If you simplify it, you can categorize these approaches into two main categories.
Here it is all about The Expert, and an assumption that this solution will handle everything from here to eternity. Or perhaps with this expert aura it simply becomes too many features within one solution, and too few that dare to challenge the solution. In the 90s this was a popular way of approaching software architecture. Trying to build and capture THE Enterprise Model that would solve everything and with that false expert know-it-all notion this could be done. Meanwhile, the business had to wait while the experts sat down and did their analysis, and after that it was done. The only thing that now remained was for anybody or somebody to implement their flawless design and voilà the one model was built.
To quote Jimmy Nilsson on why this did not work on the 90s and why it will not work in the future either:
This approach often leads to a big on-premise monolithic design. Over time this will not scale with new creative ways of solving real business challenges, but more be a war for preserving a state and design that was built and invented during the analysis and the creation of THE Enterprise Model.
Here it is all about knowing that we do not know what the future holds, hence we need to approach our domain with that notion. Understanding and accepting that everything we add will create complexity, so being very aware of what type of business challenge we are solving is paramount. Because we know that the domain and business challenges will change many times during the lifetime of our design. If other or tangent business domain opportunities arise, look for other services or collaborations to solve it. This approach of moving forward in small steps and failing fast, but with tiny failures that quickly will lead to a path towards an efficient design. In hindsight, this path will look crisp and clear, but without these small failures it would have been impossible to find it.
This approach often leads to a SaaS-based design with Microservices as base architecture, which often gives more flexibility and more purpose-built features . This often fits better within an organization. Because of the natural state of a IT-landscape where a lot of different systems and services often needs to coexist. To assume that ONE system would solve this challenge in the most efficient way is not very realistic. If you on the other hand are working with modern service-based solutions, this will put you in a much greater position to be efficient in maximizing the effect of your investments.
A couple of weeks ago me and our CEO, Niclas Mollin returned from San Francisco after attending the great event SaaStr 2017. The reinforced insight we left with was that all inRiver customers deserve a modern approach to delivering software. We have, for a long time, believed in a Cloud Service Approach, but with that transition we had to go through a lot of changes. To get where we are now, we have “killed a lot of darlings” on the way. With this I mean things that were thought of as absolute musts in our solution, and could not be changed. As always with these situations, time and commitment will help you in finding an alternate route. In this change process, The Microservice architecture is something that has helped us in our ambition to ― together with our community ― create an easy-to-use and fast-to-scale SaaS approach. The feedback we have received is very positive, the agility we can provide and the speed of change our design offers is very appreciated by our customers.
Think big – Start small - Scale fast
Jimmy Ekbäck, Executive Vice President Products & Services, inRiver
I want to start with saying that this post contains a lot of technical and architectural thoughts around software design. This is a subject that I enjoy very much and therefore read a lot about. In this post I am going to give you an insight to how Microservices has help us as an organization but also how it enabled us to be quick and agile.
One important aspect of an organization is commitment and the consequences if you do not have the right commitment. If the implication of an action is hidden too many layers away from the one performing it, it will never create the right sense of urgency and you will never become an efficient organization.
A focus and a goal for any R&D team is to be productive and agile as we all know anything static in this world will go extinct. For us working with information logistics within the realms of marketing, we know everything changes very rapidly and our design needs to be able to do the same without us breaking anything. Our architecture stem from DDD (Domain Driven Design, Eric Evans), which means that we design everything around the business domain, instead of around functions like a database, persistence or other application layers. This for us is a better model for evolving and adding new features. With this mindset of changing often, quick and also moving to a new State-less mode (Cloud). We needed to break our architecture into more decoupled parts, to have less dependencies and not creating a big monolithic architecture, so for us it felt very natural to work with a Microservice model.
If you do not do this, you risk ending up with a big black box (monolith) where all new ideas get stopped because with every change needed/made everything has to be rebuilt from the ground. Even worse is if you build a black box all new ideas must be built by you and it is impossible to scale out and get help from a creative community with new features. This model will ultimately break under its own weight because it cannot be maintained over time (more on this topic….). For us thinking and working with a Microservice Architecture we can be more pragmatic and flexible in choosing where and how we want to add a new feature, because our community with thier great skill-set can solve some of these new feature requests. As our partners can replace a service, with their own built service and alter or extend the behavior of an operation. It will even be possible to implement service end-points where they have the power to build their own new UI on top of our services. For us this is a fantastic thing that the great inRiver community can be more involved in creating business value for our customers. A great example of this is our customer H&M that together with our partner Accenture will be using the Media Driver concept. They are storing all their media assets in a separate DAM (Adobe). For inRiver the assets will look as if they are still stored in inRiver and other services will continue to operate as if they were, this by just changing how our Asset Service is operating.
Two of my great inspirations when it comes to software designs, Martin Fowler from ThoughtWorks, in the same city Chicago as our North American HQ and Jimmy Nilsson from Factor 10, have both written inspirational and insightful pieces on this.
Martin Fowler´s Microservices - great post about what a Microservice Architecture is.
Jimmy Nilsson´s Chunk Cloud Computing - was written back in 2009 but to the point of what we are doing without calling it Microservices.
By adopting this style, our teams also became cross-functional, as everything is focused around a business domain and not a server operation or function. They now have full responsibility from the Database all the way up to the UI. This transfers knowledge in more natural way but also shares responsibility. The teams are responsible for what is actually executed all the way when a user is working with a released feature. We have even taken this one step further with inspiration from the above mentioned articles, with addition from one of my true house gods, Nassim Nicholas Taleb. If you are not careful when building a team, and not making sure everybody has "skin in the game", you will easily create an Agency problem, transferring risks. This they knew better in ancient times than we do now. The Code of Hammurabi is a well-preserved Babylonian law code of ancient Mesopotamia, dating back to about 1754 BC. It is one of the oldest deciphered writings of significant length in the world. One of the laws in this code states that if a house collapses and kills that first born of the family living in the house the first born of the builder must also be killed.
Now we have not taken it to this extremes, we settled with having the support within the R&D team, making sure that you are responsible and feel a sense of urgency all the way. If you are awakened 3:00 AM in the morning due to something you have written, you are more likely to not make the same mistake again because it has a direct impact on you and your sleep (well-being ;)).
One thing I would like to emphasize here at the end, if you are still reading, is that it is all the small decisions and actions made every day by individuals operating within a team that bring this to life and dictates what it is and what it will become – so from words to actions!
So a big thank you to a fantastic inRiver team and a great community!
-- Jimmy Ekbäck, CTO --