- Organizing Your SOA Project Office
- SOA Adoption Roadmap
- The Need for SOA Governance
- SOA Technical Governance
- SOA Project Roles
- Summary
- Links to developerWorks
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.3 The Need for SOA Governance
Enterprises using SOA can adapt to target broader connectivity and increased revenues; on the other hand, doing so requires restructuring applications for greater flexibility and lower costs. This requires the alignment of the business and IT value chain, as described in Chapter 2, "Explaining the Business Value of SOA." With this evolution, the enterprise will also need to adapt the way the business and IT units interlock and define a new way of reflecting business requirements in terms of IT applications. For this reason, organizational governance plays a more prominent role than before. The following sections provide guidance on establishing key governance functions for operating an SOA.
4.3.1 SOA Governance Motivation and Objectives
The business operations and the underlying IT infrastructure in an organization must react very quickly to rapidly respond to new business opportunities. Business units have to prioritize new IT services that have to be designed and managed as part of highly integrated and complex enterprise architecture. To achieve this, we discuss in the following sections a set of key governance functions for a successful SOA roadmap.
Governance provides an overarching structure to prioritize and then support the enterprise business objectives on a strategic, functional, and operational level. The governance model defines "what to do," "how to do it," "who should do it," and "how it should be measured." It defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision-making, steering, and control of the SOA engagement to meet the enterprise business needs and challenging targets. As previously indicated, the SOA project team is responsible for creating this governance model.
The following are key questions that can help define the appropriate governance structure:
- What business change does the enterprise expect from SOA? Is it a better use of its existing infrastructure at lower costs, does it target new business and interaction models, or does it target both?
- Which roles, responsibilities, structures, and procedures exist to allow business prioritization and IT funding, planning, steering, and decision making?
- How can you develop skills and leadership competency?
- Which principles and guidelines are necessary to optimize the alignment of business and IT?
- What is the appropriate way to structure the business-to-IT relationship while keeping consistency and flexibility to allow the organization to quickly adapt to new changes?
- What is the appropriate level of standardization of services, the service definition, and the description?
- How do you control and measure services and service providers? What key business performance indicators do you need to monitor? Who should monitor, define, and authorize changes to existing services?
- How do you decide on a sourcing strategy for services?
We believe that an accepted and formalized governance model is crucial to successfully achieve business objectives, so we will define important governance functions in the following sections. For fast and high-level acceptance, it is essential to start from the existing enterprise structure and adapt it to the SOA roadmap.
To provide architectural governance, you need an organizational structure to help identify all necessary roles and responsibilities. Based on our experience, it is quite useful to establish an SOA center of excellence (COE) to control the SOA roadmap and to support large and complex projects. The COE is responsible for keeping the SOA-based implementation aligned with the business requirements on a strategic, tactical, and operational level. It requires authority over technical artifacts such as architecture blueprints, enterprise templates, and design assets.
4.3.2 An SOA Governance Model
In her IBM developerWorks article, Yvonne Balzer describes an SOA governance model on which we based our considerations. SOA governance is an evolution of the ideas of IT governance, introducing a greater business involvement in supporting IT service components. There are different definitions of IT governance, but the IT Governance Institute's definition gives a good general overview:
The IT Governance Institute's Definition of IT Governance
IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes to ensure that the organization's IT sustains and extends its strategies and objectives.
The purpose of IT governance is to direct IT endeavors to ensure that IT performance meets the business objectives so that the following occurs:
- IT alignment with the enterprise results in the promised benefits being realized.
- IT enables the enterprise so that opportunities are exploited and benefits are maximized.
- IT resources are used responsibly.
- IT-related risks are managed appropriately.
SOA governance incorporates the control of the enterprise model as a set of standardized modular business components and processes, and the prioritization of those based on business value. In summary, the SOA governance model is a combination of organizational structure, joint processes, and relationships that are based on accepted ground rules called governance principles and the strategic direction.
4.3.3 Strategic Direction and SOA Governance Principles
To sustain the focus on business needs, it is essential to define the strategic direction for developing an SOA. Both business and IT units need a common understanding of the business strategy and objectives. Governance principles and guidelines form the fundamental basis for any decisions. They shape the solution area and define how business and IT units collaborate. Everyone involved should carefully understand and agree upon these principles, from executive management to individual project personnel.
According to E.G. Nadhan in his EDS Solutions Consulting position paper of April 2003, "SOA Implementation Challenges," there are two main governance approaches:
- Central governance is optimized for the enterprise. The governance council has representation from each business domain and from technology subject matter experts. The central governance council reviews the addition or removal of services, as well as changes to existing services, before authorizing their implementations.
- Distributed governance is optimized for the distributed teams. Each business unit has control over how it provides the services within its own organization. This requires a functional service domain approach. A central committee can provide guidelines and standards.
Each guiding principle should be defined with a rationale explaining the business reasons and implications. The specific principles for architecture design or service definition, for example, can be derived from these guiding principles. In addition, a common understanding of a structured approach from business to IT is fundamental for defining the architecture. You will find different methodic approaches such as process orientation, business functions, or even component modeling like IBM's Component Business Model approach.
4.3.4 Empowerment and Funding
The move to SOA is a paradigm shift driven by the need for more flexible business models, greater integration, and a stronger business and IT alignment. This evolution might face resistance within an organization, which can turn it into just a simpler result of implementing Web services on a small scale rather than a move toward the benefits of a true SOA. In truth, a successful SOA project can happen only with the strong support of senior executives, identified funding, and proper empowerment of the SOA governance body.
One of the pitfalls is the institution of a rubber-stamp governance body or one that has a mere consultative role and cannot enforce its recommendations. At the end of the day, the governance body needs to have proper practical control of project funding.
4.3.5 Managing the Risk of an SOA Roadmap
When embarking on an SOA roadmap, the first action of the governance body should be to develop an initial readiness and risk assessment. The governance body should then periodically update this assessment during the development lifecycle. Figure 4.2, an example of this assessment, shows important aspects and criteria that need to be taken into account. The scale values and the specific criteria can be chosen based on the situation of the individual project. The goal of this assessment is to identify the business, organizational, and technical gaps and roadblocks between the current state of the enterprise and a future service-oriented business model.
)
Figure 4.2 An SOA readiness and risk factor assessment.This was adopted from IBM internal SOA assessment practice and was modified by editors.
This kind of assessment should balance the vision of the SOA-based solutions with the delivery capabilities of the IT department and should help establish specific a business case for the SOA for the organization. It includes both an evaluation of business readiness and one of IT readiness. It requires customer and partner understanding and determines if changes to the client's or partner's needs can be mapped to existing products or applications in a service-oriented fashion.
The assessment then suggests possible action plans, with focus on improving the less mature aspects of the enterprise relative to the SOA. As before, these improvements to develop the SOA should be executed in well-planned, incremental projects.
4.3.6 SOA Governance Processes
Governance processes are those needed for strategic business and IT planning and steering—for example, strategy development, IT technical planning, portfolio management, sourcing, innovation management, and architecture management. Any IT organization also needs processes that provide control. Depending on the size of the organization, these processes should be implemented at the appropriate level matching the size, from individuals to teams to departments or even larger. The following types of processes are essential for successful SOA adoption.
A business component identification and prioritization process:
- Defines a structured approach to model, identify, and prioritize business processes and services components.
- Provides formal definition of the business goals and key performance indicators that can be delivered by the architecture and implementation.
A business exception fallback process:
- Business process models can rarely be exhaustive. No one can preview each and every possibility that can happen in an enterprise. Therefore, there must be rules for exception handling that are set up and agreed to.
- This ensures that the concrete SOA solution architecture has to incorporate entry points that enable certain users or processes to bypass the normal, formalized processes and process exceptions. In a way, this gives another degree of flexibility for ad-hoc business process changes.
An architecture review and approval process:
- Defines a structured approach to review and approve changes to the existing SOA and to make decisions in accordance with the governance guidelines.
- Formal design and service evaluation reviews are key control points of SOA development for the installed governance units.
An architecture exception and appeals process:
- Provides means to appeal architectural decisions.
- Allows exceptions to the SOA architecture to meet unique business needs.
An architecture vitality process:
- Ensures that the SOA is maintained and communicated as new services are incorporated into the architecture.
- Variances to the architecture are documented and communicated.
An architecture communication process:
- Ensures that the SOA is available to all who need access.
- Promotes the understanding of the importance of the SOA.
Having outlined the process we now describe how to launch a governance model in practice.
4.3.7 Launching the Governance Model
The process we use to develop a governance model is a three-phased approach (see Figure 4.3). This governance launch model was adopted from Yvonne Balzer's developerWorks article "Improve your SOA project plans" and enhanced by the authors. The approach is based on time-constrained SOA engagements. The key to success is to begin to establish the governance functions from day one. To speed up this operation, you can launch the governance model in the following three steps:
- Operationalize
- Set the governance core functions in place, integrated with the enterprise's business operations.
- Perform the initial SOA assessment.
- Learn and adjust by doing by experiences and available assets, delivering quick results.
- This phase will need experienced practitioners.
- Define the next steps.
- Professionalize (Automate)
- Build up the necessary structures, processes, methods, and tools.
- Adapt experiences from the operational step.
- Initialize the service-oriented modeling and architecture practice.
- Gather experienced architects and method practitioners.
- Stabilize
- Teach and train the personnel to run the operation.
- Change from operations mode to coaching mode.
- Need to nurture coaching expertise.
)
Figure 4.3 Launching the governance model.
4.3.8 Hints and Tips for Success
Even with strong governance, in the real world there are many roadblocks that prevent this type of evolution; thus, it is essential to build on solid ground. The following are some practical lessons we have learned from engagements:
- Set up rules and roles (discussed in Section 4.5) to organize and project-manage the SOA endeavor.
- Communicate regularly. SOA also involves corporate cultural change; therefore, to hurdle barriers, communication is critical, especially between lines of business and technology teams.
- Document each decision, constraint, and assumption to ensure transparency in decision-making and departmental buy-in.
- Define key deliverables and necessary toolsets or templates. These deliverables need to be readable by a variety of parties in the enterprise.
- Set up pragmatic tools for lifecycle management and versioning. Particularly see the discussion on long-lived business processes in Section 4.4.
- Assign a weight factor to each decision and then document and communicate those decisions and their weights.
- Continue to keep a strong sponsorship by all stakeholders and the buy-in of decision-makers.