Back in the day, Web Services were the de facto standard for accessing "systems of record." Out of this grew the secured ESB architecture that is synonymous with enterprise architecture.
More and more, projects are utilising API Management in those architectures now and pushing on Web Services' door.
In this blog, I'll explain why social factors—as much as technical ones—are enabling API Management to make inroads into 'traditional' SOA architectures. I'll also show that API Management is much more than the "API Economy."
The Web Services Legacy
My definition of Web Services
Web Services is a vast array of reasonably well-defined XML-based, transport-agnostic definitions that allow data communication between parties. The protocols and definitions cover everything from the message content to the meta-data and systems surrounding the content (e.g. security or notifications of changes.)
The Case for API ManagementI believe that there are three things making the case for API Management and challenging Web Services domination—and they are not all technical.
If you're a computer science grad, it would have been drummed into you on day one that you hide away complexity as much as possible when you are writing code. Yet, we didn't do that when it came to system configuration and administration. This is mainly because software, and technology in general, has moved on so fast that user interfaces and tooling was secondary to getting the function out of the door.
With the advent of the mobile age, users are expecting those same rich user interfaces in everything they do. We used to call this the 'google generation' when I worked at IBM. These are people who've grown up with "things just working" and these are the people that are creating the systems of today.
Buying decisions are being made based on how easy it is to do something because that is the new differentiation point. API Management is the first group of software tools to be built in this era and reflects that by hiding the complexity of the creation and management of APIs. This is shown very explicitly by the fact that most of today's API Management tooling just creates configuration for the software that the vendor already had. For instance, IBM's API Manager configures a DataPower gateway, WSO2's API Manager configures their ESB.
Making APIs easier to implement, secure and manage reduces skills requirements and speeds time-to-market.
The third reason Web Services are not today's technology of choice is because mobile devices and clients with rich user interfaces are the modern way. This is complementary to hiding the complexity on the server side. These applications are being written by developers who want to focus on the user interfaces and don't want to learn the other deeply-technical data handling skills. How they access the data is almost secondary and their skills are not in that area. They just want access to data, as and when they need it and in a simple manner.
Micro Services and Agile Development
The business needs highlighted above are having further ramifications in the project delivery.
With the promises that they hold of small "just when you need it" access to data and services; Micro-services are challenging the traditional SOA architectures hold on the enterprise. They fit well into the API Management ease-of-use paradigm.
Micro-services are still in their ascendancy and tooling and architectures are still being invented. Even so they are already challenging Web Services with their promises to deliver just the right amount of access to the systems. This also fits nicely into the agile methodologies being employed by most businesses today. Small sprints and piecemeal construction techniques require "just enough" work to be done to get from A to B.
We can see the ramifications of Agile and API tooling today: around 75% of API Management projects are internally-focused. This tells us that APIs are not just about directly making money by selling data, but that they are being seen as today's best practice. Below is a diagram of the hypothesised use of APIs vs Web Services.
I'm convinced that we will see less and less Web Services used internally and externally...but Web Services isn't dead just yet. I expect standards to play a bigger part in API Management, but API Management's emphasis on simplicity and complexity hiding will stop standards being APIs death knell.
I also believe that same simplicity push having ramifications for lots of other software products when customers realise that enterprise software doesn't *always* need to be so hard. I can already see this happening in some of IBM's latest direction statements around its ESBs.
API Management is being born into an ever-speeding, real-time world. Rich user interfaces are being written by developers with the interface in mind more than the data. This is driving simpler tools, integration architectures and techniques.
This, as they say, is the perfect storm. Where once a Web Service would be created with all of its complexity, there will now be APIs with all their simplicity and developer-led tooling. This will speed time-to-market.
This does not deny Web Services its legacy. The ESB architecture and the depth that SOA gives is not usurped by API Management. But, it does mean that in an ever-pressurised market, API Management's concepts and associated easy-to-use tooling are going to win time and again.
I believe that API-Management's simpler tooling and configuration is at the forefront of a trend to simplification of other products...but that's for another day !
About John Hawkins
John Hawkins is the Integration Practice Lead for Lightwell in the United Kingdom.
He has extensive experience in the middleware and integration stack having worked at IBM, IBM Business Partners and WSO2.
During his time as an IBM MQ architect he led IBM's Cloud strategy and architecture for next generation, Cloud Centric, Messaging.
John is an innovator and naturally "sees the big picture" which he has demonstrated not only through his work at Lightwell and previous roles, but also his large patent portfolio.