Service Oriented Architecture Governance: The Basics

Organizations that choose to adopt Service Oriented Architecture (SOA) quickly realize that Governance must be established quickly in order to manage a successful SOA program or initiative. SOA Governance, however, has been difficult to establish successfully in many organizations for a variety of reasons.

To understand SOA Governance (and how Governance can be successfully initiated in your enterprise), there must be a clear understanding and definition of enterprise SOA Governance Principles and an operational, holistic SOA Governance Model. Clarifying Governance Principles (creating a common, shared definition of SOA Governance in an organization) and creating an organizational Governance Model will provide the necessary foundation towards more advanced Governance activities.

This article will address the most basic challenges in establishing SOA Governance. First, it will attempt to explain to define SOA Governance by comparing and contrasting "strategic governance" and "tactical governance". Next, a SOA Governance Framework will be presented that can be customized for an organization in any maturity stage. Finally, this article will provide actionable steps your organization can take to move forward in its SOA Governance efforts and initiatives.

SOA Governance is more than a group of people who meet once a month (or less) to talk about SOA topics, create enterprise SOA Policy, and then retreat to SOA Ivory Towers. In fact, establishing SOA Governance can be a challenging, disruptive, and destructive force in an enterprise's SOA efforts.

For years, SOA evangelists have asserted that the most challenging obstacle in establishing SOA Programs and initiatives has been the cultural and political obstacles that must be overcome for success to be supported by a collective group. Consequently, it should come as no surprise that establishing SOA Governance - or organizing a group of SOA domain owners in an effort to establish enterprise SOA policy - would be a (if not the most) significant challenge that an organization will face, early, when establishing an enterprise SOA program. After all, Politics is inherent in Governance.

Inevitably, political battles will, in most cases, determine who wins specific SOA domains - and specific SOA Governance responsibilities. However, many battles can be minimized and isolated (and organizational damage averted) if there is a clear boundary of domain areas and a clear definition of what is being fought for (in efforts to create SOA policy). The purpose of this article is to provide such foundations to the reader.

SOA Governance: Strategic vs. Tactical

Surprisingly, to some, the group(s) that will succeed in establishing SOA Governance may not be that one group that calls itself the "SOA Governance Committee". In many organizations, "that" group tends to be very strategic and lacks the necessary tactical understanding of SOA Governance to support all enterprise SOA activities through their full lifecycle. In fact, the group(s) that will succeed, organizationally, will be the group that can define what SOA is in the enterprise, how SOA will be supported, and can articulate, clearly, where they fit in a SOA Governance Model. Having clear definitions and models around Governance will allow SOA discussions and decisions to be pointed, clear, and understood - keys to avoiding organizational disruption.

Yes, you read that right. There will be multiple groups in most organizations that provide strategic and tactical governance. In fact, many organizations are adopting tiered governance models. While some are complex (perhaps too complex), this approach can be simplified if an organization can understand that SOA Governance will need two things, primarily.

Organizations will need a representative community of real SOA practitioners that can provide input to SOA conflicts and decisions. This group provides "Strategic Governance" and is often the first group to be implemented in an organization's SOA Governance activities. After all, this group controls what enterprise policies should be, what platforms get to be deployed, and what constitutes the enterprise's SOA Reference Architecture. Those are big decisions.

Organizations will also need a group of domain SOA practitioners that will determine lower-level (or more granular) policy. This group provides "Tactical Governance" and is often the group that is implemented organically throughout the organization as SOA Pilots, Projects, and Programs emerge (often with sponsors outside the "Strategic SOA Governance" group). Therefore, this group is often more implementation oriented, tied to deliverables and business results, and is often the group that struggles most with falling in line with "strategic" governance efforts.

To be clear, "strategic governance" often results in a set of ideal enterprise SOA policy based on cutting-edge technology, evolving standards, and the latest and greatest markitecture (marketing architecture) that the vendors promise will be ready to ship "next quarter". On the other hand, "tactical governance" results in which policy gets configured in which SOA platform for specific integrations. Both must be aligned for Governance to occur.

Let's conclude this discussion with an example. In FastCom, a fictional communications company, there is a need to integrate with SpeedyCable, another fictional communications company, in order for both companies to bring a new product to launch in select markets. Consequently, a B2B integration is required. FastCom's "strategic governance" group has its ideal enterprise SOA architecture and policy. SpeedyCable has its ideal enterprise SOA architecture and policy. At their "Integration Kick-Off" meeting, both enterprises present their "strategic SOA policies". Chances are, the two organizations' capabilities and policies don't align.

Then, those architects leave and the domain owners are left to negotiate those policies to create a "tactical" integration plan. As the two development teams and project managers meet, weekly, they review Security, Schemas, Standards, data transformation requirements, and a host of other integration requirements. While the "strategic governance" groups determined what policy was and where policy can be viewed, it is likely that the "tactical governance" groups will determine which policies apply, where policy is created, and where policy is enforced.

