Composable architecture: how agile can one go?

The only way an organisation can successfully transition to a composable architecture, is when it’s fully aware of the ‘three layers’ that IT-systems are usually composed of.

These layers can be found in the IT-systems of most mature companies:

1. The outer layer is where you bring the customer journey to life. The lead time for change in this layer is generally two months, for example when you add a new screen to your app or a new integration to your ad network.

2. The middle layer covers all APIs and middleware used to connect a company’s internal and external applications and processes. The average lead time for significant change in this layer is ten months, which is effectively one full business year.

3. The inner layer consists of a company’s core systems such as its ERP or legacy application. The average lead time for structural change in this layer is around fifty months.

The three layers are subject to the so-called Core vs. Edge rule (2-10-50), which is often used as a reference for how quickly a company can transition to a composable architecture.

Do you want to start making your ERP or CRM composable in the next year? Then make sure that your ambition and what is realistically possible are well aligned.

As an organisation, your core systems determine how your business processes are set up and being run on a day-to-day basis. Making your true core processes composable only pays off when you serve a highly dynamic market – f.e. if you’re a logistics provider for webshops.

Organisations in a stable market, such as life insurance providers, benefit from having a composable architecture in the middle or outer layer, f.e. when they want to connect a new sales channel or implement new payment options. However, if you use the lead time expectations of one layer to make another layer composable, the transition will most likely fail or at least result in major disappointments.

The three processes that all tech teams need

Do you know which timeline expectations match with the parts of your IT landscape? And are you ready to accept them? Then the next step is to look at how an IT organisation works.

There are three processes that tech teams require to effectively implement a composable architecture:

• True Iterative Development as default: the ability to quickly develop and release MVPs has to become second nature. The only way to achieve this, and migrate to production with the simple press of a button, is via Kanban or agile working, (merciless) automation and rapid development. The skills required to do this are part of the outer layer that allows you to quickly make changes. True Iterative Development is less important in the middle layer, as you are obliged to inform external parties before you can make changes. Additionally, in the middle layer, you are dependent on other parts of your business that are connected with APIs, but also follow their own roadmap.

• Use collaboration tools: in order for teams to work together in the most optimal way, they have to understand the approaches and releases of others. By using open standards and tooling for workflows, wallboards and APIs, you can keep an overview at all times and make sure that there are no communication hiccups. Additionally, it’s also essential to make sure there are owners that facilitate and oversee the use and maintenance of the tools.

• Develop your integration capabilities: not only is it important to know how to integrate your systems, you also have to know how to bring the data from your systems together. If you opt to split up a system into multiple components/PBCs (packaged business capabilities), it will directly impact the 360-view you have of your clients and the analytics of the customer journey. Also, having the right knowledge and implementing data mesh like architectures will become super important.

The three processes mentioned above share the same basis: agile working with clear team responsibilities for each ‘component’. If your business processes are not agile yet, applying a composable architecture will be hard, as both agile and composable are needed in order for large organisations to make complex processes more flexible.

The four major advantages of composable
If your tech team or organisation meets the requirements of the above mentioned processes, only then can you truly benefit from the advantages of composable, as per Monika Sinha, VP Analyst at Garner. In the 2023 CIO Agenda, Sinha explains what these advantages are.

1. You will gain more flexibility either by dividing a system into multiple components or by building a system using multiple components. This approach to system structure will also make it easier to manage the system.

2. The so-called 'discoverability’ of all that is possible will improve when business capabilities are no longer hiding deep down in a large and monolithic system. With a composable approach, everyone can easily take a closer look at individual components and learn how to use their power. This also helps to prevent shadow IT, for example when stakeholders request the same customisation work for multiple systems to achieve similar goals, like a notification system for an ERP system and a HRM system respectively.

3. The ‘adaptability’ of your organisation will improve because of ‘orchestration’. Your organisation will be able to reach its goals in multiple ways, fitting with different lines of business. Also, by rethinking the connections between your individual processes, you can create unique services and customer experiences.

4. The teams on your platform that work at a different pace will gain more autonomy. Developers manage their own components, which allows them to work faster and more independently.

Evolution instead of revolution
Transitioning to composable allows your organisation to work faster and more flexible, but not necessarily across the entire board. Reducing the lead time for changing your core processes from fifty to twenty-four months is a massive change already. However, reducing the time it takes to build your customer journey by the same ratio, is not feasible.

The fixed ‘heartbeats’ that indicate the lead times for changes will speed up and gradually disappear. Standard release moments, alignment moments and financial years will lose their impact on the rhythm.

This clears the way for an ‘adaptive strategy’, in which you can adjust your strategy at the C-level during the year, to be implemented. Additionally, it also changes the traditional vision of IT being an expense to IT being a business driver.

This way, a high trust culture in which teams get more responsibility over their components can be cultivated. The focus shifts from a release calendar to partnering up and realising amazing things together.