In SOA Governance, Who Has the Authority?

I would equate it to a homeowner's or condo association type of arrangement. Everyone shares in the ownership of a piece of the environment, but relegates some authority to a committee to handle and manage shared services (trash pickup, groundskeeping, security, etc.) In the case of SOA, the committee's job would be to "contract" to IT to manage the availability, standards, and security of the SOA environment.

Governance and Ownership are not the same. As far as Service ownership is concerned Central team ownership as well as distributed model, i.e. some services are owned by departments or different locations, are valid models. As far as Governance is concerned the centralized model is preferred. An exception to this rule are services with limited scope, i.e. these services scope is limited to a specific Line or Business, Location or department.

In general, the target of SOA is Enterprise. My folk definition of Enterprise is "An organization that's big enough to experience fragmentation of organization, market, supply and technology".

In those situations, typically you see two governance patterns, the atomic pattern and the metapattern.

In the atomic pattern you have a provider and consumer relationship governed by a contract. In this case authority is typically conferred to the consumer side.

In the metapattern, you have multiple providers and multiple consumers, and the pattern here is called "Federation". This is the balance of power between central and regional authorities.

OASIS SOA RM and coming RA respond to this question directly.

There are three different but interconnected things: service governance, management and ownership. Every one of them has its own role to play and corresponding jurisdiction. The role of governance is to define policies, procedures and authority of all participants of service interaction across ownership boundaries. The role of management is to implement, enforce and realise governing policies.

One of the forms of management of shared services is ‘star’ – centralised shared services set Service Contracts with all service consumers centrally. The problem with this approach is that every service carries a potential to become shared as any moment. Since services have different ownership, it might be a complex process to move a service under centralised governance and back (for the time the service is not shared). Even if a service addresses a business task specific to one LOB today, this task may appear in another LOB tomorrow. That is, the service scope does not preclude it from become shared.

Another form of management of shared services is ‘mesh’ – every service is governed in such way that allows its provider/owner to set the Service Contracts with any consumer directly. That is, each service manages its own relationships independently from others and this is an extra work. This does not prevent service providers from using the same management methods and tools and even register the services in a federated service registry.

Known reliable solution for the ‘mesh’ management model is cross-functional and cross-departmental management (unit, programme) with authority that is higher than the authority of individual service owner. This cross-functional unit decides which service participates in which service composition. Described model has the higher potentials for business flexibility than the ‘star’ model.

In my opinion, the short answer is the CIO is accountable for (service-oriented) architecture.

The long answer involves first addressing 2 key buzzwords associated with the question: SOA and governance. I leverage MIT’s IT Governance model when defining SOA governance: SOA governance involves specifying decision rights and accountabilities for important SOA-related decisions (e.g., service design, service version control, service deployment, etc…). In practice, I actively promote using a responsibility assignment matrix (RAM) to aid in implementing SOA governance as it clearly identifies: (1) what decisions need to be made, (2) who is involved in the decision making process and (3) each individual’s role (i.e., responsible, accountable, consulted, informed) with respect to the decision. In my opinion, SOA is a contemporary approach to enterprise architecture – i.e., the overall design of an organization’s many and disparate information technology assets and how they link together to enable the enterprise’s business processes. SOA promotes deconstructing business processes into discrete, reusable and standardized services. It’s an architectural style that can lead to enterprise agility, flexibility and lower costs.

Second, we need to understand the tradeoffs associated with ‘centralization’ versus ‘decentralization’ issue. The former often leads to economies of scale; the latter permits local innovation. The “optimal” configuration depends on the business model. The business sets the direction on which business processes and data should be centralized or decentralized. IT organizations should align with this direction. The advantage of SOA is that it’s a flexible architectural pattern that facilities this alignment.

I appreciate and agree with Raymond's very clear and pragmatic answer. Ultimately, the CIO will be accountable however, it's like saying that the CEO is responsible for success of the business, true, however, there is a whole lot of delegating going on.

Two things that Raymond highlights however that are proven best practices are the Responsibility assignment matrix to guide and identify where decisions need to be made, who makes them, whether other stakeholders have a vote and an escalation path if needed. I also agree that there is no one right way to implement SOA and SOA governance -- centralized, decentralized, etc. but rather it maps to the needs of the business and to some extent, culture.

The key, in my opinion, however, having worked with several customers, is to be very clear on responsibilities and roles, give authority with accountability (no one wants accountability without the ability to make decisions), and measure and monitor what matters-- if you are going to govern it, make sure it's a priority for IT and the business.

Really well-thought out answers here. Joe, this is funny because we often use the Homeowner's Association vs. Federal Govt. as the example of why you need Federated governance. It is simply too inefficient for the Federal govt. to tell you where you should put your mailbox and flag, etc. - however, you have overarching issues like currency or a space program that would be impossible to manage at the HOA level.

I think Miko hits on something new, because it does truly depend on the relationship. We are seeing more peer-to-peer or multi-partner types of applications. In these environments, not enough federation acts as an inhibitor to participation - the rule of law is just too rigid. However, too little central authority and enforcement of polity, or at least setting AND enforcing the "rules of the road" leads to chaos and abandonment in the long term.