Skip to main content

Making SOA governance fit your organization

SOA governance is a like a stimulus package for successful SOA implementations. Inadequate governance might be the most widespread root cause of SOA failure. When properly applied, SOA governance provides the key aspects of Business/Information Technology (IT) alignment and organizational change needed for new SOA deployments. In addition, SOA governance enables the process and framework changes to ensure your SOA environment can become productive as quickly as possible.

The new book, "SOA Governance: Achieving and Sustaining Business and IT Agility" describes both a framework and method for applying SOA governance in your organization and making it work given your organization’s idiosyncrasies. To help you get started, book co-author Robert Laird introduces in this article these practical aspects of a governance strategy, based on the authors’ extensive observations of successful practices in the field:

A model for entities that need to be governed

SOA Governance extends IT Governance as enterprises increase their level of services. Ideally, SOA is an enterprise initiative that crosses boundaries and delivers on the business and IT strategy and goals. To this end, it is important to have a model to assist the governance practitioner in specifying each of the aspects of what is being governed. As governance practitioners, it is important that we take a more structured approach to the art of governing.

In this mode, let’s consider a governance paradigm to assist the governance practitioner in specifying each of the salient aspects of the governed entity. The governed component is the entity requiring governance. That governance is guided by policies, controlled by standards, managed by a responsible party, implemented by some process or procedure, supported by a mechanism or method, and monitored by a set of metrics as shown in the figure, the SOA governance paradigm.

SOA governance paradigm

A framework to guide the SOA governance transition

Every good SOA practitioner should use a governance framework as a starting point in their planning process. This allows the practitioner to get the governance “big picture” and identify the areas that are of immediate importance, as well as those that can be put off until later or even ignored for your organization. It ensures that errors of omission do not occur. The book identifies a set of governance domains and capabilities in guiding the governance transition plan and goes into great detail about what these are. This brief description can help you get started.

The Plan & Organize domain covers the governance for planning and organizing of the SOA journey. SOA changes the way in which IT decisions are made. Services have to be defined that are enterprise-ready and usable across the entire enterprise, not just for a single operating unit. SOA requires new models for defining ownership of the service assets, and new mechanisms to control and govern SOA activities. The Plan & Organize domain is also concerned with answering the questions: “Is the enterprise organized in the optimum way to implement SOA? Do we have the right balance of skills, and can we implement effective SOA governance without becoming too bureaucratic?” A total of 11 governance capabilities are described in the book for this domain.

The Program Management Controls domain is concerned with the enterprise planning, and with governing the implementation of SOA at the level of individual development projects. It is concerned with questions like: “Will this project benefit from an SOA approach? How do we assure that the additional activities needed to create reusable services do not adversely impact the project budget or scope of the project that creates them; are resources being managed in an optimal manner; are vendors being managed to common services standards?” A total of 6 governance capabilities are described in the book for this domain.

The Service Development domain defines activities that govern the design of individual services and automated business processes. Enterprise models that describe business entities and business processes are critical inputs to service development. Since the eventual portfolio of services will become a major company asset, governance of the service modeling activities is especially important, as the success of the implementation of SOA is directly dependent on choosing the right set of services and implementing them effectively with proper governance controls. A total of 6 governance capabilities are described in the book for this domain.

The Operations domain covers the activities that govern operational phases of the service lifecycle. Governance of these activities is critical to ensuring the functional and technical quality of all services and automated business processes that the Organization produces. A total of 3 governance capabilities are described in the book for this domain.

No one-size-fits-all governance

Cantor and Sanders describe in the article “Operational IT governance” the suitability principle, which states that “the needs of the organization determine how the level and style of governance will be tailored.”

The book identifies and discusses 9 levels of control that the practitioner should consider while identifying the right level of control for a governed entity. They are, in increasing order of control:

Governing the service factory

SOA employs significantly more standardization than traditional application development, and SOA Governance must strive to encourage and support this standardization. Services have interfaces defined in a standard way, they execute in standardized operating environments, and use a common technical infrastructure. A single common SOA infrastructure provides security, logging, event handling, data transformation, and physical connectivity, which, in traditional application development, each application had to provide independently.

In much the same way that standardization of components led to the industrial revolution, such standardization of components can enable services to be constructed using a manufacturing or assembly approach – a software production line or service factory to create all the necessary work products.

This engineering approach appears to address many of the issues that beleaguer traditional software development, such as cost, consistency and reliability, and product flexibility and time to market.

