SOA Governance overview
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 re-used 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).
In order to implement a 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 re-use. Should a new channel be introduced at a later date, let's say mobile apps, the existing service can potentially be re-used 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 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.
Tip
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 as a liability. The following table lists some of the most common challenges and their consequence to the business:
|
Challenge |
Consequence |
|---|---|
|
Lack of visibility of the existing assets and their performance characteristics. |
|
|
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 that become 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. |
Projects overrun, ending up costing more than originally budgeted. |
Understanding the goal of SOA Governance is an important step forward; however, it is not a guarantee for success. A successful governance implementation must tick several boxes and answer several questions, such as:
What artifacts are required to deliver governance? It is vital for the success of a governance implementation to have a clear understanding of the artifacts to be delivered, what their purpose is, and what value they add to the overall governance implementation. The main artifacts are:
SOA strategy: It defines the goals and objectives for adopting SOA in the enterprise. Moreover, it defines the success criteria needed to ensure that the business benefits are realized by the adoption of SOA.
SOA reference architecture: It defines the core building blocks for an SOA solution.
SOA policies and standards: Guidelines such as patterns, anti-patterns, conventions, and best practices to be considered or adopted when designing solutions.
Tip
Policies define principles and assertions to be evaluated when making decisions. Standards define clear guidelines on what is or isn't allowed. Policies are usually but not exclusively created to enforce standards.
SOA Assets and taxonomies: It defines all the SOA Assets available in the enterprise, their description, and type.
How can it be delivered? The necessary tools, processes, and procedures required to deliver governance and its objectives. The key artifacts that should be created or influenced are:
SOA Roadmap: It defines the activities required to deliver an SOA strategy and milestones for implementation. This topic will be covered in more detail later in the chapter.
Tip
A roadmap must set realistic targets, ones that are achievable based on the organization's current maturity state. Not doing so means that wrong expectations will be set for the business, inevitably leading to failure.
Design-time and Runtime governance: These two fundamental concepts will be described in detail later in the chapter.
Who is responsible for delivering it? A description of all the participants required to deliver the artifacts previously listed, including their roles and responsibilities.
