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.

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 Mesopotaima, 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 --