Book Image

Oracle API Management 12c Implementation

Book Image

Oracle API Management 12c Implementation

Overview of this book

Table of Contents (19 chapters)
Oracle API Management 12c Implementation
About the Author
About the Author
About the Author
About the Author
About the Reviewers

SOA Governance

A Service Oriented Architecture (SOA) is a strategy for constructing business-focused software systems from loosely coupled, interoperable building blocks (called services) that can be combined and reused quickly, within and between enterprises to meet business needs.

Oracle defines SOA Governance as an agile and efficient decision and accountability framework, to effectively direct and assist in realizing the benefits of SOA, while encouraging a cultural evolution in how an organization delivers SOA to the enterprise.

SOA Governance defines the interaction between policies (what), decision makers (who), and processes (how). This is shown in the following diagram:

In order to implement successful SOA Governance, organizations need to understand how to align processes, people, and tools in order to maximize business benefits.

But what does it mean to deliver business benefits? In simplistic terms, it means creating reusable assets and eliminating liabilities.

In SOA terms, assets are electronic artifacts such as APIs, XML documents (XSDs, WSDLs, or XSLTs), documents (requirements, designs, and so on), systems, and services that add measurable value to the business. For example, a service that supports multi-channel submission of sales orders delivers value in the form of cost savings by way of reuse. Should a new channel be introduced at a later date, let's say mobile apps, the existing service can potentially be reused thus avoiding the costs of defining, designing, building, and testing a service specific to the new channel.

Assets are usually electronically stored in a repository and can be associated with other assets. Throughout the chapters of this book, assets will be elaborated on further and concepts such as asset types and asset taxonomies will be described.

Liabilities, on the other hand, are duplicated, deprecated, redundant, or unused assets that no longer deliver business benefits and potentially introduce additional cost. For example, having several services delivering identical functionality represents a liability since the total cost of supporting and running each service exceeds the cost of having a single consolidated service.


It is not common to use the term liability when talking about SOA Governance. However, we felt that if there is a description to describe what adds value to the business, there should be another one to define what takes the value away from it.

Challenges that prevent organizations from realizing the benefits of SOA can also be considered a liability. The following table lists some of the most common challenges and their consequences to the business:



Lack of visibility of the existing assets and their performance characteristics

No asset reuse

More duplication (increased liabilities)

Higher costs

Tactical projects over strategic solutions

Projects deliver short-term benefits, but bring no enterprise-wide value or long term benefits

Poor decision-making and lack of accountability

No sense of ownership makes decision-making, policy enforcement, and accountability almost impossible

Low quality assets which becomes difficult to maintain and change

Assets are difficult to change and their cost is high. Changing an asset is considered risky and costly, which prevents new and innovative solutions from being introduced

Poor estimation techniques and inaccurate planning

Project overruns, ending up costing more than originally budgeted

For SOA Governance to deliver real business benefits, it is imperative to establish the goals and objectives of the SOA Governance effort. These need to be aligned with the goals of the business and its I.T strategy. Without clearly aligned objectives, an SOA implementation can be perceived as failing to deliver any meaningful business benefit.

All such objectives should be supported by clearly defined success factors that are achievable and measurable prior, during, and after the implementation.

The following principles should be followed when defining the objectives of an SOA Governance implementation:

  • Business value: Ensuring that the project investments yield business value

  • Alignment: Keeping the SOA aligned with the business and architecture, and in compliance with the business and IT policies

  • Business agility: Gaining visibility into your SOA for more rapid decision-making

  • Risk reduction: Controlling dependencies, managing the impact of change, and enforcing policies

  • Cost savings: Promoting consolidation, standardization, and reuse

Once the objectives have been defined, these should be well documented and presented to the key stakeholders within the business and IT departments to obtain the desired level of sponsorship. This sponsorship is critical to achieve the required level of assistance from different departments in order to develop the maturity assessment and roadmap, and to secure any extra funding, if needed.