API and SOA convergence

As the technology discussion pivots to focus on APIs, teams are wondering how API and SOA converge.   Are services simply being re-branded?  Are APIs only good for mobile or external use cases?  If we publish APIs, do we need SOA?   Many architects believe that APIs do not apply to their projects or business use cases.

Both API and SOA success requires creating loosely coupled consumer-provider connections, enforcing a separation of concerns between consumer and provider, and exposing a set of re-usable, shared services, and gaining service consumer adoption.   With traditional SOA, many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams.

Over a period of six years (i.e. 2003-2009), I consulted and advised over 200 large enterprise IT organizations on how to create effective SOA strategy and SOA roadmaps.  The experience provided a battle-tested SOA strategy for moving organizations forward. After performing a SOA portfolio review and understanding their maturity, many teams were overwhelmed by the amount of IT transformation required to implement an effective SOA initiative.   All teams gained small and localized benefit by implementing ‘service oriented integration’ and web services, yet many struggled to establish a coherent architecture.

In today’s connected business world, API and SOA are the business.   How do we deliver the technology the business wants and accelerate business agility?  An effective approach must address human collaboration stumbling blocks.

Kin Lane posted a provocative and philosophical article describing “SOA vs. API: The Humans Win.”   Kin states an API focus is more effective than traditional SOA because they focus on the human side of endpoint consumption. According to Kin,

SOA …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.

Kin describes how common API attributes complement SOA by providing important SOA puzzle pieces:

API introduces newer pieces of the SOA puzzle, found within the OAuth security relationship, terms of use and privacy policies, self-service access, transparency, while also providing monetization strategies that encourage partner and developer innovation.

The real insight in Kin’s post:  API and SOA fit together, and API management can be used to advance SOA initiatives.  API management complements SOA Governance, drives service reuse, and maximizes Service Oriented Architecture success.  Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams. SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. Too often, there is little or no insight into service reuse and:

  • How to enable business functionality as an API
  • Who is writing re-usable APIs and services
  • Who is consuming APIs and services
  • How APIs and services are being used

A recent blog post and white paper describes how API management complements SOA initiatives by overcoming traditional SOA implementation limitations.

Software architects and developers can take five actions to avoid common API and SOA pitfalls, create business value, and monetize API assets:

  1. Embrace the Managed API
  2. Establish a Monetization Model
  3. Make APIs Easy for Developers to Access
  4. Employ Governance
  5. Monitor API Use

How are you making your SOA initiative a success?