What do we mean when we say, ‘Is this product or 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.
Before diving deeper, let’s go back to what is ‘Composability’ and why it is important. If I were to put this in simple terms, composability is the freedom for brands and organizations to easily assemble a tech stack with the capabilities you need and swap out modules or components when you no longer meet your needs.
After all, who doesn’t want to have the flexibility to add, replace, or remove capabilities from their existing tech stacks? This sounds like a rhetorical question, doesn’t it? Well, let’s discuss what capabilities, packaged together or not, we want to replace.
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.
One Vendor vs. Several Vendors
Some people in our community think that buying a set of capabilities from one vendor makes it monolithic. I don’t think that is true unless each of the individual capabilities (at the granularity that matters to you) is completely coupled, and you’re unable to swap it out with a solution from another vendor. 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. In this case, you 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 and foreseeable needs.
Where in the overall architecture do you need flexibility?
When making a decision about where and how to source each capability, you must consider the current digital maturity level of your organization, the short and long-term flexibility you may need, and last, but not least, the 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.
Backend vs. Frontend Flexibility
One of the reasons for brands to think about a composable architecture is to offer more features and flexibility in your frontend experiences and to offer more channels and touchpoints 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 be sufficient to meet your needs. In this case, you need the freedom to be able to bring your own frontend framework. You don’t need to replace your commerce platform or your DXP as long as the APIs they offer give you enough granularity and control to build the experiences you need.
MACH ISVs 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 one or more all-in-one DXPs, Commerce Platforms, and still 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 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 if you are ready for the challenges it brings with it.Composability Unpacked: Moving Beyond the Monolithic vs. Composable Debate
Comments