What is Composability, and What Does the Composable Concept Mean for your Business?

I've written about composability in the past, and it is great to see this concept remain front and center in some contexts and gaining momentum in terms of development standards, methodologies, successful middleware providers that can help wrangle the moving parts of a truly composable stack, and also seeing the basic concept of composability have broad application in the realm of AI models and apps.

All of this is to say that composability continues to gather momentum as an approach to building technology ecosystems of one kind or another within organizations. It is an approach with a lot of merit and that comes with specific considerations and requirements in terms of how you build your roster of talent to support these approaches. Let's jump into composability in more detail and why it matters.

What is Composability?

As with most trends and buzzworthy concepts, composable and composability have taken on a bit of a life of their own when it comes to how people use this terminology and conceptual framework. There is enough overlap between the different usage that we can fairly quickly bridge the gap from one framework to another. For the purposes of this article, we'll try to answer this question generally and then use three examples of application of these principles to help illustrate the point.

Broadly speaking, the concept of composable architecture is to design and build systems of integrated technology and data systems such that you have the flexibility to choose the best component for each specific technical need and then integrate them using methods that support modularity, seamless integration, headless architecture for components of the larger system, and the ability to decouple, replace, or swap out a key component for an alternative application if desired at a later date if and when a better or more appropriate solution comes along. Another way to say this is that you prioritize solution design and system architecture principles that utilize excellent sub-components designed to be integrated rather than purchasing and implementing pre-bundled 'suites' that tie together multiple core functions under a unified interface and integrated black box back-end.

This naturally leads to lots of questions such as, "That's all fine and good, but what's the best way to accomplish that?"

Enter the MACH Alliance, an organization started in 2020 to help evangelize and establish collaborative best practices around composability and composable solutions. The acronym reflects the core principles of the MACH approach:

• Microservices: loosely coupled, independently functioning applications or services that perform or execute discreet functions. They can be deployed separately or together, and they give you the flexibility to implement only the features, code, and products that you need in your stack with the ability to easily scale and add others down the line.

• API-first: takes advantage of standardized rules and protocols for intercommunication between applications and data systems. This approach to many integration needs creates flexibility, reliability, and helps avoid some of the most onerous dead-ends of related to vendor lock-in and other dead-ends caused by proprietary and tightly-bundled technology solutions.

• Cloud-native SaaS (Software-as-a-Service): Cloud-native takes advantage of the scalable computational power of cloud infrastructure, the flexible continuous deployment options of containerization (e.g. Kubernetes) to make integrated applications and workflows much more robust, flexible, swappable, and extensible.

• Headless Architecture: this is the blessing and the curse of composable. Decoupling the front-end (User Interface) from the back-end (data systems, architecture, logic systems) is part of the magic that makes your architecture truly composable, but that decoupling comes at the cost of leaving you needing to do the integration between the front and back end.

Using an ecommerce retailer as an example, there are a number of potential components to an ecommerce website to consider: the website and/or mobile app(s), the commerce engine, order fulfillment, inventory management, product information, digital asset management. If you are a small startup not ready to scale or an SMB in a specialty niche, your business may be such that investing in a fully composable architecture and taking on the technical burden of doing the front-end integrations are not worth the significant effort required to unlock that level of flexibility and composability. You may be better off with a bundled/suite solution, such as Shopify or similar platform that has sufficient integrations with the other tools and functionality you need to be successful through a robust App Marketplace (or equivalent).

On the other hand, if you have a massive product catalog with 100,000+ SKUs, a massive amount of website imagery, product information, and other key meta data, one million plus customers, etc. then you could very much benefit by investing in the technical capabilities to integrate together best-in-breed solutions for your technology needs:

• Commerce engine

• Web/app front-end

• Digital Asset Management (DAM)

• Product Information Management (PIM)

• Order Fullfillment/Logistics back-end

• Inventory Management

• Digital Experience Platform

• Customer Engagement/Marketing Automation

• Privacy & Consent Management

  
  

The availability of development standards, integration protocols, and the technical infrastructure to support these composable architectures is what makes this approach both feasible and desirable. Let's move on from the approach evangelized and developed by the MACH Alliance folks as our first example.

