Posted on 03-10-2013
As the API movement marches forward, it continues to grind against the enterprise and its legacy of Service Oriented Architecture (SOA), which increases the frequency at which people ask me, What is the difference between API and SOA? This is not a technical explanation of the differences, but a philosophical one that many will argue does not apply, but in my opinion is the dark matter around the technological and business approach of SOA, that makes API work.
Many say that a web API is just one component in an SOA toolbox. This is true. Using HTTP for an API is not that novel in itself. That is until it jumped out of the enterprise petri dish, got a little oxygen to grow, allowing the introduction of some new aspects that the industry and technology overlords of SOA would never have introduced on their own.
"Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used. In other words, there is a machine side and a people side to every technology change. The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side."
He is right. APIs moves us closer to the people side of the equation, outside the technologists comfort zone, but I would also add that it moves it outside the business and industry leaderships comfort zone, introducing more balance that has the potential to make online communities, platforms and ecosystem thrive. Matt continues to say:
"Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line."
SOA does a damn fine job of looking after the platforms (business), the developers (technology), but doesn't always provide for the best interest of the user--aka human side of the equation. APIs have allowed for valuable resources to flow around traditional IT bottlenecks, outside the firewall and be put to use by those who are potentially closer to the human problem that is being solved.
At first glance, it is easy to mistake API as just part of the SOA toolbox, but there are other nuances that bring SOA closer to the users, and solving the real problems they face, by developers who understand. In the end I don't really think it matters whether you call it SOA or API, just make sure you include the essential ingredients that have worked with "open" APIs, whether your API is public, private or evolving your partner relationships.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Is Your API More Than Just A Footnote On Your Website?
- There Are Four API Design Editors To Choose From Now
- Sales, Onboarding And Support In A Self-Service API World
- An API For Developers To Access Their API Account Information
- My Continued Support As Signer Of Oracle v Google Amicus Brief From EFF
- Join Me Tomorrow For A Panel Discussion On API Ecosystems At SF MusicTech
- I Will Review Your API On API Evangelist if You Add An APIs.json File Plus A Machine Readable API Definition
- Hey, Why Isn't This (API) Free
- Resource Base API Monetization vs. Experience Based API Monetization
- Tracking On The Red Flags For API Monetization