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
- Someone Please Build My Open, Interactive, Portable, And Visual API Documentation Toolkit
- Dwolla Using Slate For An Evolved API Documentation Experience
- Crazy Mess Of URLs Across 400 Of The APIs In My Stack
- Reworking My API 101 Content: Consuming APIs
- I Need Help To Make Sure The Dept. of Agriculture Leads With APIs In Their Parks and Recreation RFP
- What Is The Biggest Challenge For Fraud Detection API SiftScience?
- Reworking My API 101 Content: Providing APIs
- What I Spent Ada Lovelace Day Working On
- An Outside-In Approach To Jumpstarting An API Effort At The University of Oklahoma
- Exposing Dictionaries From My API Collections