It’s death came furiously and quick, like an earthquake shaking the carefully constructed buzzword tower engineered by Enterprise software marketers around the world. Anne Thomas Manes proclaimed the death of SOA back in 2009 in her seminal blog “SOA is dead; Long Live Services.” Yet here we are in late 2013, over four years later still wrestling with this undead terminology. We have analysts publishing new reports referencing SOA, popular blogs with references to the dreaded “SOA-saurus” and we have companies with SOA in their name (still), and while #SOA now denotes the hash-tag for the popular show “Son’s of Anarchy” there was in fact a time when this term was heralded. With all of the recent activity and ‘fire’ in the API Management, let’s resolve to engulf and bury SOA once and for all.
SOA promised to be the goose that laid a golden egg for Enterprises, and then we killed it. Whoops. So what’s a good Enterprise to do now? APIs and API Management are the rage, yes, but there is a lot of confusion out there. There is talk of open APIs, public APIs, and private APIs. Talk of developer communities and partner developers. There is talk of governance (this word is just a little bit too close to SOA, it scares me) and policy life-cycles (hold me back from the excitement). And then there are artificial categories created. Some say that if you are doing internal stuff that’s “SOA” and if you are doing external stuff, that’s “APIs.” I’m not so sure… ever heard of WS-Security for external B2B WS-* exchanges?
Or, if you’re doing “business agility” and “application integration”, well that’s “SOA” and if you are doing developer communities, well, *that’s APIs*. Or, if its social and cool, that’s an API and if its boring and ‘Enterprisey’, that’s SOA. All of this is hogwash. Let’s agree now that Anne had it right – long live services.
And let’s also agree that while the term “APIs” is a bit jargony (is that a word?) and thumbs its nose at CS degree holders everywhere, the term is infinitely more descriptive than SOA. Here comes the popular culture Netflix-analogy: If orange is the new black, APIs are the new SOA, but APIs are a long way from a low security women’s detention facility. Furthermore, API Management and services should run deep within the organization; an artificial split between SOA and APIs is nonsensical. Amazon, in their famous example of adopting a service model simply declared that their internal systems would have published, stable interfaces or the developers would be fired. That’s what we call a services strategy folks. The concept of API Management is more descriptive and includes all of the important concepts of SOA. Web services are APIs. Call them APIs, don’t call them SOA unless you want to artificially date yourself. Remember: In the tech world, 4 years is like 40 years in real-life, so do the math. It’s time to bring these two worlds together, to forcefully bring these two old friends to the bar and agree to be the same thing and share a drink. Don’t be fooled into a false dichotomy.
It’s an unfortunate aspect that the history of this subject brings these categories which are hard to shake. Let’s talk in plain language about what is needed.
Enterprise API Management Requirements
Enterprises need to:
- Turn existing business assets into well-defined, stable interfaces, suitable for internal, partner, or public consumption.
- Provide scalability, security and control for these interfaces and corresponding back-end systems
- Ensure compliance for data transferred through these interfaces
- Publish interface definitions and accelerate use among internal, partner or public developers
- Deploy such infrastructure in a flexible, yet cost-effective means
And lastly, item 6: Manage change throughout items 1 through 5.
What about API lifecycle? That’s covered in #1. What about hosting choices? That’s covered in #5. What about SOA registry/repository? That’s covered in #4. What about Hackathons? That’s covered in #4. What about reuse? That’s covered in #4. What about OAuth? That’s covered in #2. What about a developer portal? That’s covered in #4.
The truth is, once you boil down the requirements into the essentials, it’s easy to see that SOA and APIs live rather harmoniously. It isn’t ‘decisive’ that REST is always easier than SOAP. What if you’ve been using SOAP for the last 10 years in your organization? The costs to rip and replace could be quite expensive. Similarly, it isn’t ‘decisive’ that JSON should be the format for all API calls – what if you aren’t (gasp) exposing data to a mobile application? The answer is both. Enterprises should use whatever weapon is available to get the job done and if they want real business agility, ditch the jargon.
This is the way we see it at Mashery with API Management. We want to help Enterprises get moving on their projects. We can help you with your progression to deploying cost effective API management solutions – no matter how they are deployed and where you are across items 1-5 above. The progress of APIs becoming a larger part of the daily lexicon is happening and has happened. Just the other day I heard my non-technical sister-in-law talking about the unofficial Vine API. When members of the general public understand your job, your ship has come in. Mashery can help your ship come in with API Management today.