As API-fronted services rapidly proliferate, a radical new model for building applications is emerging – and it’s going to radically change enterprise IT. In this model, companies will choose from a toolbox of public and private API services that can be integrated and discarded with relative ease to meet changing business demands.
It will simplify the integration of complex systems into businesses – and it will see the developers playing a decisive role in which technologies win, driving adoption from the bottom up. Termed by some as “the Composable Enterprise,” this model of production threatens to forever alter the economics and power relationships that define traditional enterprise IT organizations.
Jonathan Murray, EVP & CTO at Warner Music, recently tackled the composable enterprise model in a blog post, describing an approach to building applications where “[c]ompound business processes are broken down into the minimized set of ‘atomic’ functions. These processes, and the applications underpinning them, can be “continually re-configured with low-cost and operational impact.” And since this means a radical shift in how change is managed, the composable enterprise presents a challenge not just to entrenched technologies, but much more importantly, to traditional management structures.
The resulting changes, he argues, will make it possible for companies to build apps faster and at much lower cost, employing processes that owe more to industrial production than to artisanal methods. Seven years after the launch of Amazon Web Services, it is hardly an outrageous notion to suggest that enterprises should think twice before building their own data centers. But Murray’s argument goes well beyond IaaS, into the tangle of traditional IT infrastructure, where unglamorous yet necessary services like e-discovery and document retention, mail, voice, data warehousing, database, payment processing and even pager notification continue to burden CIO budgets.
Services like these will be composed of many discrete services (e.g. storage, monitoring, security, metering) and will in turn be components in even more complex applications. Some will be delivered by third parties and some, either for strategic reasons or out of necessity, will be developed in-house. The provenance is less important than the architecture – Murray wrote that services should be viewed as modular “building blocks that can be reconfigured as needed to address the changing competitive landscape.”
APIs can help
While much of this might seem second nature to today’s nimble startups, the composable enterprise model represents a profound shift from the siloed, monolithic architecture that characterizes both traditional enterprise apps, as well as the large enterprise IT organizations that produce them. Being an “agile” organization is not enough. Nimble processes on top of ponderous, bespoke infrastructure will not be enough. It’s still just lipstick on a pig.
Interestingly, and particularly in light of his assertion that the cloud plays a prominent role as “an architectural blueprint for developing a new generation of loosely coupled, highly resilient, and scalable systems,” Murray makes no mention of APIs in his blog. The recent explosive growth in public APIs, along with a lively debate as to their role in enterprise strategy, underscore just how essential APIs are to the composable enterprise model.
There is really no other way to quickly integrate loosely coupled services other than through standardized, easily apprehended, programmatic interfaces. In fact, the API may be the most important aspect of any modular service. Poorly executed, or even just poorly documented APIs, tend to take longer to integrate, thus leading to buggier integrations, defeating one of the principle benefits of the composable enterprise model in the first place.
Bottom-up or top-down change?
The absence of a discussion of APIs might seem puzzling until one considers a key component of Murray’s argument – that this transformation to a composable enterprise must be driven from above, by enlightened management. From his vantage point, APIs probably matter about as much as which text editor developers use. According to Murray: “Change of this magnitude requires visionary and forceful top-down leadership. Implementing the Composable Enterprise approach is not going to happen from the bottom-up.”
On this point, I completely disagree. A cursory look at the history of the last decade shows us that all major changes toward the composable, modular model have started from the bottom, where the intransigence of IT has sparked rebellions among devs who took refuge in the metaphorical hills of Amazon and Heroku. With personal credit cards and personal time, devs have dragged their IT organizations into the age of cloud. There is every reason to think this trend will only accelerate.
As Steve O’Grady writes in his book “The New Kingmakers: How Developers Conquered the World“, technical talent will increasingly separate the winners from the losers in not just the software industry, but in every industry. Developers will be the ones who decide which of the services become central to the composable enterprise. And they will make decisions, in large part, based on API utility. The success of services like Stripe has been driven by developers who love it — because it is easy to use, and because it works.
I can understand why someone with Murray’s vantage point would believe that management must drive the change. And whether it comes from above or below, the central tenet of this argument is almost certainly true. The consequences for companies who fail to embrace the composable enterprise model will be dire. These companies will themselves be mired in the lethal inertia of traditional time-and-capital-intensive IT processes, watching composable enterprises iterate much more quickly on features, and more quickly respond to user demands.
Over the next several years, we’ll see many enterprise organizations resist and deny the inevitable. But it’s not so different from what we witnessed with BYOD, and then “the consumerization of IT.” APIs have eaten software, and they’ll go on the eat enterprise architectures, too. And it won’t be the CEO in his swivel chair that makes the call, it will be the masses of developers who will drive it forward.
This story was updated Sunday at 7:30 am to reflect Jonathan Murray’s correct title.
Antony Falco founded Basho, makers of the Riak database, and more recently, Orchestrate.io.