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 utilizing 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.” Read on to learn about the benefits of API management over Web Services.
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.)
That definition misses as much as it says…
XML is a hard thing for human beings to read. The Ws standards are seen, by many, as bloated. The tooling around the standards is seen, by some, to be poor given the complexity of the standards. The definitions themselves are sometimes loose and thus interoperability (one of the main reasons originally cited for using Web Services) is not as good as it could be.
That aside, Web Services have been tremendously successful in what they are good at: interoperability of large enterprise systems. These enterprises liked the idea that Web Services made them vendor neutral (in theory). They also liked that having standards means cheaper developers: when something is standard it can be learnt by more people. In addition there was an implementation arms race amongst the application server vendors, who just loved selling their latest and greatest server. This was an all-round win-win.
The Case for API Management
I believe that there are three things making the case for API Management and challenging Web Services domination—and they are not all technical.
Changing Demands
The world is getting faster and faster. Consumers are demanding more and more real-time information sometimes from places where it was never being exposed before. Direct interaction with data, and just the data, in a simple way is being demanded by the new world order. We all know this (if you don’t then you don’t work in IT!)
As this data demand has increased, companies are exposing their data sets in order to encourage use of it by third parties. Often this exposing of data is done only to enable the third parties and may not have a direct impact on their own bottom-line. This has been coined the “API Economy.”
Decreasing Time-To-Market
Over the past few years digital disruption has increased. The time to bring a company from zero to $100m is decreasing. Time-to-market is more valuable than ever before as companies strive to keep up with their fresh competitors.
It’s not just the old pre-internet companies that are struggling to keep up. There is data to show that even the early internet giants are also being overtaken by new start-ups who are leveraging the social media age to their advantage.
Complexity Hiding
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.
Changing Clients
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 hypothesized use of APIs vs Web Services.
Forward Thinking
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 realize 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.
Closing Thoughts
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!
