Uniform blog/Which digital experience architecture is right for your business?
lars birkholm petersen
Lars Birkholm Petersen
Posted on Feb 1, 2023

8 min read

Which digital experience architecture is right for your business?

Monolithic, headless, MACH, composable, oh my! The past couple of years have seen a resurgence of spending by brands in digital-experience technologies. From the impact of COVID to the uncertainty in markets, brands have been seeking to raise the value of their digital properties, specifically in agility, flexibility, and performance, and overcome the slow time to market caused by the brands’ existing technologies. Plus, brands must pay attention to retaining customers rather than just acquiring them.
Many are the approaches that take advantage of new technologies. This article unpacks the options and their relative strengths and weaknesses in building the foundation on which you can scale or unchain your brand. 
As a start, the following are the key terms that apply to digital-experience architectures:
  • Monolithic, which refers to single-vendor-based architectures, whereby the vendor is often a closed system with a single product that contains many specific components, that are glued together so that they are inseparable. Monoliths frequently dictate certain paradigms for coding the front end.
  • Headless, which applies to decoupled architectures, where presentation (the head) is separate from the underlying (headless) business logic technologies.
  • MACH, which stands for Microservices, APIs, Cloud, and Headless. Notably, products built the MACH way can meet brand requirements for performance, scalability, flexibility, etc. However, despite the vendors’ headless capabilities, not all vendors are MACH certified. 
  • Composable, which means that your digital-experience stack comprises various packaged business capabilities (PBCs), each of which featuring one or more technologies and which you can add or replace without fundamentally changing the architecture. In a composable architecture, all the systems are decoupled. The more decoupled they are, the more flexibility for switching functionality or updating designs.
Headless and MACH, though often cited as composable, represent different concepts, as follows:
  • How composable a technology is refers to how pluggable or swappable its elements are and who can plug or swap them.
  • How MACH ready a technology is refers to how oriented it is vis-à-vis APIs and microservices and how mature it is in terms of MACH standards. 
Based on the above axis, we’ve generated a matrix and the diagram below that illustrates the approaches:
The four choices are—
  • Legacy monolith: low composability and low MACH maturity
  • Suite technologies: high composability and low MACH maturity
  • Composed MACH monolith: low composability and high MACH maturity
  • Composable MACH: high composability and high MACH maturity

Legacy monolith

The vendors that offer a legacy monolith have been around for a while, perennial leaders in categories like digital experience platforms (DXPs), content management systems (CMSes), commerce, and digital asset management (DAM), having started before cloud and SaaS technology became standard practice.  
Those vendors have large installed bases. Since they might already have paid a premium for the technologies, the existing customers usually stay around for a few years. For other customers, it’s simply too hard to change short-term because it took years to install those systems with tentacles all over the place. Also, those vendors have large, loyal agency partners and systems integrators that have built their own service offerings on top of the vendor's products, given that the partners have abundant resources that are trained on the technologies required for deployment and adoption. That’s a common problem for less mature buyers, however: As amazing as the vendor presentations and demos might look, in reality, the architecture has long been outdated. Obviously, smart brands would avoid those aging platforms at all costs. 

Typical customers

Organizations that are on fully-paid, perpetual licenses whose costs would increase significantly if they were to replatform, and organizations whose current implementation imposes few or no limitations.

Pros

The software has been in place for so long that organizations are no longer paying license fees, only maintenance costs.

Cons

  • Inflexibility, involving extra costs when acquiring capabilities not offered by the vendor or when the capabilities offered cannot meet your requirements.
  • Vendor lock-in, i.e., a platform-based stack that often needs replatforming for modernization every four to five years.
  • Limited access to resources for implementing solutions based on the vendor’s proprietary technology.

Suite technologies

Suite vendors have often built or purchased various products and integrated them themselves. Even though those vendors have long been around, they have added modern capabilities to their core platform since losing deals to upstart competitors, such as headless vendors. These additions include SDKs for modern JavaScript frameworks (e.g., Next.js), headless capabilities, and easy integration with their technology ecosystem. Suite vendors tend to shy away from integrating outside their suite. 
Since their platforms are typically not fully SaaS, suite vendors are not MACH certified and are routinely sold as a cloud, with the vendor handling updates for customers and provisioning access to systems, etc. Even though suite vendors brand themselves as composable, e.g., composable DXP, they are not composable because you lose capabilities in the suite if you replace any preintegrated products.

Typical customers

Less digitally mature organizations without strong in-house engineering and architecture expertise.

