Now more than ever, the app economy has led to organisations having to be much more agile and reactive than they’ve ever been before to stay competitive. In the good old days, you might have had the luxury of 6-12 months to take an idea through to delivery – today most companies would expect delivery in 1-3 months!
We still have all of the enterprise data and systems to integrate that you would expect, but now we have to also worry about APIs and potentially rapidly changing mobile apps, perhaps including third party providers.
It’s impossible to talk about APIs without addressing the necessary complexity associated with them. Building new distributed systems is understandably complex. But who owns that complexity? It’s a simple question but it can be deceptively tricky to find a consensus.
The new complexity
If you consider the ‘Old World’ way of working, when SOA was king, API has provided us with much simpler, basic standards. We’ve moved away from the plethora of Web Services standards and focused on standards such as HTTP, REST and JSON. We also have simpler data models that are self-describing and focused on providing what the consumer requires, not what the provider needs.
So APIs make everything smooth sailing right?
Well, we have to remember the need to add in new standards to replace some of the WS standards we've lost, such as OAuth2.0 and OpenID for security authentication and authorisation. Plus, we’ve added a few things that were not even there before, such as social integration and developer portals.
So really, it’s still looks just as complex. I thought that APIs were meant to make things quicker? Let’s investigate further.
Fig 1. Complexity responsibility for SOA
With SOA, your organisation might choose five or six out of the hundreds of WS standards to implement and your service consumers will need to learn those in detail to consume your service. When those consumers have to integrate with another provider, the chances are that the new provider chose five or six different ones, so they have to learn those too.
Also, services tend to be exposed with complex data formats, sometimes representing some sort of common or canonical enterprise format you have designed. The consumer is forced to understand this too so that they can create and consume the messages.
In your organisation, once you have understood those standards in their entirety, you often need to implement full stacks to process them.
Fig 2. Complexity responsibility for API
On the other hand, in the API World, the consumer is king and simplicity of the interface is paramount.
We still have lots of complexity with the new standards, such as OAuth2.0 that we mentioned earlier. But now the provider of the APIs has to handle as much of that complexity as possible to make the consumer’s job easier – shifting the ownership of the complexity heavily towards the provider:
In OAuth2.0 for example, the consumer need only call a simple RESTful API, and then ensure the token returned is used to call protected APIs.
However, the provider is responsible for implementing the non-trivial complexity of the OAuth2.0 server standard – storing client ID, tokens, validating, expiring, scope checking, etc.
In my next blog, I’ll be looking at how APIs play a role in digital transformation, and where your organisation should be focusing to make the most impact on your agility.