Moravia’s Take on the Composability Revolution
Click here to close
Click here to close
Subscribe here

Moravia’s Take on the Composability Revolution

Moravia’s Take on the Composability Revolution

Moravia's Take on the Composability Revolution

The term “composability” has largely remained exclusive to the IT domain, but it’s a concept that has broad relevance, including to the GILT (globalization, internationalization, localization, and translation) industries.

Case in point: Moravia has been undergoing our own composability remodel—a move designed to serve our customers in both subtle and profound ways.


If you don’t have at least one foot in IT, you may never have heard the term “composability” before, which Wikipedia describes as a system design principle. I’ve mostly seen it used in the context of designing IT infrastructures.

Its key principles are modularity and reusability, but the heart of the concept can be found in the word itself. To compose something is to give it form through the assembly of components, and the extent to which something supports the creation of new things through these components is its level of composability.

When you start to look at the world through this lens of creation through the assembly of components, you see examples of composable systems all over the place.

The go-to analogy out there is LEGO, and it’s easy to understand why: anyone who has ever played with Legos has a good sense of the concept already. Through a set of different-but-interoperable pieces, you can create any permutation of object—or scenario—you can imagine.


It’s an idea explored in the movie “Big Hero 6” through the plot device of the Microbots, a set of “neurotransmitter controlled,” magnetically connectable pieces that can create dynamic, architecturally complex structures (which ultimately get stolen by the villain and used as his superpower).

Composability is also central to the IKEA business model that sells modular pieces of furniture that can be bought and arranged together to form comprehensive groupings.

And it’s an underlying principle (although not by name) in Adam Smith’s The Wealth of Nations, which asserts that economic growth is driven by increased division of labor in both manufacturing systems and economic systems. At the manufacturing level, the components are the tasks required to produce something. Within economic systems, the components are the individual specialized industries that can be traded and combined to create new value. Our modern economy is a living example of this principle in action.

The (r)evolution

Not all systems are equally composable, however. In the world of IT, the opposite of a composable system is described as a monolith.

If monolithic systems can even be described as having components, their components are bound together. Nothing takes place outside the monolith; everything is built-in. They’re big, standalone, all-in-one, indivisible entities. There are arguments in defense of monoliths, but the case against them is that they’re inherently inflexible, slow to evolve, and difficult to scale. They’re tailor-made to a problem until the landscape changes completely—at which point their all-in-one-ness becomes an impediment. The worst examples are disparaged as “balls of mud.”

The reaction against monoliths has influenced several notable technology movements:

The Service-Oriented Architecture (SOA) movement – SOA sees the natural component within a modular system as being the service: a discrete, specific piece of specialized functionality that can serve a variety of systems and contexts, including other services. There are parallels with the Unix philosophy, which advocates small, modular, interoperable applications.

The SOA movement has been highly influential over the way companies are designing or re-designing their technology stacks, and to the adoption of enterprise service buses. Related, but not identical, is the microservices architecture movement, which has additional notions about how modularity should be implemented.

The “Programmable Web” movement – I see this as the SOA movement applied inter-organizationally. The programmable web philosophy sees all the APIs available across the internet—from separate hosts—as part of a holistic programmable system from which new capabilities can be composed.

It’s a movement that’s spawned the practice of “mashups”: the creation of useful applications through the combination of APIs (for example, combining Craigslist apartment listings with Google Maps to create a visual map of available apartments).


The Wealth of the Nation” by Seymour Fogel. What new value can be created by leveraging the wide world of API-accessible capabilities?

Moravia’s response

At Moravia, we’re excited about these movements, since they’re compatible with our worldview: we define a “solution” as a composition of strategy, process, technology, and human involvement, and we employ solutions to meet our customers’ needs, solve their business challenges, and provide value.

The efficacy of our solutions has always been relative to their composability—the extent to which components need to be developed from scratch, capabilities can be reused as-is, and pieces can be replaced or updated by better ones. As our customers’ workflows evolve (sometimes radically), the ability of our solutions to quickly conform to the shape of the problem (not unlike a cloud of Microbots) is incredibly valuable.

And we’ve embraced the pro-composability revolution in several ways:

  • We’ve been migrating to a service-oriented architecture within our own tech stack. We recently developed and deployed the Moravia Service Layer through which all our internal tools can communicate, and have been generally migrating from a products-orientation to a services-orientation. Through the Service Layer, we remove the functions that are common across tools and make them available as shared services.
  • For a while now we’ve been “API-ifying” our tool stack, making sure that our tools’ core capabilities can be flexibly invoked from anywhere.
  • We’re leveraging the programmable web and API economy ourselves, utilizing third-party APIs where they can add relevant capabilities to a solution.

We’re doing these things because we see advantages for us and for our customers, both big and small. Any time we can reuse a capability that’s already available as a component—as opposed to having to create it from scratch—we save time and money.

More broadly, having a rich, highly-composable capability stack with components that we’ve either created ourselves or have leveraged from others is a liberating force for creative problem-solving. The more specialized components we have in our stack, the more we can assemble them to create new solutions to increasingly complex globalization problems.

The more we can focus on solving our customers’ big-picture globalization challenges, the more relevant and valuable we are to them. Everybody wins.


What are your thoughts on composability and its relevance to solving globalization problems? Are you making changes in the context of the composability revolution too?