SOA Governance: Reengineering IT Governance

It's no wonder, then, that IT governance is the most critical area of corporate governance in today's competitive enterprise -- both the governance of IT and the use of IT for corporatewide governance. However, how can executives rely upon brittle legacy IT infrastructures connected with spaghetti integration to offer the governance they require? The answer lies in architecture, because architecture provides the framework for the IT infrastructure and its use within the organization. Unfortunately, however, many organizations are struggling with their enterprise architecture, just as they are faced with IT governance challenges.

Fortunately, there is hope on the horizon in the form of Service-Oriented Architecture (SOA). SOA is an approach to enterprise architecture that abstracts IT functionality into business-oriented Services. The application of SOA to IT governance -- what we call SOA governance -- promises to provide the visibility and control necessary for IT governance, while increasing the business agility today's organizations require. Likewise, SOA provides an enterprise the ability to govern other aspects of their business as well.

IT Governance and Enterprise Architecture
IT governance describes how people entrusted with the authority over some aspect of the business will consider IT in their supervision, monitoring, control and direction of that business entity. How they apply IT will have an impact on whether the company will be able to attain the vision, mission or strategic goals that the management of the company sets for it. IT governance specifies who has the rights to make decisions regarding IT, what decisions they can make, and an accountability framework that encourages the IT usage behavior corporate management seeks to exhibit. IT governance is not about making specific IT decisions (management does that), but rather determines which individuals and roles with the company systematically make and contribute to those decisions.

Enterprise architecture plays a key role in this process of delegating responsibility for IT resources and their integration. In essence, enterprise architecture encompasses both technical architecture (the organization of IT resources) as well as the business architecture. In order to succeed, enterprise architecture must reflect the needs of the organization and the fact that consensus must drive architecture definition and implementation. Architects, even if they are not involved in the development of business strategy, must at least have a fundamental understanding of the prevailing business issues facing the organization. It may even be necessary for architects to participate in the system deployment process and to ultimately own the investment and product selection decisions arising from the implementation of the architecture. As a result, the enterprise architect has an increasingly important role in the IT governance process.

However, one challenge many organizations face is that the practice of enterprise architecture is still relatively immature. The role of enterprise architect is sometimes subsumed within product or project management roles, advanced developers, network administrators, or line-of-business users with a technical bent. Common roles for enterprise architects often include the definition of architectural taxonomies across business, application, and technical areas, the delivery of supporting knowledge and assets to consumers, and the governance of those assets within the scope of IT projects. However, such responsibilities vary from organization to organization.

SOA Governance
This lack of clarity surrounding the role of the enterprise architect can affect the IT governance process at some organizations. For companies with siloed IT shops and rigid delineations between IT and business, IT governance can be problematic, because of the numerous difficulties facing the people responsible for driving IT governance -- in many such cases, the business and IT users are often at odds with each other. In enterprises that have adopted SOA, however, the cross-functional nature of SOA improves this situation. The Service-oriented (SO) architect, who is in essence an enterprise architect, has broad responsibility for both IT and business across organizational silos. Therefore, IT governance within the context of SOA -- what we're calling SOA governance -- promises to augment the IT governance process, while mitigating its risks, and facilitating the dialogue between business and IT users.

The IT governance process begins with setting objectives for the enterprise's IT efforts. Traditional IT governance processes then distribute these objectives to each department within IT, for example, applications, networking, and IS. SOA governance, however, introduces the notion of domain ownership, where domains are managed sets of Services sharing some common business context. In many cases these sets of Services are business Services, such as customer information, order processing, or product analysis.

Each domain is responsible for maintaining the applications that support its Services and for maintaining the interfaces to its Services for other domains. The owner of each domain must therefore handle such issues as Service management, business logic encapsulation, location independence, and the data format issues associated with its Services. When the people in charge of some product area want access to a Service from a domain, they make a request to the owners of the domain and the two groups determine the relationship between their respective spheres of influence, creating a Service-level agreement between them. Such relationships and agreements also exist between domains.

SOA governance also introduces new roles that the company must provide for:

• The domain owner -- manages the direction of the domain and the business relationships between the domain and business units, as well as other domains. The domain owner also helps business process owners in various business units understand the business application of the Services within the domain. This person also tracks the usage of Services for management purposes and ROI calculations.
• SO domain business analyst -- identifies abstracted, normalized business Services. Translates business requirements into Service definitions. Works closely with IT personnel to direct Service implementation.
• Line of business representative -- communicates business requirements and identifies business Services for each of the domains.
• Domain developer -- builds and maintains Services consistent with the SOA lifecycle. Implements Services consistent with implementation guidelines and the SOA.
• Service tester -- certifies that each Service conforms to the business requirements that apply to that Service. Builds test cases for the Service interface.

Each person working within a given Service domain is responsible for developing the business Services that are shared across the lines of business. This shift in responsibility introduces a change in the organizational structure for application development, as people shift from developing functionality within an application to developing functionality within a particular Service domain. These new roles should work in conjunction with the enterprise architecture team.

The ZapThink Take
There is a common misconception that SOA governance is governance of an SOA, as though SOA were one more IT asset in need of governance in the organization. That belief, however, indicates a fundamental misunderstanding of the role of SOA. Fundamentally, SOA is enterprise architecture -- when an enterprise adopts SOA, it should approach the organization of all of its IT assets from an SO perspective. As such, Service orientation provides a broad organizing principle for all aspects of IT in the company -- including IT governance. That's why we say SOA governance is IT governance in the context of SOA, rather than governance of SOA.

Furthermore, SOA requires a reorganization of IT personnel and the users of IT into domains. The need for governance highlights the importance of such reengineering, but is not its cause. On the contrary, the need to break down silos and organize a company's efforts based upon the core needs of the business is as old as the term "reengineering" suggests. SOA enables the enterprise to organize IT functionality into Services that meet the needs of the business, finally enabling companies to achieve the long-desired business goals of breaking down silos and focusing on the needs of the business and the customer.