Composability is a Spectrum

What do we mean when we say, 'Is this architecture composable’?? In our community, we often find ourselves caught in the dichotomy of composable versus monolithic architectures. The problem with this thinking is that there is no architecture in the world that is purely composable or purely monolithic.? Composability exists on a spectrum. Not only that, there are many dimensions to this spectrum that you must consider before arriving at a suitable architecture for your organization. Here are some that I believe you need to think about.

Granularity of Packaged Capabilities

An ecommerce brand may have a commerce platform, a CMS, a PIM, CRM, ERP, CDP, Inventory Service, Pricing Engine, and so on. When defining capability, how granular should we go?? Should we consider ‘CMS’ a capability or one product with many capabilities? We can break a CMS down further into content management, content delivery, site builders and WYSIWYG, content operations and workflows, SEO and marketing tools, personalization, and A/B testing. So, when looking at how flexible/composable your architecture should be, is it enough to just replace the CMS with all its capabilities with another similar product, or should you start looking at replacing components of that CMS itself?

There is no simple answer to this question - the answer will always be, “it depends.” It depends on how much flexibility and specialization in each capability you really need. It may be sufficient to stick to your CMS for some of its core capabilities but bring in another specialized personalization tool or a site builder/experience manager if you have outgrown your CMS in some of the functional areas.

Digital Maturity and Buying from One Vendor vs. Several Vendors

Some people in our community argue that buying a set of capabilities from one vendor makes it inherently monolithic. I don’t think that is true unless each of the individual capabilities is entirely coupled and glued together, at the granularity that matters to you, and you’re unable to swap it out with another solution. As the enterprise gets more and more digitally mature, chances are that you’ll require more specialized/deeper functionality for each capability. However, smaller, less digitally mature brands will want to avoid the ‘swivel chair effect.’? For instance, smaller marketing and content teams may prefer to log into a single application to create/edit content as well as manage the experience on the web. So, less digitally sophisticated teams may want to go with a CMS (or DXP) that is providing many of the capabilities you need pre-integrated as that may be ‘good enough’ for your current as well as foreseeable needs.

Where and when do you need flexibility?

When making a decision about where to source each capability from, you must consider where in the stack you may need the flexibility along with practical considerations like budget, timelines, etc. Again, going back to the example of an ecommerce brand, an all-in-one Commerce platform may be able to provide all of your core commerce capabilities like product catalog, order management, checkout, sales and promotions, merchandising, customer service, and support, but you may not be satisfied with the CMS, Experience Management and Search capabilities and may want to source these from other specialized vendors.

Backend vs. Frontend Flexibility

One of the reasons for brands to think about moving to a 'composable' architecture is to offer more features and flexibility in your frontend experiences and to offer more channels and touch points for customers to engage with your brand. Many of the all-in-one DXPs and Commerce platforms come with highly templated pages and screens, which may not provide the flexibility to meet your needs. In this scenario, you need the freedom to be able to bring your own frontend framework, but you don't necessarily need to replace your commerce platform or your DXP. This is assuming, however, that the backend components offered by your all-in-one DXP or commerce platform exposes the APIs you need to give you enough granularity and control over the experiences you want to offer to your customers.

MACH Products vs. MACH Architecture

There is a sense in the community that the pro-MACH folks are pushing for organizations to create a 100% MACH certified architecture. First of all, MACH Alliance certifies products, not brands using those products. The alliance offers guidance and reference architectures, but by no stretch of the imagination does it certify your specific architecture. A brand could have an all-in-one DXPs and/or a Commerce Platform in their tech stack, and still want to add some of the MACH products such as Search, CMS, CDP, DXO, and so on.? It’s not an all-or-nothing deal!

Compostability

Yes, this is an intentional misspelling of the term. The point of composability is to give you the flexibility to extend your existing capability, to swap out vendors when needed, and do this faster than customizing or adding glue code to your existing applications. There are ways in which you can connect the MACH products together that completely go against the principles of composability. If you want true composability, you need to be able to take apart the capabilities (at the right level of granularity, of course), just as easily as you put them together.? This is compostability, and it requires creating an abstraction layer between your frontend and backend, but also between backend systems. You all know where I’m going with this one, so I’ll just add the shameless plug here for Conscia’s DXO.? If you want to know more about this, you’ll be able to find a lot more content on my linkedIn articles.

So, the one thing I hope you can take away from this article is that there is no silver bullet here and there is no use arguing about whether or not composability is important. The real question is how composable you want to be, where in your architecture it is important for you to be composable, and whether or not you are ready for the challenges it brings with it.