Pros

  • A one-vendor contract, i.e., you buy the capabilities for your stack from a single vendor.
  • A preintegrated system with adjacent capabilities.
  • A broad ecosystem of system integrators.

Cons

  • Inflexibility, involving extra costs when acquiring capabilities not offered by the vendor or when the capabilities offered cannot meet your requirements.
  • Vendor lock-in, i.e., a platform-based stack that often needs replatforming for modernization every four to five years.
  • Limited access to resources for implementing solutions based on the vendor’s proprietary technology.

Composed MACH monolith

The composed MACH monolith leverages MACH-certified technologies for CMS, commerce, DAM, etc., and then builds code for manual integration between the systems that offer the user experience, e.g., MACH technologies and their front end of choice—open architecture, API first, flexible business logic.
The projects typically start with one or two connected systems, which can become complex to manage and maintain once the number of integrations exceeds five and the number of connection points, 20. The architecture is more composed—e.g., gluing the selected technologies together—than composable, which is easier to adapt on the go. This example can also be an agency-created accelerator.
Also, since composed architectures are often developer led, only developers can update them. Consequently, those architectures tend to focus on engineering interfaces with little need for business user UX.

Typical customers

Organizations that emphasize custom development and that traditionally lean toward build versus buy.

Pros

  • Learning how to use the composed MACH monolith is easy and fast given the small number of systems.
  • The front end being based on modern standards leads to a larger pool of developers.
  • Vendors might provide prebuilt connectors to other systems or support interoperability to an extent.

Cons

  • You must manage multiple vendor contracts.
  • Significant maintenance is required over time in addition to a risk of being locked into the developer backlog for even trivial business-user tasks.
  • The dependency of maintenance on either the agency—thus creating a middle layer, or on the engineering team, which, over time, might balk at those mundane chores—is undesirable.
  • Glue code turns into tech debt, requiring constant maintenance and refactoring that slows development velocity over time. 

Composable MACH

The composable MACH architecture reaps the full benefits of composable, e.g., flexibility in connecting technologies to the stack and readiness in adapting to future needs, such as new front-end frameworks, new channels, and new markets.
Organizations with a composable MACH architecture aim for the highest level of flexibility, optimized for the fastest time to market, and for a great UX for the teams that manage digital experiences. With a passion for maximum speed to market and time to value and learn, those organizations can iterate faster and faster. 

Typical customers

Ambitious and mature organizations that prioritize fast time-to-market and that clamor for the ability to quickly adapt to changing business needs—while recognizing that the task of building digital experiences is shared equally between business and technical teams. 

Pros

  • A future fit as architectures become more value driven and adaptable to changes of their components on short notice.
  • High speed and simplicity in deploying only a few systems.
  • A focus on the requirements and workflows of both developers and business users with the recognition that those two teams play a crucial yet different role.

Cons

  • Multiple vendor contracts.
  • A requirement for seasoned architects, either in-house or through agencies.
  • The likelihood of process change to ensure that marketers and developers work seamlessly together.
Based on the above four architectures, the diagram below highlights which solutions organizations should adopt as their architecture.
  • Legacy DXPs, most of which, having been around for 10-12 years, are closed and monolithic.
  • Composable DXPs, which are often legacy DXPs with added modern capabilities and branded as composable DXPs. Integrating tools that compete with the preintegrated ones might result in loss of significant functionality.
  • Bespoke accelerators (e.g., agency accelerators), developed either in-house or at the agency. They seek to speed up adoption of MACH products, which are often integrated through glue code that’s custom-built by integrators and agencies, not through configuration. 
  • Digital experience composition, a new category of products that build the basis for managing composable experiences at scale, integrating MACH tools through configuration with a no-code or low-code approach to preserve the benefits of composability beyond the initial implementation.

Next steps

Choosing the right digital-experience architecture is crucial for gaining agility, flexibility, and high performance for your digital properties. By understanding the key concepts and differences among the monolithic, headless, MACH, and composable options, you can make an informed decision that aligns with your business goals and needs.
If you're still unsure which architecture best suits you, book a free demo with us to learn how a digital experience composition platform (DXCP) can help you realize the true promise of composable.
Monolithic, which refers to single-vendor-based architectures, whereby the vendor is often a closed system with a single product that contains many specific components, that are glued together so that they are inseparable. Monoliths frequently dictate certain paradigms for coding the front end.
A cheat sheet for getting composable right!

A cheat sheet for getting composable right!

Start your composable journey!