Armed with APIs, developers will drive the composable enterprise

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.

Structure 2013 Jonathan Murray Warner Music Group

Jonathan Murray, EVP, CTO, Warner Music Group(c) 2013 Pinar Ozger [email protected]

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]om­pound busi­ness processes are bro­ken down into the min­i­mized set of ‘atomic’ functions. These processes, and the applications underpinning them, can be “con­tin­u­ally re-configured with low-cost and oper­ational 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.

Lipstick won't help.

Lipstick won’t help.

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 mag­ni­tude requires vision­ary and force­ful top-down lead­er­ship. Imple­ment­ing the Com­pos­able Enter­prise approach is not going to hap­pen 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,