APIs and SOA Services

Introduction

We’ve been talking about Service Oriented Architecture (SOA) and the services that are at the heart of the concept for years now.  A large body of standards, tooling and best practice has evolved over this time, and SOA is now considered a relatively mature discipline.

Web APIs, at least in the sense that they are currently being discussed, are a somewhat newer phenomenon.  There is clearly a lot of overlap between the two concepts, but just how different are they really?  What do we need to do for APIs that we weren’t already doing for our SOA services?  What can we reuse from our SOA programmes?

Similarities

We’ll start with the similarities between SOA and API Management.

First of all, they are both about exposing functionality from one computer system to another through a well-managed published interface that works well with the modern Internet technologies.  They both focus on managing the long term costs of ownership through standardisation, monitoring and control, loose-coupling and facilitating reuse.

There are remarkable similarities between SOA management products such as the Enterprise Service Bus and API management products.  In many cases, a vendor’s API Management product suite contains many of the same components as their SOA product suites.  In addition, established vendors often group their API Management products as part of their overall SOA product portfolio.

Differences

Probably the biggest difference between web APIs and the more mature SOA service concept is that APIs are generally public and published.  The SOA services that enterprises have traditionally built have largely been consumed internally, or by a limited number of known partner organisations.

• You don’t know in advance how many consumers of your API you will have
• There are probably a lot more of them
• You often don’t have a direct relationship with your API consumers
• You can’t really tell those consumers what to do

These are all important differences, and will require a change in approach to some degree from what we have been doing so far with SOA.  

In terms of maturity, SOA and the products that support it have been around for ten years or more, whereas API Management and API Management products are still a rapidly evolving “new” discipline.  This has allowed API Management tools to avoid some of the issues that SOA has seen, but there is also a risk that it is failing to accommodate some of the lessons learned as well.

A more technical difference is that enterprise SOA is typically based on SOAP Web Services, whereas web APIs are more likely to use RESTful services.  However, both disciplines can use either interface type, so this is less of a difference than it might seem.  Bear in mind that SOAP interfaces are a lot more constrained than RESTful interfaces; is this level of constraint an example of a SOA mistake that API management has avoided, or of a SOA best practice that API management has failed to learn from?

While some people, particularly product vendors, claim that SOA is a set of tools to be purchased, most architects, analysts and IT decision makes realise that it is more about the way an organisation operates than the specific tools used.  In organisations with effective SOA programmes the discussions tend to focus on governance, maturity models, roadmaps and centres of excellence.  API Management still seems to be very much focussed on the tooling and products used. Is this a sign that API Management is a much simpler problem for which “canned” solutions are appropriate, or a symptom of the lower level of maturity in this space?

Conclusions

It is clear that there are significant differences between API Management and enterprise Service Oriented Architecture, but that there is also a lot of overlap.  Organisations looking to strengthen their API Management strategy should be wary of constraining that strategy by assuming that their existing SOA tooling and approach is sufficient for API Management.

At the same time, organisations with a mature SOA initiative - or that have already embarked on a programme of SOA adoption - would be advised to look to reuse as much as they can and to only change what they can demonstrate needs to be changed.  Assuming that an element of a SOA strategy or platform is not necessary for API Management simply because no-one is talking about it in that context (yet) has the potential to cause significant pain and embarrassment in the future.

The best approach is surely to assemble a team with the experience built from successful SOA adoption, but with the open minds and agility required to adapt and change what they know to accommodate the new challenges and opportunities inherent in API Management.

With the right team in place it won’t matter whether we are in a brave new world or just rediscovering what we already knew.