Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 111 posts at DZone. You can read more from them at their website. View Full User Profile

Promoting Service Reuse and Maximizing SOA Success

09.12.2012
| 3149 views |
  • submit to reddit

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

Service Oriented Architecture initiative 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.   Many development teams publish services, yet struggle to create a service architecture that is widely shared, re-used, and adopted across internal development teams.

Instead of creating consistent service architecture and demonstrating service re-use, teams inadvertently produce Just a Bunch of Web Services (JBOWS) or Just a Bunch of REST Services (JBORS).   A single application often consumes a service, and a spaghetti web of One-to-One connections exists between service provider endpoints and consumers. Many teams find a SOA or REST focus may not improve IT agility, but result in simply swapping out IT toolsets, message formats, and protocols.

SOA Governance is often promoted as a mechanism to enforce best practices, guide teams towards developing service architecture, and realize IT agility.  SOA Governance focuses teams towards documenting service interfaces, managing the service lifecycle, and enforcing approval gates.  Teams often incorporate service portfolio review processes into approval gates, and the teams successfully limit redundant service proliferation.   Applying a service governance process to the service lifecycle may ensure teams properly test, document, and secure services. As most SOA governance tooling does not support consumer roles and views, interface with run-time monitoring, or define monetization rules, SOA governance programs often fall far short of encouraging consumer adoption, tracking service consumption, and illustrating business value. By publishing managed APIs, establishing API manager and publisher roles, extending the governance registry, and offering APIs through an API Store, your team will increase service re-use and enhance IT business value.

A WSO2 white paper describes benefits gained by:

  • Publishing managed APIs for consumption within your organization
  • Establishing API manager and publisher roles to foster API adoption
  • Extending the service governance registry to encourage cross-team (or cross-department) communication, coordination and collaboration
  • Overcoming common SOA anti-patterns of ‘Not Invented Here’ (NIH) and ‘Build, and Build Again’ by using an API Store
  • Following an API roadmap focused on increasing service re-use and enhancing IT business value
Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)