6 Comments

Summary:

The rise of APIs as a source for web services and data means that developers don’t have to reinvent the wheel on every feature — they can source it from an API. This trend brings about 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 pinar@pinarozger.com

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, Orchestrate.io.

  1. It will be a curiosity to watch this unfold and see how far and reaching it will trickle down to the most remotely removed and technically challenged companies. It will allow for a start up or mom an pop operation to have level playing field with the strongest company that lives by their own IT CONSTRUCT .

    Share
  2. Forrest Maready Sunday, October 13, 2013

    I’m curious how this will play out in the coming years among startups, Will they be considered inferior and with very little IP because they rely on a disparate set of APIs with a relatively small amount of glue code holding things together? Complex ideas that could once make it past the patent examiners with a spider web of terms and processes may be more aggressively declined and/or paired back when their functions can be ascertained by the recipe of APIs they are using.

    As a technology leader at my company, I’ve already felt pressure to shy away from common PaaS vendors because of the perceived hit to company IP.

    Share
  3. Forrest Maready Sunday, October 13, 2013

    I’m curious how this will play out in the coming years among startups, Will they be considered inferior and with very little IP because they rely on a disparate set of APIs with a relatively small amount of glue code holding things together? Complex ideas that could once make it past the patent examiners with a spider web of terms and processes may be more aggressively declined and/or paired back when their functions can be ascertained by the recipe of APIs they are using.

    I have friends in technology leadership roles that are already feeling pressure to shy away from common PaaS vendors and some APIs because of the perceived hit to company IP.

    Share
  4. Chris here from Mashape – the API Marketplace. If you’re a developer and would like to discover long-tail APIs, you can check out Mashape.com Feel free to email me if you have questions (or looking for specific APIs for your apps) – chris@mashape.com

    Share
  5. Hi Antony

    This article could not have come at a better time for us. After a year of working on our platform, we just launched out cloud services platform that helps enterprises develop, deploy and manage cloud services. Our vision aligns with yours and we feel that enterprises have not choice but to move towards this architecture. Unfortunately there isnt enough expertise out there to make it happen. This change will be gradual but inevitable.

    Thanks,
    ritesh@nirmata.com

    Share
  6. This is great and with a few modifications to Johnathan’s model we can create “Composable Enterprise 2.0″ and call it the “Recomposable enterprise” or the “Adaptive Enterprise”.

    The first change is to introduce a business process compiler which can optimize and re-synthesize the enterprise topology, which interconnects the individual atomic functions and the integrated analytic capability. The compiler in turn can re-synthesize the enterprise based on analytic feedback and business objectives/forecasts. This is the basis for the adaptive enterprise.

    Key elements of Johnathan’s model include:
    1. Elimination of private data sets, this makes the enterprise model stateless and circumvents coherence issues.
    2. The “unified data model” this constrains the business compiler and anchors it to support business continuity across re-synthesis operations.

    Elements of the model that can be enhanced:
    1. People services: Johnathan’s model proposes role-based user authentication / profile management, roles based engagement (authentication + authorization) is rigid and brittle and less adaptive/extensible that an attribute based approach. Attribute based access control can support support delegation to loosely coupled employees, vendors & partners.
    In addition attribute based access control is flexible enough to adapt any device anywhere scenarios based on the instantaneous risk calculated from real-time contextual attributes.

    Paradoxically, Any device anywhere / BYOD can be transformed in to a major business enabler for the adaptive enterprise. The SIMcard is the most prolific online security token in the history of business. Here at Payfone we provide a cloud API that enables enterprises harvest the power of the SIMcard and the intelligence of the mobile network infrastructure. The Payfone API supports diverse use models, including:
    a. Device Authentication based on SIM hardware-embedded credentials, no client software required
    b. Employee / partner / customer Self-provisioning by virtue of strong device authentication and consent based access to subscriber identity attributes on file at the mobile network operator.
    c. access to realtime contextual attributes such as lost / stolen or location for transaction based risk management

    Share

Comments have been disabled for this post