Composable Architecture – a risky investment?

Composable Architecture is a term that's seeing broad adoption in the IT industry, especially in web development. From what I can see and hear in the industry, many – if not most – new projects are "composable" in some shape or form. Composing websites using multiple different data sources and tools is not new, and I regard Composable Architecture more as a consequence than as a new invention. But it's not always that everything runs smoothly in composable projects and stories about overruns in both budget and time are not uncommon. In this blog post, I first want to look into the reason why composability is gaining traction and secondly why composable projects are a risky investment – at least according to me... :)

The attractions of composability

Composable Architecture is gaining traction because it appeals to both technologists and business professionals. Technologists are drawn to it because it presents an interesting technical challenge, while business leaders are eager for any approach that promises better business outcomes – especially if it's at a lower investment. However, to be honest, interesting technical challenges and lower investments don’t usually go hand in hand.

You may interpret the above tension between technical challenges and investment size as a critique of Composable Architecture, but that’s not the intention. This is about the business case. A large investment in solving an interesting technical problem can lead to a positive return on investment. In fact, in some cases the potential of a high reward is the reason for making a high-risk investment. However, I will advice most companies to reconsider before making a risky bet on technology investments – and I'll return to why composable is risky later in this post.

The push towards Composable Architecture is driven by two main arguments. First, the best of breed argument. Every organisation is slightly different, and being able to choose exactly the right tool for the right job might just give you a competitive advantage.

Read more about this trend 👉 The middle layer is the new playing field.

Secondly, the proponents of Composable Architecture argue that it's a prerequisite for business agility, as composability allows for greater flexibility in the IT stack, enabling the business to adapt to changes in the environment.

Both arguments are 100% valid, and what business in its right mind wouldn’t opt for the best tools and optimise for business agility?

Why is Composable Architecture a risky investment?

Even though the arguments for composable are plentiful, I wonder if businesses know what they are signing up for. Do they fully grasp the high level of technical and organisational maturity required, as well as the long-term commitment needed for investing in a composable setup? You should never underestimate how difficult it is to get multiple discrete IT systems to work together and deliver a coherent customer experience. It's not uncommon to see 4-6 discrete systems in medium-sized ecommerce web development projects, including:

• ERP
• PIM
• CMS
• Search and recommendation
• Commerce engine
• Email marketing

And this is before you even start considering the actual frontends, such as the website that customers will interact with.

A typical scenario in many businesses looks like this: The ERP system is usually not open to change – even upgrading it is beyond the reach of many companies. They also work with a "legacy" CMS, which is often used as both a PIM and commerce engine – and perhaps the CMS is nearing an "end of life" phase. Most ecommerce solution architects would advise against reinventing the wheel or building anything from scratch.

So, what do you do?

You begin by picking the best tools for each category and writing a lot of code to get all those discrete systems working together. The question is whether you’re now in a better or worse position than before?

Writing code always comes with risks. The initial risk is that it might be more complicated than originally estimated. It is a well established fact that many software development projects become more complicated than initially estimated. And even when you complete the initial project, you’ve also taken on the responsibility of operating and maintaining the software through its entire lifespan 😬

The maintenance phase is often just as costly as the initial project – it’s longer, of course, but you never know what challenges might arise from personnel changes, updates to dependencies, or shifts in business requirements.

But wait – didn’t you say that changes in business requirements are exactly what Composable Architecture is meant to address? Yes, that’s the idea. But in the real world, you use code to integrate all these different systems. If you need to replace one tool due to changes in business requirements, you either need to find a system that adheres to the already established contracts, or write more code to make the new tools integrate with the others. In practice, the promise of being able to swap out tools as business requirements evolve is a mirage.

Want to know about the role of URLs in a composable world?

Is Composable Architecture bad?

The principles of Composable Architecture are solid, and, in my view, very sound advice to follow. But it’s not a silver bullet – you will almost certainly not achieve faster or cheaper results. In fact, it might be slower and more expensive. However, the one clear advantage is that you can keep the working pieces of technology landscape and exchange the parts that are not working – without having to re-platform every 3-4 years.

Our advice for anyone venturing into the composable architecture world is to write as little code as possible and minimise the operational responsibility. Only this way will you avoid the main risks associated with any software development project.

If you're curious to read about other companies' experiences with building a composable stack, check out this customer case 👉 Data from multiple sources in one view.