Therein lies the distinction between Strategic Governance and Tactical Governance - how each embrace enterprise SOA Policy.

Six Pillars of SOA

Another key to good Governance is the holistic understanding of the components or pillars that support a mature SOA Program. While an organization's SOA program can certainly exist with only the basic support mechanism(s), a mature program will require and provide more support as the load on an enterprise's SOA program increases. Each SOA Program area requires a different approach to SOA Governance and affects "policy" differently.

It should be noted, here, that Policy is the key to SOA Governance - as a SOA Governance effort will define what SOA enterprise policy is, who creates SOA policies, where SOA policies are stored, how SOA policy gets updated or changed, where SOA policy can be viewed, what systems / tools are used to enforce SOA policy, and who the groups are that enforce SOA policy manually.

That said, the Six Pillars of SOA all support SOA Policy in some way. Let's briefly introduce the Six Pillars of SOA:

1. SOA Operational Lifecycle Model
2. SOA Organization
3. SOA Process
4. SOA Service & Integration Portfolio
5. SOA Tools
6. SOA Technologies

The Pillars of SOA can be seen as supporting "top down" or "bottom up" SOA program development. Understanding these pillars will clearly define what "top down" and "bottom up" SOA Governance approaches actually mean. "Top Down" SOA Governance typically begins as "strategic" in nature and starts with a model and some projects. Working downward, a "strategic" governance organization can define the people, processes, services, tools, and technologies that will be used to support the enterprise's SOA program. Working upward, a "tactical" governance organization can define an SOA program by the technologies, tools, and services it creates. Typically, SOA organizations that are "grass-roots" and the result of individual, domain led service-oriented efforts are "bottom-up". Very few organizations create a strategy prior to individual departments and business units piloting and prototyping SOA technologies and tools, thus adding complexity to establishing Governance to enterprise SOA initiatives.

For that reason, we'll start with a "top-down" SOA Governance approach and define a SOA Governance Lifecycle Model, first.

The first pillar of SOA is an enterprise's Operational Lifecycle Model. A "SOA Operational Lifecycle Model" is simply the model that supports and defines an enterprise's SOA efforts. It should be noted that SOA Governance is a pillar in itself. In fact, it is this model which specifies that Governance is, indeed, a critical component of any SOA Program or effort. Typically, the following domains are defined (and then processes, organizations, tools, and technologies are mapped to each domain):

1. SOA Portfolio Management
2. SOA Planning
3. Service Development
4. Consumer / Client Development
5. Integration Configuration
6. SOA Platform, Service, and Integration Production Support
7. SOA Program Promotion & Marketing
8. SOA Reporting & Analytics
9. SOA Governance

A typical SOA Lifecycle model will not be further defined, here, but can be researched more at: http://en.wikipedia.org/wiki/SOA_Lifecycle.

The second pillar of SOA is an enterprise's "SOA Organization". This pillar is the people and the way people are organized to support a SOA Program. This area can be defined by "function" or by "organization". But, it is best to define the "functions" that the people will be supporting through manual efforts and then loosely couple those functions to organizations. Typically, organizations are evolving at a constant rate. Approaching "Organization" in this manner will allow flexibility as the "functions" that people perform in a SOA Governance effort will not change, but the names and titles will. Typically, it is this "organization" definition that will define who has input to SOA Policy discussions, who makes SOA Policy decisions, who configures SOA Policy, and who can view SOA Policy in the organization.

The third pillar of SOA is an enterprise's "SOA Process". This pillar is the way in which SOA work gets done. It is critical that these processes map to the SOA Operational Lifecycle Model that was just introduced. Having key processes around building services, configuring integrations, building clients, planning for services, adding services to a registry / repository, how policy gets created / updated, and production support for SOA platforms and tools will enable an enterprise to define who does what work, what artifacts are used in the process, where hand-offs occur in the process, and how long each step should take in the process. In essence, when documenting an organization's SOA Processes, Governance is established in a measurable form. Decision points in the process can become "Governance Gates" and should align to the "strategic governance" bodies and review sessions. Establishing "SOA Process" is critical in maturing organizations from "departmental SOA" to "enterprise SOA".

The fourth pillar of SOA is an enterprise's "Service & Integration Portfolio". This pillar defines the services that the enterprise has deployed, planned and conceptualized as "product offerings". This pillar aligns enterprise services to enterprise functions where the service becomes an entity or representation of a "unit of work" that the business performs. Governance in this area regulates who creates and supports services and when they are released to support the enterprise. In essence, this area defines a policy around when services get created and what justifies services being developed. This is often a forgotten area and is typically the last to be developed. It is here that "bottom up" and "top down" efforts converge in an enterprise that has both kinds of efforts.

