Composable architecture: What, why, and when?

Like many industries, the world of digital experiences is no stranger to convoluted technical jargon and buzzwords. Terms like “WCM”, “DXP”, “monolithic”, “API”, “headless”, and “microservices” have emerged during the decades—and now a new term enters the domain of CMS, web apps, and several other niches: “composable”.

What is it? Why does it matter to your industry and organization? Should you adopt it or not? What does it solve? And what are the challenges associated with “composable architecture”?

What is composable architecture?

Composable architecture is an old idea from another niche now being applied to CMS. Common principles from IT—like service oriented architecture (SOA) and APIs—have steadily moved from back-end to front-end. In the past, organizations wanted to control everything within their on premise networks and application back-ends, but not anymore.

The rise of modern front-end frameworks, together with web APIs and microservices, has led to the influx of SaaS solutions and increased tech democratization. This has again made it easier to build complex solutions without the use of low level integrations and coding.

It is in this context—of leaving the complexity of moving parts behind—that composable architecture moves in to assume the mantle. Driven by modern API and SaaS trends, composable architecture enables organizations to build richer, better, and more robust digital experiences faster and with less effort—compared to using traditional stack approaches.

Composable shifts the focus from monolithic software suites and hosting to the following: Your organization instead chooses the best of breed solutions from a variety of online services and platforms. All this boils down to APIs—changing focus from infrastructure to an API-first approach.

There is even a formal association advocating the composable approach, in the guise of the MACH Alliance—wherein “MACH” is an acronym for “Microservices based, API-first, Cloud-native SaaS and Headless”.

In their own words, “enterprise suites are no longer “the safer choice.” The MACH ecosystem is. It is agile and nimble, always up to date.” The Alliance thus wants to “future proof enterprise technology and propel current and future digital experiences.”

As for composable, they identify it as an architecture “in which every component is pluggable, scalable, replaceable, and can be continuously improved through agile development to meet evolving business requirements.”

See also: How a digital experience cloud can lift your business »

Why use composable architecture?

Just like a modern skyscraper, you do not use the same material throughout the entire structure. You use concrete for foundation, steel alloys for support, glass for windows, and polished stone for surface. Not to mention all the timbers, aluminums, plasterboards, and other materials for the interiors.

In the same way, and for the same reasons, you should not use only one material—one system—for building your digital experiences. Due to rapid technological innovation and likewise rapid consumer behavior patterns in our omnichannel age, an inflexible monolithic suite simply does not cut it.

Today, most forward-thinking organizations build modern solutions with rich web experiences, putting the solution and the user experience at center stage—which was previously occupied by a zeal for technology.

According to Uniform, Gartner, Inc. predicts that by 2023, organizations that have adopted an intelligent composable approach will implement new features 80% faster than their competitors who have adopted a suite or a bespoke approach.

80% faster is quite a number. In addition to vastly improved agility and speed, composable offers a welcome separation of concerns. Now front-end developers can focus on the UX, and separate teams can take advantage of that good, ole’ division of labor to get things done. It will thus be easier to both upgrade and scale different bits and parts—without involving other specialists every time.

See also: Microservices: What does it mean for your digital project success?

Separation of content and presentation is a natural part of composable architecture. As mentioned, omnichannel is a driver behind composable, as consumers—your readers, visitors, clients, customers, and ambassadors—tend to be everywhere. Long gone are the tidy days of clear-cut channels. Now people are on the smartphone while working on the laptop, when the wearable gives them health advice and the latest news from the stock market.

What do you think caters best to this scenario? A monolithic DXP suite or a flexible, best of breed solution?

Take modern eCommerce for instance. Online stores do not put all their eggs in one basket, instead they often opt in for third-party services—like Klarna for smooth checkouts. Headless CMS is another obvious example of composable.

The core idea is that you build your solution with several parts, best of breed from all their respective niches—whether that is CMS, eCommerce, analytics, front-end framework, CRM, or marketing automation, ad infinitum.

When should you use composable architecture?

Even though composable architecture has been presented with all the bells and whistles, the case of whether or not your organization should adopt such a system is not straightforward. So, when should you use composable?

In addition to being on the lookout for all the advantages listed above, if your organization wants to build customer-tailored digital experiences, a variant of composable architecture is most likely best suited for the purpose.

Also, you and your organization’s stakeholders must ask yourselves the following question: Which parts of the moving machinery should you acquire as services in the SaaS fashion, and which should you take fuller responsibility for and build yourselves?

Furthermore, when should you not use a composable architecture? If you only want a simple website or a blog, such a setup is overkill. If you want a ready-made solution out of the box, and if such a solution fulfilling your requirements exists, then great! No need for composable.

See also: The future of CMS »

Challenges with composable architecture

Nothing in this world comes without both pros and cons, and composable is no exception. One chief challenge with the approach is security. For instance, in regard to GDPR: how much and what data is shared with what vendor in your potential “patchwork” solution?

Also, the risk of hacking is greater when you are using many different systems, meaning parts of the solution can be breached individually. You are no stronger than your weakest link, so ensure to build a solution that can handle one failure among several factors. For example, if a check-out solution consists of four factors, it should still be operational even if one of these fails or gets hacked.

See also: Composable architecture: Using the CMS as your director »

As for administration, with multiple vendors there will of course be an equal amount of deals and contracts—which can in the worst case add to red tape and headaches for you and your organization. Make sure you minimize the number of vendors, in accordance with what your teams can handle.

The individual products you use to build your composable solution are, of course, of immense importance. Take headless CMSs, for instance. Due to weaknesses in several headless systems, content editors lose the control they have been previously accustomed to. Much of the functionality has been moved to the developers’ table, or has been hard coded into the solution—leaving the editors frustrated or even enraged.

How you integrate your CMS with your front-end framework is one of the key factors for flexibility for both editors and developers, so choose your CMS, frameworks and other composable components wisely.

***

To sum it all up: Despite the caveats, the overall advantages of composable architecture makes it the most likely approach more and more organizations will take in order to meet the omnichannel reality head-on.