By Mark Sigda
I have to admit, as an architect with a long history in distributed systems, that I still love the concept of SOA.  I’ve also tried to make it happen (more than once) and failed miserably.
 
As a former developer, something always troubled me about SOA.  I didn’t see it at the time, but it was all so…waterfall.  SOA wanted me to learn an enormous set of SOAP-based web service standards designed to cover any scenario you might ever encounter.  It wanted me to read big fat books on SOA design patterns.  It wanted me to do big designs up front.  It needed too much of my time before I’d see the benefits.
 
I knew from painful experience that waterfall wasn’t the path to successful software projects.  Agility is key.  Agile software development grew organically from real-life experience.  I was doing “agile” before we had such a term.  Many of us were.
 
Web APIs (or just “APIs”) have evolved in a similar way: focusing on getting the job done and doing it fast.  De facto standards have emerged organically – things like REST and JSON and OAuth are common practice because they get the job done.
 
The API mentality is Agile.
 
Just as agile development puts the focus on the most important features for the business, an API is an enabler for the business.  It’s the API that presents a modern interface that supports real business needs.  It brings our focus to connections with customers, partners, and the other business units in our organizations.
 
API success stories are all around us.  You’re using a successful API every time you use Google Maps on your phone, send a Tweet, “Like” an article, or shop on Amazon – and those are just public APIs.  For every success story we hear in the news, many more are hidden from view, driving partnerships and internal business integrations.  APIs are at the heart of mobile and cloud and Big Data; of connected cars and smart grids and music and video and gaming. 
 
The architect side of me learned to be agile without sacrificing architectural integrity, and he’s seeing the light with APIs.  He doesn’t have the time to design and govern every piece of software we build, but designing the APIs?  He might actually have time to accomplish that.
 
Next time I’ll talk about the new paradigm of API Management and how it can help architects get just the right amount of control around our APIs.
 
 
Mark is a solution architect in Fort Collins, Colorado.  After a couple of decades in software application development, he’s discovering the new world of API Management with CA Technologies.