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.
blog comments powered by Disqus
Latest Blog Posts
- APIs in DFW
- Adding API Broker Under Monitoring for API Aggregators
- The Dark Matter That Make APIs Work
- Potential for API Aggregators to Provide Valuable Industry Data
- My Talk Tomorrow Night at the Dallas-Forth Worth API Professionals Meetup
- The White House Releases An Open Data Strategy
- When API Success Signals Begin Working Against You
- Get To Know Which Languages Your API Developers Are Using
- Twitters Developer Area is More Embeddable Than API
- Overview Of Backend as a Service (BaaS) White Paper
- Make Sure And Have Multiple KPIs For Your APIs
- API Enabled Toys For Our Children
- I Am Speaking At The Dallas-Forth Worth API Professionals Meetup May 14th
- How Much Do You Spend Attracting and Supporting Freemium API Developers?
- What Does The API Evangelist Do?
- Startups Need To Work Together on API Definitions
- Parse Is Successful By Truly Solving Problems for Mobile Developers
- API Commandment: Thou Shalt Not Forego Talking to a Person
- API Trends
- API Priorities
- Have You Taken A Look At AT&T APis Lately?
- Helping People Understand APIs Through Real World Examples
- Evolving Beyond API Service Providers and Tools to Goal Based API Toolkits
- APIs & The Federal Government
- After Last Couple of Weeks, It's Clear There Is Big Opportunity In The API Space