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 --
I want to start with a warning: this post contains a lot of technical and conceptual thoughts around information logistics and how to be less exposed to unknown risks when implementing a technical platform. If you still are reading, let me start by giving this some context to elaborate.
You as an organization have tried to communicate a digital offering to the market. You know that it is a big challenge to organize your customer touchpoints (Channels, eCommerce stores, mCommerce, and catalog). It is a relatively straightforward thought process to decide on colors and strategies for achieving a great customer experience on paper, because these are all very visible challenges. But to generate the content that will create the story of your products, and get it out to all customer touchpoints with consistency is very hard over time. However, this content is the foundation for giving your customer that great experience. The information you want to get out to your channels must be rich in content to tell an inspiring story around your products. This is basic information logistics.
There are three basic rules when working with information logistics and moving product information across channels in an efficient way:
These are all contradictory rules, which is why it is a challenge to keep a consistent and inspiring story around your products in all customer touchpoints over time. The challenge is to know where to draw the line; you must know what information is needed for generating a great customer experience, but you must also know where the line for flexibility and adaptability to all customer touchpoints goes.
Here I would like to stop and highlight inRiver´s fantastic partner community with well over 600 certified consultants from the inRiver Academy. With the skill, knowledge and ingenuity that this community has acquired, combined with the way inRiver is architected, we have a very good recipe for creating and building flexible and agile solutions for our customers. This is something we believe makes us very strong: our community.
If we take a look at a specific area where this mix of Community & inRiver Architecture is very useful, it is in the decision-making process where a business challenge is addressed. Should this challenge be addressed within the platform, or should it be addressed in the framework around the platform? Obviously there are a lot of answers to this question, but these arguments can be made:
One area where this is truer than others is information logistics, where information travels in and out of different domain models. More often than not, these models change in either format or the information they require to perform.
So when information is onboarded to a platform, the information arrives as data in a specific format. When it is released, it goes out as enriched information, with more data in a new format. To excel at this, it must be easy to add new fields, or new content - but also easy to adjust the format of the data structure when building a solution.
When making a platform choice, I believe you should seek to minimize your exposure to risk, and maximize the gains (create better product stories and customer experiences) for your organization. We all know that implementing a large platform is always tightly linked with corresponding large risks. You can never have 100% control over the risks involved when implementing new platforms, but by choosing an agile, purpose-built, best-of-breed platform, you will probably minimize your exposure to unknown risks when moving forward.
-- Jimmy Ekbäck, CTO --
On our inRiver PIM platform, the PXM (Product Experience Management) concept ties into one of the best illustrative images I have seen on marketing technologies. The image, made by Gartner, shows all emerging marketing technologies in the form of a subway map. In order to get this whole ecosystem of marketing technologies to work, they need one repository for marketing content and one story. This is where the inRiver PXM concept fits in – working as the center of all marketing technologies as a Dynamic Marketing Hub.
What I have been told over the years is that our customers find it hard to choose a platform that will help them benefit from all these emerging marketing technologies, and knowing that the choice will not lock them up in a rigid platform with nowhere to go after the initial implementation. With a complex ecosystem of new marketing technologies, it is important to be antifragile in your choices. The concept comes from the fantastic book “Antifragile” by Nassim Nicholas Taleb, where he describes things that benefits from disorder and thrive on optionality (benefiting from more than one outcome), amongst other topics.
At one point, when I had the time and the pleasure of reading this book, I was inspired to do a thought experiment with time, since time is the ultimate judge of what will work and what will fail. This is always revealed by time. If you look at time in a simplistic way of past, present and the future, you can go back five years in time to look at some ideas and predictions that were made then and there. For example, take the economic analysts giving stock market advice, or the technology experts giving predictions on the world domination of some technology or company. When you heard about these predictions then and there, they most likely made sense. But with the time perspective on your side, you see a whole other story being revealed. Almost all of these predictions are precisely what they are: predictions. Some were lucky and got it right, but almost all of them failed.
Adapting to changes in the market instead of trying to foresee all eventualities becomes a necessity when dealing with change. If you can adapt in real time, rather than trying to react to changes after they have happened, you have a far more powerful set of options on how to move ahead with your marketing strategies.
What we are trying to achieve, is to make your organization’s investment in a marketing platform antifragile by using inRiver’s agile Marketing Model. This will enable you to easily adapt to the changes in the market, since you can adapt and change the Marketing Model easily to suit new requirements and new ways of telling the story about your products.
An important point is also that it also gives you the possibility to capitalize on the available options in the market at a low cost. If you have no options left, and must make major changes to keep up with the demands in the market, everything becomes quickly significantly more expensive.
So when you scope and plan your journey to tell the story of your products, make sure you are on a platform that will support you in this mindset:
Think big, start small, scale fast.
-- Jimmy Ekbäck, CTO --