Skip to content

The Product Manager's View on Composability

Composable Definition and MACH

Composability, also known as Composable solutions or Composable commerce, is a design principle in which individual components or services are modular, independent, and interoperable. It allows them to be easily combined, reused, or replaced to build complex systems.

We have a custom-built core product for software businesses, whether a monolith or a set of microservices. In addition, you (when I mention you, I mean a product, area, or organization) have several external integrations with different levels of complexity.

For non-software businesses, several vendors of different scales have some in-house solutions. Those businesses are the primary beneficiaries, as Composable is a way to eliminate vendor lock-in and gain more control while also being flexible enough to adapt to market changes.

Composable addresses the latter case by using "best-of-breed" components available, whether market or house-built and adapting them according to business requirements.

To build such a miraculous system, you need middleware that connects several headless subsystems via API and provides governance and data consistency.

That matches a MACH architecture style corresponding to:

  • Microservices,
  • API-first
  • Cloud-native
  • Headless.

Sometimes, Composable and MACH seem interchangeable, but the former, as mentioned already, is a software architecture style, and the latter is rather a business architecture. But those terms are tied together in the current agenda.

Recipe for Building a Composable Solution

A successful recipe for building a composable solution consists of:

  • vendor or internal systems that follow MACH and, ideally, are certified by MACH Alliance as truly MACH
  • the middleware to connect and operate them
  • UI layer for end-users, unless your business is providing an API

The paradox is that you need a custom-built middleware to connect multiple systems and maintain their interoperability. If you choose a ready-made platform from the market, you are again trapped in a vendor lock-in, as it becomes a bottleneck of your composable solution. So, to be puristic, you need to build such a middleware using open source only.

It is similar to the UI, which you need to build from scratch to provide a unified user experience. Although it is not trivial, building the composable layer is a real challenge with some high risks.

Bad news: your organization is likely to lack all the required expertise.

Good news: there are guys who can help you for some money.

Outcome: your organization probably get a composable system, considering some risks.

The Myth of Plug-and-Play

While on the vendor side, I've seen many times how product owners on the customer side struggle to learn the limits of a vendor system.

Learning and adopting a third-party system as your own is a time-consuming effort. After achieving that, there is still a risk that something will go wrong with a vendor: something will break, a vendor will be acquired by a bigger corporation, which will raise prices to compensate for a recent acquisition, and so on.

Composability mitigates those risks by considering vendor systems as easy to plug and unplug at any moment. If a vendor is MACH compliant, then changing a Packaged Business Component (PBC) should not have such an impact.

If we talk about interchanging several API endpoints, that is not a problem. If we are talking about migrating to another product with dozens or hundreds of APIs, its own data model, and business logic, there are no identical systems in the world.

The middleware needs to handle such friction to make the transition as smooth as possible.

There are two problems here:

(1) every migration is a high-risk challenge

(2) introducing complexity into the middleware

Those are manageable problems if you have people who know how to deal with them.

The remaining challenges are people who are slow to change (mentioned already) and vendor contracts.

Most vendors build their business models on upselling their products to achieve their ultimate goal: selling their entire suite (of something). Vendors love vendor lock-in. They want to put their customers on that needle and keep them there as long as possible. That is a part of their nature.

Enterprise vendors' attempts to "build open ecosystems" seem to be shooting themselves in the foot. The idea of Composability is lovely to customers, so vendors and system integrators are leveraging that as a new marketing weapon.

SaaS subscriptions may seem like a guarantee of a quick exit from one vendor to another. However, that walkout from larger enterprise vendors that provide critical business capabilities won't be easy, especially when you haven't had leverage while signing the agreement. There may be complicated contract terms, complex migration, and a lack of alternatives.

Composability in E-Commerce and Beyond

Composability took off in e-commerce, so it is sometimes referred to as Composable commerce. That industry has been on the edge of innovation for the last decades through various modular transformations. The coincidental rise of Clouds and Microservices created a pretext for raising a Composable business architecture.