With the steep and rapid AI adoption curve, it's no surprise that the emergence of standards and protocols for integrating AI-based tools and models into other applications has enjoyed rapid development and adoption as well.

A second example of composability is Model Context Protocol (MCP). MCP is an open source framework developed by Anthropic. It was released in 2024, and what this open standard facilitates builds on the inherent utility and extensibility of the LLM-fueled GPTs. What MCP standardizes is how AI models integrate and share data with other tools, applications, data sources, or services. With the rapid growth of AI-enabled and AI-native technology, we should expect the development of additional open standards that make these technologies more extensible, integration-friendly, 'headless', and configurable to more and more discreet (and proprietary) use cases without developing new integration plumbing from scratch for every new specific application.

MCP follows a client-server architecture, with MCP clients embedded in an AI application. These embedded clients initiate connections to MCP servers, which are small programs that expose specific capabilities or functions of external systems. A non-comprehensive but fairly exemplary list of platforms that are MCP compliant includes the following: Anthropic, ChatGPT, Perplexity, IBM BeeAI, Claude, Copilot, Hubspot, Windsurf Editor, Postman, Google Drive, Jira, Slack, GitHub, Stripe, GitLab, and more (this list is out of date as soon as I hit publish), but here is a fairly comprehensive and growing list of MCP servers.

I know full well that the MCP standard is not exactly 'composable architecture' in the common sense of this word, but I chose to include it in this article because it is actually quite closely aligned conceptually with the way shared and open standards facilitate creative, flexible, business-aligned use of powerful new technologies. Utilizing the power of the leading LLMs and GPTs integrated with your own internal data systems, CRM, productivity tools, documentation repositories, and to facilitate the rapid retrieval, analysis, clustering/segmentation of customer data, technical data, support response data, etc. in ways that does not externally expose that data and that maintains information security and governance compliance is well within the spirit of composability.

Let's move to a third example. In the world of Customer Data Platforms (CDP), the composable concept has caught on a bit as well, and in this context composable does reflect some notable distinctions from the broader use of composable architecture, though ultimately not as distinct as may first appear.

The core principle of the composable CDP is decoupling the core functionality of profile/identity unification, 360 View of customer touchpoints and engagement interactions, and data activation to downstream destinations from the underlying data infrastructure and data warehouse/lake.

One of the big differentiators in the CDP arena between 'traditional' and 'composable' is related to the idea of copyless data sources. In other words, with a composable CDP, the querying/unification/and activation functions are overlaid and run against the data warehouse itself. There is no 'copy' of your customer data that resides within the Customer Data Platform itself as is the case within a traditional CDP. This is closely aligned with the de-coupled nature of composable architecture. In this case, the foundational data resides within the data warehouse, and there is no need to duplicate, store, and constantly sync that data within another technology (in this case, the CDP).

Companies, such as Hightouch and Journify have made significant headway in this space, and they understand well that for brands and their partners, it is the capabilities that CDPs unlock that are critical to businesses rather than the technology itself. The question around composable or not has more to do with your specific business needs and not whether a composable CDP is the right solution. Any brand of a significant scale in terms of customers and revenue will benefit from the capabilities of a CDP properly implemented and utilized. Developing a unified view of customers, understanding the various media and engagement touchpoints you have with those customers (email, sms, push, paid media & performance marketing, customer support, etc.), and having the ability to segment and activate that data with downstream media and customer experience functionality is powerful. How you unlock those capabilities is a separate consideration, though an important one.

Why Should You Care About Composability?

Decisions about your system architecture can either lock you in to specific vendor/platform/ecosystem commitments or can free you up to build a stack comprised of best in breed solutions. From another perspective, choosing a bundled (or composed) solution with enough enterprise capabilities may be an expensive, though cost effective way to give you most of the capabilities you need with most of the features and benefits without the technical burden of integrating it all. It's a good idea to go through a robust process of business alignment before making these commitment. Involve key stakeholders early, solicit input on the true needs of the business and the digital capabilities you need to meet those needs, and then design a solution and architecture that make sense for your business.

Want to have a conversation about this? I invite you to reach out and connect.

Get In Touch