Solving major issues of traditional software development

    Cost: Software may be intangible, but it is certainly costly to develop new code, and even more costly to maintain it once it has been created. Despite the focus on methodology and tools over the last two decades or so, most software development still occurs using an approach that is closer to a craft or cottage industry than an assembly line. Because services share much more common infrastructure components and development tools than do traditional applications, it is much easier to apply a production engineering approach to their development.

    Consistency and reliability: This is often a major problem with software development. Estimation of total development costs is problematic; cost or time overruns are common; and errors, malfunctions, performance, or response time issues are frequent dilemmas. Using a production-line approach can enable incremental quality checks to detect functional or performance issues with services early, before the cost of remedy escalates.

    Product flexibility and time to market: The purpose of IT systems is to support the ability of each organization to operate successfully, either through automated support of business tasks or providing functionality that is directly saleable to consumers. Every organization, whatever the industry, has a need for agility of its internal systems and processes to be able to respond to competitive threats or opportunities, or to cope with legislative changes in a timely manner. In many organizations that the authors are familiar with, a perceived inability of the IT systems to change as rapidly as the business environment is a major cause of contention between the rest of the organization and IT. Improving that relationship, through showing an enhanced ability of IT to support business agility, may well be the most significant potential benefit of SOA for them.

So, using a production engineering approach to achieve enhancements to the software development process, especially the service development process, is something that virtually all organizations should embrace. Of course, one needs the right governance to do this and the book discusses typical control points that will help you govern your service factory.

SOA governance goals and measurements

The IT adage “you cannot manage what you cannot measure” is applicable to SOA governance as much as, if not more than, it is applicable to any other discipline within IT. The promise of SOA is to align IT initiatives directly to the business goals, vision, and drivers; foster reusability; and drive down total cost of ownership (TCO). The measurements of the results of the attainment of such alignment, hence, assume a lot of importance. SOA governance is the framework that incorporates such measurements as one of its key responsibilities.

Goals remain merely of a theoretical significance, unless there is a mechanism to measure the ability of the execution team to meet the goals. Measurements of goals along with a supporting management structure help an enterprise to judge the effectiveness of the institutionalization of a given discipline. SOA governance, like any other discipline, needs to first define a set of goals that it strives to achieve. A base set of metrics should also be defined to measure the goals that the governance framework has defined.

Michael Treacy and Fred Wiersema, in their book, “The Discipline of Market Leaders,” postulate that a fundamental tenet of success for any company is to identify its strength and then define a value proposition around that strength. Using a top-down approach, we start with the operating model and then identify, derive, and develop the SOA Governance goals from them. Taking a cue from Treacy and Wiersema’s work, we see that they define the following set of business focus areas for each of the operating models:

Without going into the details of any specific operating model, let's look at how we can derive some SOA Governance goals, metrics, and measurements from each of them.

For Operational Excellence, in order to ensure the lowest price, here is an example of decomposition and a metric derivation technique:

One can derive multiple IT goals and their metrics for a given business goal. For example, for the same operating model and the business goal, we can derive the following:

For Product Leadership, one of the value propositions is to be able to come up with and sustain the best product in the market. The following can be derived:

For Customer Intimacy, one of the value propositions is to sell products and services that cater to specific customer needs. The following can be derived:

Use SOA governance to reduce costs, not increase overhead

The SOA Governance function does not need to be large, and the governance of SOA need not be onerous if it relies on collaboration and cooperation. Implementing governance should be about reducing cost, by reducing unnecessary work and improving value and quality, rather than about adding unnecessary overhead.

If you are a practitioner, manager, or executive tasked with the job of making SOA benefits real in your organization, you may find it helpful to read the book to find out more about the framework and method for applying SOA governance in your organization. The book also contains a case study with insights for an organization faced with real-world problems and the strain between strategic intent and near-term goals.

By Robert G. Laird, co-author with William A. Brown, Clive Gee, and Tilak Mitra of “SOA Governance: Achieving and Sustaining Business and IT Agility.”

About the book authors: William A. Brown (Raleigh, NC) is a Master Certified Executive Architect with IBM Global Business Services Enterprise Architecture and Technology Center of Excellence and the SOA Center of Excellence. Clive Gee (UK), retired Senior Solution Architect at IBM Enterprise Integration Services group, has designed and deployed solutions involving technologies such as XML, XSLT, SMS, Web Services, and SOA. Robert G. Laird (Colorado Springs, CO) is responsible for supporting and leading SOA governance and architecture engagements for worldwide IBM customers. Tilak Mitra (Coconut Creek, FL) is a Senior Certified Executive IT Architect with IBM Global Business Services in the Enterprise Application Development group.

Contact IBM


Considering a purchase?

Or call us at:
Priority code: