from Michael Schlegel-Iten at
Perhaps you, as a business representative, are familiar with the following situation?
You have a simple requirement that needs to be implemented in the existing web shop. However, the feedback from your IT department is sobering: several dozen days of development are required for the implementation, not including testing. Moreover, the work can only be scheduled for next year at the earliest, as the team is still working on an upgrade of the web shop software from version X to Y. Unfortunately, this has turned out to be much more complicated than expected, but is urgently needed in order to close existing security gaps and avoid losing product support. And IT actually recommends not making this adjustment anyway: "never touch a running system". The result: frustration.
If the buzzwords currently being bandied about in the industry are to be believed, you would not have such problems with a "MACH architecture" or a "composable architecture". We at diselva are also staunch advocates of these approaches, but we also want to raise awareness of the fact that this topic needs to be viewed from different perspectives. In this blog post, we would like to discuss the specific advantages of these approaches and illustrate them with examples. However, we will also look at the other side of the coin and describe challenges and how to overcome them.
"MACH Architecture" & "Composable Commerce" - what do these terms actually mean?
The MACH Alliance (an association of various product, infrastructure and service providers) provides clear explanations in its article for readers with different levels of prior knowledge. For non-technical readers, the "Composable Architecture" approach is described as follows:
"[an approach] in which a large, complex problem is broken down into smaller, more manageable pieces. In the context of software architecture, composable architecture allows developers to create systems from smaller, reusable components that can be easily combined and reconfigured to meet the specific requirements of a particular project."
MACH is an acronym made up of the principles to be applied: Microservices, API first, Cloud Native and Headless. My colleague, Cuno, goes into more detail about these principles in his blog post and describes how to set up a composable commerce architecture.
From a business perspective, I'll try to summarise in simple terms:
Instead of a complex, monolithic system, the overall solution is divided into smaller, detached components. These components can be combined as required and expanded over time with additional components. The user interfaces are deliberately separated from the application logic so that different channels can be served with the same components or services.
What advantages does an organisation benefit from?
The approaches described are the answer to the frustration caused by situations like the one described at the beginning. These new approaches create a number of advantages.
The decoupling and use of suitable infrastructure and tools leads to more flexibility in the composition and expansion of the overall solution in various dimensions.
For example, a purchased SaaS commerce engine can be combined with a self-built application for price calculation. There is no need to make an either/or decision between "make" (build the complete commerce solution yourself) and "buy" (buy an expensive commerce engine that also covers more complex pricing models).
This flexibility leads to fewer dependencies than with large, complex and expensive monolith solutions, which often cause a lock-in effect through high licence fees and long-term contracts. Customers are also often dependent on the prioritisation of the provider's product roadmap when it comes to functionalities. Instead of waiting for the provider of the commerce engine to integrate personalised product recommendations into their own software, a corresponding, specialised service can be integrated into a composable architecture if required.
In addition, modularisation and decoupling increase the adaptability of the overall system. As functionalities are logically separated from each other, price calculation, for example, can be adjusted separately in the defined price service. Ideally, this will not change anything at the existing interfaces. And if it does, only the components that are actually connected need to be adapted. On the one hand, this significantly reduces the complexity and therefore the cost of such adjustments and, on the other hand, also enables a certain degree of parallelisation of the development work.
The use of cloud infrastructure in combination with functional decoupling also enables better scaling. Solutions can be built in such a way that, on the one hand, scaling up takes place automatically when required and, on the other hand, is targeted at those applications that need to process the actual load. On an online promotion day such as Black Friday, for example, all services related to the ordering process would be automatically adapted to the very high load in the meantime.
Last but not least, it is important to successfully prepare for the future. Because both analysts (such as Gartner) and the marketing departments of software providers agree: the market is developing in the direction of API-centred SaaS solutions that find their natural place in composable architectures.
What challenges need to be considered?
To summarise, the biggest challenge is to convert the advantages described into actual business benefits. Some of the aspects mentioned can also have negative effects if the wrong approach is taken.
The first step is always the hardest. Perhaps a truism, but nevertheless particularly pertinent to this topic. Even for composable architecture approaches, it is essential to first create a clear foundation before embarking on implementation. This can be achieved if an overview of the status quo is created at the beginning:
- Which systems are already in use, what functionalities do they offer and where are they in their product life cycle?
- Which business processes are mapped via these systems and where are the greatest levers for positive business effects?
- Which touchpoints are currently offered and where are there obstacles or gaps in order to offer a seamless customer journey?
- ...
On this basis, an overarching vision for the digital landscape should be developed in line with the corporate strategy, setting the direction for all subsequent initiatives. The aim is to formulate a holistic roadmap that maps out the necessary steps from the current to the target state in sensibly prioritised steps and expansion stages. My colleague Jörg Brunschwiler describes very clearly how this groundwork can be successfully mastered in this specialist article.
Once the vision and roadmap have been defined, the next challenge lies in planning and managing the project or programme. This is where some of the aforementioned advantages can also be seen in their negative guise. Flexibility, adaptability and parallelised work can quickly end in chaos. The following two aspects are therefore key to keeping complexities and dependencies under control.
On the one hand, it is important to have a project or programme organisation (depending on the scope of the project) that enables or even enforces overarching, content-related control of all activities. This is done in order to check at short intervals whether the shared vision is still valid and whether everyone involved is working in the same direction.
On the other hand, from a technical perspective, it is essential to organise ownership of the overall solution centrally. A large number of tools and services quickly come together, which significantly increases the complexity of the solution architecture compared to a monolithic approach. Depending on the size of the organisation, an individual or a committee should therefore manage the overall technical solution and be responsible for the expansion. What is important here is ongoing documentation of the overall picture, clear guidelines for implementation, rapid decision-making and active involvement in the expansion of the solution.
In order to tackle these issues successfully, many organisations need a change of mindset and attitude at all levels.
From a management perspective, it is important to understand that formulating a vision and adopting a roadmap is not the end of the story. There must be a willingness to critically scrutinise decisions made, adapt plans and thus continuously sharpen the target image. This is the only way to capitalise on the advantages of flexibility, independence and adaptability. With the attitude that you have formulated a 5-year strategy and only need to implement it, you would not be able to optimally utilise many of the advantages mentioned.
At project and programme management level, a strong focus should be placed on the content level. It may take some getting used to being actively involved in shaping the content instead of working through delivery objects and milestones defined from above. But here too, it is important to utilise the existing advantages in such a way that the greatest possible benefit can be achieved in the end. This requires constant and consistent prioritisation of requirements and daily work. The larger the company and / or the programme, the more important it is to manage these content-related dependencies in order to achieve a coordinated overall solution.
At the operational level in the individual projects and initiatives, close and interdisciplinary cooperation between all areas involved is essential in order to develop solutions that create the maximum benefit from the existing conditions. Requirements and the underlying business processes must be discussed, changed, implemented and tested together. Simply handing over artefacts (e.g. specialist concepts, technical concepts, etc.) to the next person or department would negate many of the described advantages of a composable architecture approach.
Last but not least, a new way of looking at costs is required. Both the initial and ongoing assessment of costs is more difficult than if you opt for an all-in-one strategy and purchase a product with fixed licence costs for several years due to the flexibility and modular expandability described above. Of course, a total cost of ownership calculation must always be carried out in each individual case. We would also not presume to make a global statement at this point that a composable architecture approach is always more favourable. However, there is no question that decision-makers and purchasers must accept variable infrastructure and licence costs in order to maximise the benefits in terms of needs-oriented scaling and modular expansion. This is a challenge in many organisations and for many people.
Time for a conclusion
No, the composable architecture approach is not a simple patent remedy or the well-known "silver bullet". This is demonstrated by the challenges described. Nevertheless, we believe that the advantages clearly outweigh the disadvantages. Especially as the risks can be identified and there are ways and approaches to overcome them. In addition, these challenging topics can be broken down into digestible morsels using a step-by-step approach and learnt step by step.
Although the mindset changes mentioned above are difficult to varying degrees depending on the individual starting position, they can be very well supported by programme-accompanying change management and individual or company-wide training measures. In our experience, if these topics are identified and supported by management at an early stage, this can have very positive effects on the entire organisation - even beyond the project and programme context.
We at diselva are happy to help you with our extensive experience in the development of composable architectures. Be it from a strategic perspective or from a technical point of view in the development of a new target architecture and its implementation. We can also offer our expertise in design and consulting as well as in project management to make your initiatives a success. Last but not least, we also know how to prepare an entire organisation for such paradigm shifts and develop it into a learning organisation.
Wir freuen uns auf Ihre Kontaktaufnahme!
Sources
Gartner - Composable Commerce Must Be Adopted for the Future of Applications
MACH Alliance - MACH at different levels
Jörg Brunschwiler - Digitale Transformation: Warum ist sie so schwierig?