The fifth pillar of SOA is an enterprise's "SOA Tools". This pillar is simply the tools or systems that an enterprise has implemented to support its SOA efforts and initiatives. This includes the conceptual reference architecture as well as the physical implementation of systems within the architectural blueprint that the SOA infrastructure requires, hopefully in response to a set of well documented and researched needs. Too often, we see companies buying tools because of perceived needs vs. an actual implementation plan. Having documented processes that the systems will need to support and the people that will be consuming those tools for specific SOA will provide an enterprise the "use cases" and "functional requirements" that are required to support proper tool selection. This is critical as the tools will actually enforce or store much of the enterprise SOA policy. Having three tools that store enterprise SOA policy, four tools that enforce SOA policy, and two other tools that create SOA Policy adds complexity and actually impedes strong SOA Governance as the enterprise's SOA policies become unmanageable through its various systematic implementations. In this case, the systems that were meant to automate and relieve manual governance tasks actually complicate the management of governance tasks. For this reason, it is recommended that "governance" tools be purchased only after the other SOA pillars have been defined - if good Governance is to occur sooner rather than later.

The sixth pillar of SOA is an enterprise's "SOA Technologies". This is simply the technology standards and choices that an enterprise selects to support a SOA initiative or effort. Governance in this area is often around specific standards and versions of technology standards. Enterprise Policy can be easy to define, here, if an organization can agree to sacrifice the shiny, new technology standards for standards that are mature and "LCDS" (Least Common Denominator Standards). What is most critical, here, is for "tactical" groups to define their technology preferences and work through the "strategic" groups to get those preferences standardized (across departments), approved, and documented. This will enable SOA service convergence as the enterprise service portfolio is manifested through time (and composite services to be created more easily and with more agility).

Next Steps in Governance

Now that we have a clear understanding of different types of Governance and how Governance supports the Six Pillars of SOA, we've established a basic and primary understanding of SOA Governance.

There are, however, steps we can take to formalize this effort and validate our SOA Governance objectives. We can begin by answering (and documenting) the answers to these critical questions:

1. What are the "strategic governance" bodies in my organization? Are they currently responsible for SOA Governance decision making?
2. Who are the "tactical governance" groups in my organization? Who is piloting SOA programs and initiatives? Who has created services and configured integrations? Have they documented any of their technology standards or processes?
3. Has anyone conceptualized an enterprise SOA model for our enterprise? If so, where is it and where can I learn more about it?
4. Has anyone documented what SOA functions are currently supported in our enterprise? Who is responsible for aligning those functions to actual departments or teams?
5. Has anyone documented our enterprise's SOA processes that support that model? What is the process for creating a service, designing a service, deploying a service, registering a service, configuring an integration, getting "help desk" support, or asking for a policy exception?
6. Has anyone documented the services our enterprise has already made available? Has anyone aligned those services to our business domains, products, and functions? Has anyone published a "plan" for service offerings and identified "gaps" in our planning?
7. Has anyone aligned the enterprise's SOA tools with a SOA reference architecture? What capabilities does our current SOA tool set provide the enterprise? What capabilities are missing? Who is responsible for selecting tools?
8. Has anyone documented technology standards and preferences? What is the exception path for requesting a technology exception? What happens if I don't adhere to enterprise SOA Policy around SOA technologies? What happens if I do adhere to technology standards?

Conclusion

One key to good Governance is to differentiate between "strategic" and "tactical" governance. Organizations that succeed with their SOA Governance initiatives allow the "strategic governance" teams to be right - while enabling the "tactical governance" teams to deliver business value. Both groups must leverage SOA Policy "exception paths". The "strategic governance" team must provide and support policy "exception paths". The "tactical governance" teams must embrace policy standards set forth by "strategic governance" or engage the provided "exception path" process in order for alignment to occur, synergies to be attained, and battles to be avoided.

The rest of the Governance work is dirty, at best. Defining Governance in an organization is an involved effort where roles and functions and people and processes and tools and technologies and services need to be clarified, documented, aligned, and integrated into a single organizational model. While most would see this as too time-consuming, we assert that less time will be spent answering these questions, and thus defining your enterprise SOA Governance, than time spent finding answers to these questions that don't exist. Basic Governance can be implemented in a matter of weeks, if the right questions are asked and the answers simply documented.

About the Author

Ed Vazquez is VP, SOA Business Innovations at MomentumSI, where he leads the Enterprise Transformation Practice. In his more than a decade of Web Application Management (including six years of SOA and Web Service Implementation Management), Ed has led major programs to transform enterprise Business and IT organizations with Sprint, Pfizer, and other
companies. Prior to focusing on Enterprise Transformation and Innovation, Ed developed significant subject matter expertise in the SOA Lifecycle, SOA Governance, and Business Driven SOA. Ed graduated with both his Master's Degree and Bachelor's Degree from the University of Kansas.

     
         
             
Sponsored by:
 
             
Whitepapers:
 - Real World SOA with CentraSite
 - Governance: Rule your SOA
             
Recent Blogs by SOA Experts on CentraSite:
 - The Human Side of SOA 
- If SOA was the answer, what was the problem?"
- Typical SOA Scenarios