The fact that you're reading this article means that you are probably planning a service-oriented architecture (SOA) initiative and recognize that some level of governance is required in order to be successful. If you are like most people in this position, you are also somewhat confused as to the meaning of SOA governance. Governance is the current buzzword, and combining governance with SOA creates a phrase that every independent software vendor (ISV) wants a piece of. How do you sort out what is marketing hype from what is truly valuable and relevant to your organization's SOA efforts?

Governance Scope Within an IT Organization
Much of the hype around SOA governance has been focused on operational governance. Defining, tracking, and managing factors like service-level agreements (e.g., average response time, peak response time, average throughput, peak throughput) and authorization policies (e.g., users from organization A are allowed to invoke this service while users from organization B aren't) are clearly important once the pieces of an SOA get up and running within an organization's IT infrastructure.

However, while operational governance and management is necessary for a successful SOA initiative, it is not sufficient. For an organization to effectively define and implement an SOA (and not simply implement a series of point-to-point services masquerading as an SOA, but in fact creating another layer of technology spaghetti), it must extend SOA governance back to the development and architectural perspectives. To be successful with SOA, you must find a way to bind these perspectives together as seamlessly as possible to enable effective information flow in both directions: from architecture to development to operations, and vice versa. Let's investigate each of these governance perspectives in turn.

Architectural Governance
Architectural governance at the enterprise architecture (EA) level involves three key elements: 1) making core decisions about business or technological functionality within the enterprise, 2) sufficiently documenting those decisions so that downstream consumers (the teams responsible for developing and deploying services and applications) can quickly understand and make effective use of those decisions, and 3) reviewing the project-specific application of those decisions. In order for an EA team to execute these tasks, it must have at its disposal an effective way to disseminate the knowledge assets it produces, to track and understand which knowledge assets are being applied to specific projects, and to document the review of those project-specific decisions.

Design-Time (Development) Governance
In many ways, Software Development Life Cycle (SDLC) governance within an SOA initiative is a reflection of decisions made at the EA level. Decisions about the scope and granularity of business services to be implemented and the technical approach to be used in implementing those services must be applied to specific service production or consumption (i.e., application development) projects. However, SDLC governance extends beyond appropriate application of EA guidance to the actual analysis, design, implementation, and testing of the resulting services and/or applications required by the IT project at hand. With respect to service production, SDLC governance involves the progressive "hardening" of the service as it progresses through its requirements definition, design, implementation/unit test, and integration/system test phases to eventual deployment in the operational environment. When applied to service consumption, governance may involve both internal project-specific reviews (e.g., have the appropriate services been selected, have requirements for new services been identified) and external reviews from the perspective of service providers (e.g., does the use of this service within this application conform to enterprise-specific or government-mandated privacy rules, does the service implementation contain open source components and if so, are the components used in a manner such that enterprise-specific intellectual property is not compromised).

Operational Governance/Management
Operational governance/management within an SOA involves applying appropriate business and technical policies (e.g., which groups and users are allowed to invoke a particular service, what are the minimum throughput and response time expectations required of a service) to deployed services. Business policies are often implemented within an SOA by an Enterprise Service Bus or SOA Fabric integrated with the enterprise's authentication and authorization infrastructure, while technical policies are typically monitored by a services management platform. The cumulative set of governed technical policies is often referred to as a service-level agreement (SLA). Examples of SLA-level technical governance elements within an SOA are:

• Average throughput
• Peak throughput
• Type and description of committed SLA
• Availability
• Consuming service clients
• Hardware and software configuration
• Fault history
• Alert thresholds

SOA governance has an impact on current IT governance processes. Some of these processes include the budgeting and project approval process, portfolio management activities, and ongoing oversight of projects to assure budgetary compliance. Applying governance to SOA activities is critical because there may have to be changes to the normal IT governance processes for budgeting and portfolio management.

Think about the budgeting process of your organization. That budgeting process has a tremendous impact on the behavior of various organizations and their IT representatives. If there is no budgetary control of projects to influence them to adopt SOA and reusable services as their fundamental design concepts, then projects will go their own way as driven by the requirements of that particular business unit or project. The same goes for the portfolio management process. If there is no mechanism to surface SOA and reuse opportunities for all projects and then apply budgetary pressure to converge them toward an SOA, then they will similarly go their own way. SOA governance, budgeting, and portfolio management are ways to influence behavior of business units, as well as the IT and business personnel within them, to more aggressively support SOA and reuse.

Enterprise architecture processes may undergo similar changes given the advent of an SOA initiative in an organization. Often the architecture process and organization will have to be restructured to accommodate the requirements of an SOA initiative because the skills, roles, and functions of an EA team are not completely appropriate for an SOA initiative. Think about the process of architecture as two tiers of activities: one tier is the architecture strategy and goals, followed by the definition of the elements, standards, and organization of architecture to accomplish those goals. The second tier is the application of architecture to funded projects, the acquisition or implementation of various technologies and standards, and the enforcement of compliance to the enterprise architecture goals (see Figure 1).

These are two related yet distinct processes, and often they are not as interdependent as CIOs would like. Think about the cases where there is a chief architect or central architecture group at corporate headquarters, and then also present are the solution architects assigned to projects. They actually build systems and implement technologies and standards. Who has the most direct bearing on the architecture that ultimately is implemented in a given organization? Naturally it is the person assigned to the budgeted project that was sponsored by a specific business unit that ultimately funded the project. The behavior associated with enterprise architecture is similarly related to the organization and processes used to achieve the goals of SOA, architecture compliance, portfolio management, and budgetary compliance.