Developers, now more than ever, build applications from components. In the preceding decade and around the turn of the century this meant components for popular languages and tools like Visual Basic and Visual Studio.
Today, those components consist of some of these traditional components, especially in the “presentation,” UI/UX layer, but even more so those components involve services. In most cases, those services are accessed through an API.
Space does not permit a deep dive on APIs here, but they already dominate and will continue to do so in the future. Consumer apps rely on a tapestry of interwoven services and capabilities – so much so that many of the apps we take for granted could not exist without them. Increasingly, enterprise apps do, too.
I’ve just returned from speaking at the API Strategy and Management conference and am heading out next week to speak at the I Love APIs conference. These events bring home the rising importance of APIs — as does a recent piece on GigaOM that calls this trend the “composable enterprise.” The writer, Antony Falco of Orchestrate.io, shares excellent insights (and I recommend you read the entire piece). One of his main points is worth spending a bit more time on:
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.
I don’t know if the phrase “composable enterprise” will catch on, but the idea is absolutely valid.
I’ve given longer presentations on this subject to our clients; but in short, even more than before, the move to componentized (or composable) development projects represents opportunity and threat to both the enterprise and vendors who serve them.
Enterprises take risk by allowing mission-critical components of applications to be supplied by external services and suppliers. It’s difficult to make this shift — but once this shift in approach happens, it can increase the speed of development. Unless prohibited by international law, national security, privacy law, or the like, external services can bring domain expertise to aspects of enterprise solutions without the enterprise having to develop that expertise, especially when it’s not core to the company’s value.
Of course, this represents opportunity for a wide variety of suppliers, services and vendors. Doors previously closed may be open. Building enterprise developer awareness and understanding becomes core to driving large sales. (And that’s something we help with.)
However, there’s a double-edged sword lurking underneath the surface (yes, that was an Arthurian allusion).
Enterprises incur risk by allowing external sources to provide part of their value; however, when they develop applications under this model, they have effectively broken their applications into discrete, abstracted pieces. And that abstraction means that it is much less painful to change providers of that service or capability than it used to be. This in turn minimizes the risk of depending on an external provider.
For the providers, this reinforces the importance of developer marketing best practices as well as best practices of business: reliability, honesty and value.
(Don’t miss Falco’s piece, where he discusses other important aspects of this, including how this revolution is driven by developers, not executives.
How do you think the “composable enterprise” will affect your world?
Image via stevendepolo on Flickr under Creative Commons
