A businessman stacking a wooden block on a tower of wooden blocks
PHOTO: Adobe Stock

Rapid digitization drove companies into the “Experience Era,” where personalized and consistent communication (omnichannel) across all channels is no longer just a nice-to-have but a requirement. Every organization today is, or should be, exploring a better approach to designing and delivering exceptional experiences across online and offline channels.

Traditionally, the preferred approach was to build custom applications in-house over concerns that a third-party solution won’t meet their specialized needs. While IT teams are perfectly capable of building tailored software, it’s often arguable whether or not that's the best approach. Especially when today, there's quite literally a SaaS for everything.

The features offered by SaaS seem limited – you're only getting features provided by the specific vendor — while the features built in-house could be customized as much as possible. However, what you're actually buying are multiple SaaS products doing a few things extremely well, and following best practices, so you don't have to worry about staying competitive. There's enough competition in the SaaS industry to ensure all vendors stay on the top of their game in rolling out exciting innovations for their capabilities. If not, well, switch them out for a competitor without causing business disruptions.

A high-level comparison between composable SaaS and In-House from a DAM perspective.

A high-level comparison between composable SaaS and In-House from a DAM perspective. Source.

Branching off of this — the idea of Composable Architectures, Microservices, and Experience APIs are making a bigger splash in the Digital Experience industry with the emergence of the “Modular DXP”.

Moving From Monoliths to Composable Architectures With Microservices and Experience APIs

Traditionally DXPs have been “full-stack” monoliths that provide an architecture for businesses to digitize their business goals, marketing activities, analytics, and content management. Over time, with the rise of API-driven approaches and the need for omnichannel content distribution, there has been an emergence of modular “DIY” DXPs, which are essentially a loosely coupled combination of best-of-breed (typically SaaS) products working in harmony.

These DIY DXPs typically see several components, or microservices, coming together to create the functionality of what a full-stack experience manager would offer, but purely with a “headless” approach. Potentially at a fraction of the cost as well.

Composable Businesses, MACH, and Building Experience Architectures

There's been a lot of talk about MACH architectures lately. MACH (Microservice, API, Cloud-native, Headless) architectures aim to guide enterprises towards building composable architectures using building block APIs like "Legos" to define a stack that works for them.

This entails individual pieces of business functionality being independently developed, deployed, and managed — all exposed via API — and cloud-based as a SaaS model.

These “composable architectures” are what form the basis of the buy-to-build argument – where companies are utilizing several vendors, buying multiple SaaS solutions that do a few things very well, and building them into DXPs that would typically have been an all-in-one solution. Think stacks, not suites. Think the best of commerce, payments, content, and personalization APIs working together, rather than just a sub-optimal suite doing all those functions in an acceptable manner, for example.

This brings us to an interesting pivot in the DXP discussion. Going from Experience Platforms to what Forrester coins as Experience Architectures.

Deciding on Whether Experience Architectures Are the Right Approach For Your Business

The argument here is that multiple teams own multiple aspects of the customer journey. They're all buying and investing in various APIs — Products, Finance, CX, Marketing, Automation, etc. It isn't feasible to manage them all via custom middleware and gateways that lead to data silos and multiple points of failure, they all need to be orchestrated on an "aggregation layer" and delivered to customers on presentation layers that are most relevant.

Technical personas and commercial personas need to start working together in defining these experience architectures together. There’s no one-size-fits-all approach to them. Given how specific it is to a use case or company, it isn't something that can be bought from a single software vendor; rather, you build and practice experience architectures. It requires looking across the customer lifecycle and bringing together marketing, commerce, service/support, supply chain, and more to work in service of your customer, rather than in siloed teams or buckets of technologies – whether bought or built.

It is quite literally buying multiple (if not hundreds) of SaaS tools, to painstakingly and specifically map them into a custom build that lets them fulfill exactly what you want them to.

As companies are transitioning towards digitizing and modernizing, alongside breaking down monolithic stacks, the need for finding best-of-breed services to accomplish complex use cases is gaining importance by the day. Commercial personas within marketing, sales, and operations are getting conscious about the tech stacks they're using, and are starting to expect more from APIs rather than just trusting flashy software at brand value. They're getting informed about the modular approach, and are taking a genuine interest in seeing how these “best of breed” microservices combine their capabilities to fulfill business goals.

We're collectively moving from Experience Platforms to Experience Architectures, and these are being carefully built and orchestrated with SaaS platforms & APIs — we've literally moved from arguing about Build vs. Buy — and are actively buying to build architectures that are highly tuned to our specific use cases.

So is Buy to Build the new approach we should be advocating for even on the commercial side of the organization? Should we instead start paying more attention to the microservice and headless conversation that the technical teams have been indulging in for the past few years?

Used by over 50,000 teams from companies like Burrow, Telenor, 2U and Unilever, GraphCMS is the first enterprise-class headless content management and federation platform. With the industry's most versatile GraphQL content APIs and a novel approach in external data sourcing via API extensions, the content platform enables use cases beyond simple headless CMS' capabilities.