In any industry, buzzwords abound!
In the Digital Experience (DX) landscape, it is no different – and you will hear a handful of terms that seemingly set the standard for the ecosystem.
However, you might not know what they all mean and how they are different from one another. That could pose a major problem, particularly as a technology, marketing, and/or business leader in the enterprise who is expected to be at one with the trends and best practices while leading their organization to digital glory.
I recently sat down for an hour during a DX Café interview with Andrew Kumar, VP of Customer Solutions at Uniform, and we talked about four of the oft-heard concepts around the DX industry “watercooler.”
Uniform is an interesting company to start with as a frame of reference for much of this headless and composable DXP and product industry. As Kumar noted in the discussion, Uniform is “a rapidly evolving product set, but it is very much this visual workspace for digital teams.”
One of our first orders of business was to define four specific terms within DX architecture: Monolithic, Headless, MACH, and Composable.
Kumar discussed the transition from monolithic systems to more modular, composable systems in enterprise technology. Traditionally, monolithic systems encapsulated all software functions in one application, which led to challenges due to the complexity of enterprises. Companies often had to adapt their processes to the monolithic system or spend significant resources to adapt them to their business.
Kumar suggests that enterprises' complexities arise due to their constant need to meet customer demands, leading to diverse offerings. When enterprises attempt to fit monolithic systems into their complex business operations, they often encounter difficulties.
In response to these challenges, monolithic platforms decompose into modular structures to support these complex business needs.
“I am starting to shy away from the term monolithic,” said Kumar. “And I'm shying away from that because the historical monolithic platforms are decomposing themselves.”
However, Kumar mentions that businesses often underestimate their complexity until they have analyzed their operations. Only when the complexities are fully understood can technology be molded around the business rather than vice versa.
He uses the term "all in one" rather than monolithic, as the platforms are becoming more modular and adaptable to fit the needs of the business. However, these all-in-one systems often do not integrate well with external modules, akin to battery packs that only fit one brand of tools.
While all-in-one solutions can be beneficial due to their convenience, speed to market, and easier vendor management, they often do not excel in any particular area, only offering adequate solutions for various functions. This can be a drawback for businesses requiring a specific solution or the best feature. Despite these shortcomings, it can prove valuable if the out-of-the-box solution fits an enterprise's needs.
Kumar concludes that the move away from monolithic systems is largely based on the level of complexity and customization that a business requires. The more complex and custom a business needs, the more likely a monolithic system is to be an impediment.
Kumar talked about the concept of "headless" systems, which are becoming popular in the tech industry. Headless systems offer more flexibility than traditional "all-in-one" systems, as they separate the content from how it's presented to the customer. This decoupling allows for easier content distribution across various channels.
In an all-in-one system, content creation and presentation are intertwined. For instance, a Content Management System (CMS) creates webpages and websites. However, presenting the same content on a mobile app or other platforms like email channels, digital displays, or VR headsets requires significant effort to untether the content from its original presentation.
“An all-in-one CMS builds webpages and websites,” said Kumar. “(but) then if you try to build a mobile app with the all-in-one, you have to untether. You have to undergo a lot of effort to create flexibility. If you try to put that content into an email channel, or a digital display or a VR, like an Apple VR headset, it's a lot of work. It's feasible, but it's a lot of work.”
Conversely, headless systems don't know or dictate where the content will end up. The content is consumed through an API and can appear on a website, an app, or other platforms. This gives tremendous flexibility and allows reusing content across various touchpoints and channels.
The challenge with headless systems is that they do not inherently provide a way to preview how the content will appear in different consuming applications. Over the past six to seven years, Kumar has been developing tools to enable such previews.
The appropriateness of headless systems depends on the industry and the nature of customer interactions. Headless systems make sense in industries like telecom, where most customer interactions are through mobile devices or chatbots. Some organizations start by using headless for a single website before expanding to multiple websites, thereby beginning to take advantage of the system's flexibility. However, it's a different paradigm with a lean, out-of-the-box solution.
Kumar noted that the MACH in the MACH Alliance stands for Microservices, API-first, Cloud-native, and Headless. The MACH Alliance sets high standards for vendors in the tech industry, and not every vendor meets these standards.
Like Kumar's company Uniform, those who receive approval can assure prospective buyers that their platform has been audited and meets specific technical standards. This approval can help support both the buyers' previous and future investments.
Kumar acknowledges criticism that the MACH Alliance is not inclusive but argues that maintaining high standards is necessary to push the industry forward. The high bar for entry ensures that the MACH Alliance seal retains its value and is not awarded to companies that do not meet its stringent criteria. Therefore, he views the exclusivity of the Alliance as a potential strength rather than a weakness, ensuring that only vendors that meet the highest standards are admitted.
Kumar lastly broke down the concept of "composable" systems, stating that this is the latest term in the tech industry. He sees it as a natural evolution from monolithic to all-in-one to headless systems and now to composable systems.
Traditional monolithic systems are now decomposing into composable systems. They're breaking down into smaller, more manageable modules that can be reconfigured per business needs.
“Headless tools are generally composable by default,” asserted Kumar. “Because they're unique, like ring-fenced capabilities that can be plugged and played as necessary.”
The MACH Alliance's standards, Kumar explains, push the needle on what it means to be truly composable. Having APIs on top of any software does not make it headless or composable. He highlights the importance of having clean, well-defined microservices to manage the platform's infrastructure. He also emphasizes the necessity of being "API first," where APIs get published concurrently with features.
Moreover, he addresses the importance of the Cloud in the MACH model. While one might have a headless system hosted locally, it would not meet the requirements of being self-serve, auto-updating, and cloud-native. In a cloud environment, the vendor takes care of security patches, reducing the maintenance burden on users.
Finally, he highlights the value of being composable for complex business enterprises. Adapting technology to business needs is vital in a rapidly changing business environment. While "composable" hasn't gained much search volume or intent yet, he anticipates it may become the next hot keyword in the industry.
Education is paramount in the ever-shifting DX industry. We hope you have gained a better understanding of some of the key principles that are frequently raised in conversations.
Matt McQueeny is part of the leadership team at Konabos and a CMS Critic contributor.