Breaking the SOA Trust Barrier Through API Management

By Chris Haddad, WSO2

For many enterprises, trust, or lack thereof, remains the most significant barrier to service-oriented architecture (SOA) adoption.

An SOA initiative is meant to knock down internal barriers and help an enterprise evolve from separate silos of technology and information into a leaner, shared-service organization. However, many application development leaders struggle to create a consistent service architecture that is widely shared, reused, and adopted across internal development teams. Instead, these teams often go rogue, ignoring SOA procedures and swapping out IT toolsets, message formats, and protocols to build their own solutions, which ultimately fail to support enterprise growth.

While SOA governance is meant to prevent this destabilization from happening, the tooling, which is typically promoted as a mechanism to enforce best practices, often fails to encourage consumer adoption or even illustrate business value. As a result, the use of SOA governance software is not yet widespread, despite being arguably the greatest indicator of whether an organization is committed to SOA.

An SOA Governance Alternative

In the absence of an actual SOA governance implementation, API management offers a built-in, lightweight alternative to increasing SOA satisfaction. Utilizing API management as a governance tool will result in accelerated service portfolio development while quantifying the business value of any SOA.

An API management system builds confidence in an SOA by monitoring usage, securing and protecting the API, managing access keys, and automating protocols like quality of service (QoS) enforcement. A managed API is actively advertised and subscribe-able, available with an associated, published service-level agreement (SLA), secured, authenticated, authorized and protected, and monitored and monetized with analytics.

While application servers, enterprise service bus nodes, or data service hosts are all viable API publishers, API gateways are the preferred managed API delivery mechanism. However, an SOA infrastructure often already includes an enterprise service bus (ESB) that can effectively enable API development and deployment. By decoupling complex mediation from the gateway, teams can readily scale the infrastructure and independently evolve a standard, simple API from complex, back-end implementation services.

Applying four API management practices will help application architects and developers build confidence and trust in their enterprise SOA initiatives.

Monetize

We typically think of monetization as an externally focused activity that only affects partners and customers. However, applied to internal development teams and IT initiatives, monetization legitimizes the API, establishes how it supports a business return, and provides structure around its use.

Development partners can’t trust an SOA that doesn’t have the infrastructure to establish or even support business return. Legitimize your API by establishing an API monetization model and determining API availability policies and monitoring techniques.

One option is to establish a charge-back model for the API, for example, assigning a cost per API call or business transaction. Another is to employ a show-back mechanism. In many cases, APIs created for internal use to support your SOA do not map back to traditional revenue streams, but instead offer portfolio efficiency or business agility. For example, the value may be that 15 other departments in the organization made 3 million calls against an API during 2011.

In either case, the first step is to analyze API usage patterns and determine how to best monetize API assets. From there, determine what the show-back or charge-back mechanism will be, as well as how to perform investment recapture activities.

Simplify Access

To overcome common SOA anti-patterns of “not invented here” (NIH) and “build, and build again,” provide a self-service, resource-rich environment that makes it easy for application developers to browse, publish and even subscribe to APIs.

When it comes to exploring, evaluating and subscribing to available resources, an API store offers a more intuitive alternative to traditional portals. By providing well-organized support channels and API documentation, developers can “try before they buy.” This structured API exploration environment rapidly reduces the time and effort required to evaluate and integrate API resources, and the environment will ultimately encourage the growth of development partnerships and interactions across an enterprise’s IT teams.

Enforce Policies and Processes

Traditional SOA and integration platforms enable rapid development, but they don’t encourage cross-team (or cross-department) communication, coordination and collaboration. Development teams commonly operate independently and autonomously.

Often, instead of creating a consistent service architecture and demonstrating service reuse, 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.

When publishing an API for consumption, governance keeps the environment from devolving into chaos by managing people, policies and processes. API management systems support SOA initiatives by enforcing operational controls on essential development lifecycle functions, API versions, and runtime technologies.

For example, a team may desire to enforce a specific message payload or interaction pattern. If an API maps back to a mobile phone, a team might want to encourage a simple JSON format and minimize the number of interactions. By contrast, efficient machine-to-machine interaction may require transferring larger datasets via XML payloads. Understanding the system that consumes the API makes it possible to create the optimal API interface. This, in turn, helps to accelerate service portfolio development while quantifying the business value of the SOA.

Monitor

No SOA or API governance implementation is complete without monitoring. The best API ecosystems and platforms include measurement tools, metrics, and activity repositories that report back on usage, ecosystem traffic, and referral traffic.

Applying a service governance process to the API lifecycle will help ensure that development partners properly test, document and secure services. Using lightweight proxies to monitor API usage and shape traffic will enable a clear separation of concern between the consumer interface contract and back-end service implementation.

API management is a strategic component within any successful SOA initiative. Application development leaders can build trust in their SOA architecture and encourage service reuse by following these four key steps to creating loosely coupled consumer-provider connections, enforcing a separation of concerns between consumer and provider, exposing a set of reusable shared services, and gaining service consumer adoption.

I recently developed a white paper that examines the concepts presented here in more depth. You can download it here.

# # #

Chris Haddad, WSO2 vice president of technology evangelism, works closely with developers, architects, and C-level executives to increase WSO2 technology adoption, improve the middleware platform, and maximize customer value. Previously he was a research vice president at the Burton Group and Gartner. In these analyst roles, Chris led research teams in advising Fortune 500 enterprise organizations and technology infrastructure vendors on adoption strategies, architecture, product selection, governance, and organizational alignment.