The Composable Enterprise Model (CEM), which has been called the future of business by some commentators, prizes flexibility and adaptability in the technology powering businesses.

When Jonathan Murray coined the term in an Adamalthus blog post, he didn’t specifically connect it with APIs. Other writers, however, soon jumped on the idea to illustrate how effectively the two went together.

Terms like microservices, service mesh, and service-oriented architecture (SOA) get thrown around a lot when APIs are being discussed, and the composable enterprise model is the latest of these terms to rise to prominence. But what exactly does it mean?

Below, we’ll explore the Composable Enterprise Model in more detail and consider how it relates to APIs. We’ll also be looking at where the Composable Enterprise Model sits among existing terminology in the API space, and why the idea of CEM may be valuable for developer-manager relationships.

What is the Composable Enterprise Model?

In a whitepaper on the subject, MuleSoft defines a composable enterprise as follows:

“​​A highly connected organization with business processes supported by on-demand services that are acquired and leveraged from the cloud and APIs, furnished by outside providers or through internal data centers. The services, which tend to be small and lightweight, are themselves complete systems, and are connected to the composable enterprise through APIs, in the manner of building blocks.”

Today, automation and agility are more important than ever. Organizations are increasingly moving away from monolithic applications in favor of more lightweight and flexible services. And it’s easy to see how APIs, which are often referred to colloquially as building blocks, fit into that.

For example, the term Packaged Businesses Capabilities (PCBs) often appears in conjunction with the Composable Enterprise Model. Gartner calls these “application building blocks that have been purchased or developed.” Paid (and free, for that matter) APIs line up neatly with this definition.

The use of PCBs is also interesting because it represents a substantial shift away from the idea that building everything in-house is the only way to maintain ownership over products and services. That goes hand in hand with the focus on uptime and SLAs in the API space, which are changing perceptions around the value of APIs.

Microservices, Mesh and Composable Enterprises

If the definition of composable architecture above sounds a lot like microservices architecture…well, that’s because they share many similarities. But there is some nuance that sets them apart. There’s an implication with microservices that a monolithic application has been broken down into loosely coupled but independently deployable pieces.

In a composable enterprise, as the name suggests, the emphasis is more on picking and choosing (or “composing”) individual products and services that work together well. It isn’t particularly important that these products are built by the same developers, as long as they can be used together effectively.

Tom Quinn, News Corporation Australia’s CIO, comments that “if we have a number of these systems that we can easily integrate together, we can take out the poor-performing player and replace it with something that works better for us.”

This idea of interchangeability is key to the Composable Enterprise Model, where the backend comprises many individual software components that can be inserted or removed with relative ease. Because they’re domain-based and offer specific functionality, developers don’t have to reinvent the wheel to implement them: adding components for payments, eCommerce, or AI/ML is simplified.

With so many things going on behind the scenes, the use of API management software — including API gateways, analytics, security, and lifecycle management — is common within composable enterprises. And, when putting together many different components, using service mesh or Mesh App and Service Architecture (MASA) is often a good idea too.

Akana describes mesh as “the gears that grind away behind the scenes…[allowing] for greater connectivity between microservices, independent apps, and autonomous digital services.” There’s an important distinction in that statement, namely that MASA used in the composable enterprise model encompasses, but goes beyond, microservices.

The Composable Enterprise Model and the Future of Business

As we’ve seen above, APIs are a great way to work towards implementing the Composable Enterprise Model. Does that mean that CEM is just another name for API-first design?

There’s no doubt that digital architecture is increasingly moving towards microservices and libraries that power niche areas. Decoupling these services from one another, so all integration requires is the implementation of multiple APIs, is a powerful concept — that’s what the emphasis is on in composable enterprises.

Terms like microservices and service mesh are second nature to us, but they’re more or less confined to the world of APIs. Because the Composable Enterprise Model is a little less linear and narrow than this technical terminology, it enables API evangelists to join larger conversations about the overall direction of a business.

And the Composable Enterprise Model is valuable in the development space because its use isn’t limited to APIs; it refers to a holistic set of business practices that prizes efficiency, iteration, future-proofing, and the mitigation of risks such as downtime or errors.

As MuleSoft’s Ross Mason comments, it allows “central IT to become both a partner and platform to the business, working to expose more of the value of the business.” It highlights that, in 2022, technology is the enterprise and vice versa.

In other words, the Composable Enterprise Model represents a shift in thinking about the role technology (but particularly APIs) plays in the world of business. When automation, scalability, and accessibility are prioritized, it can only be a good thing for folks in the API space.