- 6.1 Governance 101
- 6.2 The SOA Governance Program Office (SGPO)
- 6.3 SGPO Jurisdiction Models
- 6.4 The SOA Governance Program
This chapter is from the book
This chapter is from the book
This chapter is from the book
6.4 The SOA Governance Program
The SGPO exists to create and maintain an SOA governance program. This program encompasses the SOA governance system and all associated responsibilities for planning, implementing, and evolving this system. The best way to distinguish the program from the system is to view the SOA governance system as a set of formal precepts, roles, processes, metrics, and any associated models. The SOA governance program is dedicated to establishing and evolving the SOA governance system and therefore further provides real-world planning and implementation considerations, such as project plans, budgets, schedules, milestones, and further deliverables that map the SOA governance system to other parts of the existing IT enterprise (including already established IT governance systems).
The task of realizing an SOA governance program can be divided into three basic steps:
- Assessing the Enterprise (or Domain)
- Planning and Building the SOA Governance Program
- Running the SOA Governance Program
Step 1: Assessing the Enterprise (or Domain)
Before creating appropriate precepts and formalizing the overall SOA governance system, the SGPO must first evaluate specific aspects of the current organizational state of the IT enterprise or whatever domain thereof for which that SOA adoption is being planned. This assessment may be limited to the domain in which the SGPO operates, but often also encompasses broader, organization-wide considerations that apply to most or all domains.
The assessment generally focuses on several specific areas:
- Current Governance Practices and Management Styles
- SOA Initiative Maturity
- Current Organizational Model
- Current and Planned Balance of On-Premise and Cloud-based IT Resources
Current Governance Practices and Management Styles
The organization’s existing governance practices and management styles need to be studied to determine how best to introduce SOA governance-related processes and precepts. As previously described, no one governance model is suitable for every organization. A successful SOA governance program must take into account the organization’s culture and management preferences.
Common issues that need to be addressed include:
- Are decisions tightly controlled by a central authority or widely delegated?
- Do the various groups within the organization collaborate or do they typically work autonomously?
- How do other governance program offices in the company work?
- How well does the organization articulate and disseminate governance precepts?
- How rigorously do people within the organization adhere to standard practices and processes?
- How much flexibility do managers and project leaders have in adapting to processes to meet the needs of a specific project?
- How much flexibility does management have to establish or modify incentive systems?
Concrete, well-researched answers to these questions can significantly influence an SOA governance program in that they can identify both strengths and weaknesses in relation to the types of governance and management practices required to see through a successful SOA initiative. This, in turn, helps determine the nature of precepts required and to what extent the existing IT culture will be impacted by the SOA governance system.
SOA Initiative Maturity
Ideally, an SOA governance program is established prior to the launch of an SOA initiative. However, in situations where existing SOA projects or activities are already underway, a further analysis of their progress and maturity is required to ensure that the introduction of the SOA governance program ends up supporting and aligning these efforts with overarching strategic goals. The SGPO may also need to spend time assessing existing SOA initiatives in relation to an IT department’s readiness for SOA governance.
Current Organizational Model
An organizational model defines roles and responsibilities within an organization. A given IT department will have a distinct organizational model that usually establishes a hierarchy with levels of authority. The SGPO must assess existing roles and responsibilities in order to identify how new roles and responsibilities specific to SOA governance will affect the organizational model.
Current and Planned Balance of On-Premise and Cloud-based IT Resources
In order to take an appropriate range of considerations into account when authoring SOA governance precepts and supporting processes, the SGPO needs to have a clear understanding of what cloud-based IT resources relevant to the SOA project currently exist, and to what extent the organization is planning to explore or proceed with cloud-based deployment of services and/or related IT resources. These considerations usually lead to additional standards, additional factors that apply to review processes, and additional organizational roles and skill-sets required for the definition of precepts and processes.
Step 2: Planning and Building the SOA Governance Program
After assessing the organization, the SGPO can get to work on actually planning and creating a concrete program for SOA governance. As previously established, the SOA governance program encompasses the SOA governance system and further provides supporting components to help establish and maintain this system.
To identify the primary components of an SOA governance program, we therefore begin by revisiting the precepts, people, and processes that are part of a governance system.
SOA Governance Precepts
The assessment completed in the previous stage is intended primarily to identify the aspects of a current or planned SOA initiative that pose the most risk and have the most urgent need for structured governance.
The following precepts are described individually in Chapters 7 to 12, where they are further associated with project lifecycle stages, processes, and organizational roles:
- Service Profile Standards (Chapter 7)
- SOA Governance Technology Standards (Chapter 7)
- Preferred Adoption Scope Definition (Chapter 7)
- Organizational Maturity Criteria Definition (Chapter 7)
- Standardized Funding Model (Chapter 7)
- Service Inventory Scope Definition (Chapter 8)
- Service and Capability Candidate Naming Standards (Chapter 8)
- Service Normalization (Chapter 8)
- Service Candidate Versioning Standards (Chapter 8)
- Schema Design Standards (Chapter 9)
- Service Contract Design Standards (Chapter 9)
- Service-Orientation Contract Design Standards (Chapter 9)
- SLA Template (Chapter 9)
- Service Logic Design Standards (Chapter 9)
- Service-Orientation Architecture Design Standards (Chapter 9)
- Service Logic Programming Standards (Chapter 9)
- Custom Development Technology Standards (Chapter 9)
- Testing Tool Standards (Chapter 10)
- Testing Parameter Standards (Chapter 10)
- Service Testing Standards (Chapter 10)
- Cloud Integration Testing Standards (Chapter 10)
- Test Data Usage Guidelines (Chapter 10)
- Production Deployment and Maintenance Standards (Chapter 10)
- Runtime Service Usage Thresholds (Chapter 11)
- Service Vitality Triggers (Chapter 11)
- Centralized Service Registry (Chapter 11)
- Service Versioning Strategy (Chapter 11)
- SLA Versioning Rules (Chapter 11)
- Service Retirement Notification (Chapter 11)
- Enterprise Business Dictionary/Domain Business Dictionary (Chapter 12)
- Service Metadata Standards (Chapter 12)
- Enterprise Ontology/Domain Ontology (Chapter 12)
- Business Policy Standards (Chapter 12)
- Operational Policy Standards (Chapter 12)
- Policy Centralization (Chapter 12)
It is important to document the reasoning behind each precept and define the circumstances in which it does or does not apply. Precepts need to be codified with clarifying policies and standards and consequences for non-compliance need to be further established. Also, supporting guidelines and compliance metrics are required. Where appropriate, conditions that might warrant a waiver need to be identified and a separate precept for allowing or denying waivers may further be required.
SOA Governance Processes
Depending on the size of the SGPO, internal processes may be required to coordinate activities within the group running the office. Governance process definition is another area of focus for the SOA governance program.
The following processes are covered in Chapters 7 to 12, where they are mapped to project lifecycle stages, precepts, and organizational roles:
- Organizational Governance Maturity Assessment (Chapter 7)
- Adoption Impact Analysis (Chapter 7)
- Adoption Risk Assessment (Chapter 7)
- Business Requirements Prioritization (Chapter 8)
- Service Candidate Review (Chapter 8)
- Service Contract Design Review (Chapter 9)
- Service Contract Registration (Chapter 9)
- Service Access Control (Chapter 9)
- Service Logic Design Review (Chapter 9)
- Legal Data Audit (Chapter 9)
- Service Logic Code Review (Chapter 9)
- Service Test Results Review (Chapter 10)
- Service Certification Review (Chapter 10)
- Service Maintenance Review (Chapter 10)
- Service Vitality Review (Chapter 11)
- Service Registry Access Control (Chapter 11)
- Service Registry Record Review (Chapter 11)
- Service Discovery (Chapter 11)
- Shared Service Usage Request (Chapter 11)
- Shared Service Modification Request (Chapter 11)
- Service Versioning (Chapter 11)
- Service Retirement (Chapter 11)
- Data Quality Review (Chapter 12)
- Communications Quality Review (Chapter 12)
- Information Alignment Audit (Chapter 12)
- Policy Conflict Audit (Chapter 12)
You may have noticed how several of these processes end with “review.” Many SOA governance processes are designed specifically to support and enforce compliance to precepts, and therefore are carried out subsequent to other project delivery tasks as a formal review.
SOA Governance Roles
Organizational roles associated with SOA initiatives are of great interest to the SGPO because the various project stages for which governance precepts and processes can be defined will involve these roles in a governance capacity.
The following organizational roles were introduced in Chapter 5 and are further explored in Chapters 7 to 12, where they are associated with project lifecycle stages and SOA governance precepts and processes:
- Service Analyst
- Service Architect
- Service Developer
- Service Custodian
- Service Administrator
- Cloud Resource Administrator
- Schema Custodian
- Policy Custodian
- Service Registry Custodian
- Technical Communications Specialist
- Enterprise Architect
- Enterprise Design Standards Custodian (and Auditor)
- SOA Quality Assurance Specialist
- SOA Security Specialist
- SOA Governance Specialist
Figure 6.8 provides an overview of how these roles commonly map to SOA project lifecycle stages.
)
Figure 6.8 Each role can be involved in governance activities pertaining to multiple SOA project stages. Appendix B further provides master reference diagrams that illustrate the cross-project stage relationships of these roles with precepts and processes.
Additional Components
As previously stated, the scope of the SOA governance program goes beyond the definition of the SOA governance system. Some of the areas that the program will likely need to further address in support of pre-defined precepts and processes include:
- SOA Governance Tools – Products and technologies that enable the automation of SOA governance processes or that can monitor and collect relevant statistical data need to be identified and chosen in order to establish a suitable SOA governance infrastructure.
- SOA Governance Roadmap – Also referred to as the SOA Governance Program Project Plan, this document establishes the timeline, resources, budget, and other real-world considerations required to actually realize the goals of the SGPO and, more specifically, a specific SOA governance program.
There can be many more parts and extensions to an SOA governance program specific to the needs of a given IT department and its SOA project goals.
Step 3: Running the SOA Governance Program (Best Practices and Common Pitfalls)
The SOA governance program is a living entity that requires continuous maintenance. Over time, and in response to real-world issues and challenges, the SOA governance program will naturally evolve as precepts, roles, and processes are refined or added to the overall SOA governance system.
This section contains a series of best practices that provide guidance for successfully running an SOA governance program, as well as a set of common pitfalls that warn against factors and circumstances that can inhibit the adoption and evolution of the program.
Collect the Right Metrics and Have the Right People Use Them
Metrics, the fourth primary building block of a governance system, represent a vital element in the on-going operation of the SOA governance program. Having the tools and processes to consistently collect and disseminate key metrics is just as important as having the right individuals and groups assigned the responsibility to interpret and make decisions based on the reported metrics.
Provide Transparency and Foster Collaboration
Depending on its scope, an SOA governance program can affect a wide range of departments, groups, and individuals. Instead of creating the program in isolation, its development should be an open process, accessible for review and involvement to others within the IT department. Not only will this generate goodwill among those less enthusiastic about upcoming SOA adoption initiatives, but it will also allow people to voice concerns and provide suggestions. This type of feedback can help improve the SOA governance system, while also easing its eventual implementation.
Ensure Consistency and Reliability
SOA governance precepts need to be consistently enforced and SOA governance processes need to be consistently carried out. Providing a reliable means of managing and maintaining the SOA governance system is the foremost responsibility of the SGPO and depends heavily on the quality and detail with which the SOA governance program has been developed.
Besides human incompetence and poor SOA governance program definition, another reason this best practice may not be followed is an unexpected withdrawal of funding allocated to the SGPO. Should this occur, it is preferable to downsize the scope of the SOA governance program instead of trying to continue carrying out SOA governance activities without the necessary resources to ensure consistency and reliability.
Compliance and Incentives
An SOA governance system will introduce precepts that will sometimes restrict certain tasks that IT project team members have traditionally been free to complete by using their own judgment. At the same time, precepts also help make critical decisions for IT professionals that can ease their responsibilities while also guaranteeing consistency across services and service-oriented solutions. It is important that project teams embrace SOA governance precepts and processes and that they clearly understand how and why new types of compliance are required, while also fully acknowledging that their judgment and freedom in other areas are still required and relied upon.
Furthermore, offering formal incentives for regularly supporting precepts can go a long way to fostering consistent adherence. Because people will generally do that for which they are most rewarded, an absence of incentives can encourage them to violate or ignore SOA governance precepts. When this happens, something generally needs to change: the incentive, the precept, or the people.
Education and Communication
SOA governance systems can impose precepts more restrictive than traditional IT governance systems. Furthermore, some organizations can find it difficult to fully mandate the adoption of and compliance to SOA governance precepts. Even when compliance is required, in some IT cultures, groups or individuals can still choose to “rebel” by intentionally disregarding precepts because they are considered too burdensome.
Regardless of whether compliance to SOA governance precepts is voluntary or mandatory, it is critical that everyone affected fully understand why these precepts exist and how their compliance ultimately results in tangible benefits. Furthermore, it can be helpful to specifically address the common question: “What’s in it for me?” Fostering a true understanding of how support for the SOA governance system can result in personal benefit will further help unify IT project teams and personnel.
For this purpose, the SGPO must put together an education and communications program. This program must begin by establishing SOA terminology, concepts, and practices using a common vocabulary that all project team members can understand. It must then introduce the SOA governance system and impress its virtues.
Common Pitfalls
From the many failed and successful SOA adoption initiatives has emerged a set of common pitfalls that pertain directly to establishing and running an SOA governance program:
- Lack of Recognized Authority – The SGPO must be endowed with the responsibility and authority to develop and execute the SOA governance program. For this to happen, other IT departments and project teams must accept that authority. When the SGPO’s authority is ignored or not recognized, there needs to be recourse. If the lack of recognition persists, there need to be consequences for those who refuse to provide support.
- Misalignment with IT Governance – An SOA governance system must be consistent with and supportive of existing corporate and IT governance systems. If other IT governance precepts and processes are not taken into consideration, the SOA governance system can become inadvertently misaligned. This will result in conflicts and can further introduce risks to the IT department as a whole.
- Overestimating or Underestimating Cloud Computing Factors – There are various ways that cloud platforms and technologies can be made part of the planned SOA project. An organization may have or may plan to establish a private cloud comprised of standardized IT resources that require distinct administration processes, or it may be moving IT resources to a public cloud that imposes non-compliant requirements that may require even more distinct administration approaches. Either way, it is important for the SGPO to be open and flexible regarding these possibilities and—if cloud deployment is a possibility—to fully understand the consequences of having some or all services or IT resources of a given project deployed in cloud environments.
- Impractical or Overly Formal Processes – SOA governance processes are intended to help enforce and organize the application of precepts. Sometimes it can be tempting to create highly structured and detailed processes that cover all possible bases. Although such processes may be thorough, they can be too burdensome, onerous, or time consuming to carry out consistently in the real world. When designing SOA governance processes, consider the impact of the process on the project lifecycle and timeline and investigate any opportunity to streamline and automate parts of the process. Tools that integrate the governance process directly with development or administration platforms may further be helpful in allowing developers and administrators to efficiently identify and fix compliance issues.
- Poor Documentation – SOA governance precepts should be well-documented and disseminated. Many precepts require human interpretation, which means that people in the trenches will need to clearly understand how and when to apply them. Sometimes members of the SGPO take the formality of an SOA governance system too seriously. As a result, precepts and processes can be documented using overly academic or technical language. This can make the documents difficult to fully understand and, at times, inaccessible to some project team members.
- Overspending on SOA Governance Tools – SOA vendors have developed highly sophisticated administration and management tools (commonly labeled as “governance” products) with various design and runtime features. While powerful, these tools sometimes provide functionality that is not needed or not suitable for an organization’s specific governance requirements. Further, these tools can be very expensive, especially in larger IT enterprises. Therefore, it is often worth waiting to invest in a full-blown SOA governance infrastructure until an SOA governance program has matured to the extent that the actual design and runtime automation requirements can be identified and well defined. Otherwise, over-spending or mis-spending on governance tools and technology can put a significant dent in an SOA initiative’s overall ROI and further limit funds that may have been better allocated to supporting the SGPO in other areas.
SUMMARY OF KEY POINTS
- An SOA governance program encompasses the models that comprise an SOA governance system and further provides actionable artifacts that determine how the system will be established and maintained.
- A basic framework for an SOA governance program consists of three primary parts that address the assessment of the current organizational state, the planning and building of the program, as well as its evolutionary operation.