Now, it spreads to different industries, which are more conservative, sometimes more regulated, and more change-resistant. Only time will tell how successful the adoption will be and whether it becomes a de facto standard.

Also, Composability got unlucky in clashing with AI rise, and that might be a reason if you hadn't known about that idea before reading this article. Composable and AI agents are not mutually exclusive and can co-exist. That is an approach that is promoted to keep it on track during the AI hype.

I might sound critical about Composable, but it is not actually true. I admit that it brings such complexity, which is not handled correctly, and can easily lead the system to disaster. I am fascinated by the complexity and challenges it comes with. But before you go in that direction, you need to know how to cook (a Walter White meme should be there).

Product Manager's Perspective

Let's return to the article title and discuss Composable from the Product Manager's perspective.

If you are a product manager, there can be two situations:

(1) you have a composable middleware that is your product. So, you are a Platform or Technical PM who needs to have a great knowledge of system integration: tools, patterns, and approaches. It is another discipline quite different from the startup PM we read about, and API Platform PM can also be used in that context. Still, Composable has a broader definition than an API Platform, so they are not interchangeable.

(2) more interesting for me to explore: when you manage a product or a product composed of multiple vendors and house-built components. I have never been in such a situation - with my Digital Experience Platform, I am near Case 1.

But let's do a mind experiment. There is a transformational stage where a product becomes composable. To my mind, it is similar to splitting a monolith into microservices and replacing the legacy.

Just by accident, I have a series of article about that.

Then, there is a relatively stable stage of operation followed by a migration phase in which one PBC is replaced with a better one. For the stable stage, if you have a new feature, the process will be different, whether an in-house built PBC or one coming from a vendor. That might become complicated when the new feature is split across several PBCs.

You may contradict that the system is not correctly split, then. I agree, but you can't decompose a monolithic structure perfectly and keep it stale forever.

The outcome might be building your customization over a vendor PBC using some extension point or just using the vendor's SDK. Alternatively, you can request the changes from the vendor. They can build some customization for additional money or promise to add the feature to a base product. That is the most unsafe option ever, as Composable implies fewer dependencies on the vendor and that is not the case here.

Again, just by accident, I have an article and a case study about managing dependencies.

Holistically, you end up with only two options:

(1) build customization over a vendor PBC and (2) switch PBC to another vendor, or (2.1) build PBC in-house.

If I could talk with someone who embraced Composable in their organization, I would ask:

"What is the threshold after which your organization decides to change a vendor?"

Option 2.1 is when you have the competency and resources to build PBCs in-house, which justifies some business-critical capability you can't delegate anymore.

Changing a small vendor is often a bureaucratic nightmare, and people are not usually happy to deal with it. So, tolerating some difficulties with existing vendors correlates with their size and criticality. Data portability and API contract changes are most prominent, but they are not the only obstacles on the way.

My thought here is that having a composable platform and MACH-compliant vendors is not enough if the entire organization continues to do business as usual. That requires a holistic transformation, and that is the biggest challenge of all.

Final Thoughts

For product managers, Composable requires an additional sidetrack: knowing the vendors you are utilizing in your product. I believe most of my fellow PMs already do this. Now, you need to keep an eye on rival vendors in their markets.

Suppose anything goes wrong with the current one. In that case, you need to quickly dive into competing proposals and be able to select wisely what your product requires with a focus on reliability and further development.

There is nothing worse than changing one shitty vendor to another shitty vendor, even if the cost of migration is not so high compared to traditional business architectures.

Although my article may criticize the concept of Composability, I am a fan of that approach, and I hope it will be adopted by many industries.

While working on implementing an insurance platform, I saw Carriers introduce advanced middleware to connect multiple vendors and custom software systems. But that was more modular than composable itself. Changing any of those vendors has a huge impact anyway.

So, that concept has a long road ahead. I will keep an eye on it, and hopefully, this is not the last article on the topic.

Take care

Continue reading about Composability