Home > Articles > Web Services > SOA

This chapter is from the book 6.4 The SOA Governance Program

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:

  1. Assessing the Enterprise (or Domain)
  2. Planning and Building the SOA Governance Program
  3. 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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020