SOA Governance: Achieving and Sustaining Business and IT Agility

In this article, InfoQ publishes the entire Chapter 4: Governing the Service Factory of the book SOA Governance: Achieving and Sustaining Business and IT Agility by William A. Brown, Robert G. Laird, Clive Gee, Tilak Mitra.

Chapter 3, Building the Service Factory, of the book deals with the importance of setting up “a service production line to automate SOA development activities, and outlined the tasks, roles, and responsibilities needed to establish such a service factory.”

The chapter presented in this article offers practical advice on governing such a Service Factory including a case study and guidelines for defining, developing, testing, deploying and operating services and business processes.

---

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning”

—Rick Cook

Chapter 3, “Building the Service Factory,” discussed the value of establishing a service production line to automate SOA development activities, and outlined the tasks, roles, and responsibilities needed to establish such a service factory. Chapter 3 also described a set of work products whose adoption can implement practical SOA governance for the Plan & Organize and Program Management Controls domains introduced in Chapter 2, “SOA Governance Assessment and Planning.”

This chapter covers a practical approach for governing both the operation of the service factory and the management of services after they have been deployed to production.

Essential Competencies for Succeeding with SOA

An organization needs certain core technical competencies if it is to succeed with SOA. Good SOA governance is all about developing these competencies and creating governance mechanisms that ensure the service factory runs as smoothly and as efficiently as possible. The following subsections define these core competencies.

Effective Requirements Collection

The old adage “garbage in, garbage out” perfectly expresses the importance of capturing requirements correctly. It is simply impossible to build good software without precise functional and nonfunctional (i.e., technical) requirements. SOA has the major advantage that services should represent some clear agreement or contract between the consumers and developers. As long as good naming standards are used, the purpose of each service invocation (operation) should be instantly clear to both business and IT staff.

There is an important degree of judgment to be made in terms of the effort made in capturing and reconciling requirements from all prospective consumers of a new candidate service. In an ideal world, all potential consumers of each service will be canvassed for their specific requirements, and a service designed that accommodates the full set of needs expressed:

• This has the theoretical advantage of reducing any need for future reversioning of the service, and encouraging maximum reuse (both major positive goals).
• Unfortunately, it has the practical disadvantage of consuming a significant amount of analyst resources, and potentially adding complexity and cost to the development of the first version of the service.

The current balance of opinion is that some kind of 80/20 rule applies: 80% of potential consumer requirements can probably be decided by a skilled analyst with 20% of the effort of an exhaustive study. Defining optimum service granularity, service design, and quality of documentation is as important an enabler of future reuse as an exhaustive initial consumer and requirements analysis.

Creating and publishing a catalog of requirements is critical to encouraging reuse and avoiding unnecessary duplication. Creating a high-level business process model and a common glossary of business terms is a critical precondition to creating a requirements catalog.

An excellent practice is to define the nonfunctional requirements, together with criteria for testing and acceptance of the service, at the same time as the requirements are being captured.

Competency in Service Design

Although service architecture and technical details beyond the scope of this book, we need to make some comments in terms of governing the service design process:

• It is essential to have a formal set of critical architectural work products to guide service designers. These include architectural principles that must be followed, architectural decisions that need to be complied with, recommended design patterns, and a formal target production. A best practice followed by many large organizations is to create an architecture review board (ARB) that is responsible for maintaining the vitality of such architectural assets.
• A strongly recommended best practice is to encourage (ideally mandate) regular service design reviews that include as wide a range of technical talent as possible. This has the joint advantages of optimizing the design of each service, promoting consistency, ensuring compliance with standards and best practices, and, not least, helping to grow the architectural skills of the more junior team members through on-the-job mentoring.

Competency in Service Development

Modern software development kits (SDKs) or tools make the physical SOA development processes relatively straightforward, and using them promotes consistency of technical approach and high quality. In this chapter, we discuss some work products that can help to monitor and assist service development.

Competency in Service Testing and Deployment

A reputation for quality is hard to gain and easy to lose. Thorough testing and an efficient and error-free deployment process are essential to gaining and maintaining a reputation for quality. Again, we describe some work products to help govern these processes.

Competency in Operational Management and Monitoring of Services

One of the easiest ways to lose a reputation for quality is to have products that perform badly or that keep breaking down, so we also address this important area from a governance perspective.

Service Development Lifecycle Control Points

Most organizations already have some type of system development lifecycle (SDLC) and a methodology that is used to perform development, although we often see in practice a lack of enforcement of that approach across different business units, and even if a set of best practices, standards, policies, and patterns has been defined, they are not always enforced.

Effectively enforcing best practices and a consistent SDLC provides a reasonable entry point for real governance, while not being a huge stretch from what is already being performed via the SDLC. At the same time, if the governance maturity level of the organization can be increased to the degree that it is able to govern the SDLC, the organization is then in a much better position to proceed to the next phase of the SOA governance cycle and create program and organization governance.

The danger here for even initial attempts at SOA governance is that often some key individuals view the imposition of any process or governance as being something that might apply to other people but not to them personally. For them, it’s an overengineered, useless exercise that just gets in the way of meeting their own deadlines. So, many governance processes are simply bypassed, or they’re followed in a less than an enthusiastic manner. The main reason for this is that governance is imposed from the outside and the execution is onerous.

What would happen if governance were mostly automated, easy, and added value to the development process and actually helped with project deadlines? Would the skeptics be more willing to take the medicine if it genuinely eased their pain?

To adequately govern the SDLC, there is a need to establish measurements, policy, standards, and control mechanisms to enable people to carry out their governance roles and responsibilities as efficiently as possible, without introducing overly bureaucratic procedures.

Governance of the SDLC may be characterized by the sorts of decisions that need to be made at certain “control points” within the process of services development. A control point is a decision checkpoint that provides an opportunity to measure adherence to the established processes, whether you are on track to meet the targets and goals you have established, and then decide whether the way the processes are executed or managed needs adjusting. Knowing what decisions involved in the process are critical, when to make them, and understanding what measurements are needed to monitor those processes are all essential aspects of governance.

Certain activities within a process may be associated with a control point. At the end of each identified activity, there is a control point at which the governance function decides whether the program is ready to move to the next activity. Each of these milestones is a control point.

At its essence, the governance of the SDLC provides a way to identify control points and to define the governance rules. At each control point, it is necessary to identify the following:

• The roles for who does what at the control point
• The policies to be applied at the control point
• Measurements at each control point that should be applied and collected for later governance vitality actions
• The proof of compliance records to be created and archived

A control point will be created where there is a demonstrated advantage weighing the standardization and efficiency provided versus the time, effort, and possible project delay. The control point enables SOA governance the opportunity to ascertain progress, to communicate this progress, to forecast efforts for subsequent phases of the SDLC based on scope and issues found, to review and report compliance, and to facilitate the injection of expertise and qualified review of the artifacts, process, or decisions made by the development team.

Control points don’t have to consist of huge formal meetings. Services and most automated business processes are smaller entities than projects, and there are many more of them. Therefore, the existing governance approach has to be streamlined or it might grind to a halt. We’ve found in practice that effective control point reviews can be made during regular—typically weekly—sessions of a subset of the SOA enablement. A real productivity aid in performing these control point reviews is the use of previously completed checklists, signed off by one or more senior professionals as certification that one or more tasks has been completed successfully, and that the service, process, or other work product is fit for purpose and ready in all respects for the next task in the development process. These checklists should be viewed as contracts between different experts in the service development process. The most important part of the checklist is the signature block to show who exercised approval authority; people tend to be careful about the quality of anything that carries their personal reputation with it.

Another productivity aid is the use of automated tooling. As much of the governance control point as possible should be automated. This aids in better near real-time feedback to the developers and provides an easy method to recheck work that has been updated. In addition, human beings are busy and will tend to apply governance in an inconsistent manner. Machines are consistent but not usually as flexible as needed. The combination of the two provides an optimal governance mix.

Let’s look at the control points needed to govern a generic development lifecycle, at least at a high level. Figure 4.1 represents a “governance dashboard” monitoring a typical SDLC with an eye toward the key concepts and the points where they must be addressed by SOA governance.

Figure 4.1 Software Development Lifecycle Governance Dashboard

As mentioned previously, we need a streamlined process that can handle the large number of services and automated processes that we need to implement to have real impact on business agility and flexibility. However, that streamlined process must not sacrifice the quality of governance just because of the need for extra speed. That would be an unacceptable trade-off.

Some organizations deal with highly regulated processes that have mission-critical or life-critical products and need to apply highly formal, auditable governance to manage the risks involved. Other organizations have processes with lower associated risks that can be more lightly regulated. We have found in practice that the same governance process can handle both these extremes perfectly well. If there is a need for stricter governance, it can be met with tighter policies at the control points together with more stringent policy enforcement and compliance measurement. If less-strict governance is more appropriate, the same process can be used with less restrictive policies, fewer audits, and lower levels of checklist signoff required.

Even within a single organization, different processes may require different styles of governance. Some processes, such as service certification, require stricter governance than other processes, such as solution architecture. Different organizational cultures require different levels of autonomy in decision making. Good governance requires good judgment.

First, let’s update our Figure 4.1 with the location of these control points so that you have a visual representation in mind as you read their descriptions. Figure 4.2 shows where the control points occur in that development cycle.

Figure 4.2 Software Development Lifecycle with SOA Control Points

Here are descriptions of these control points.

Business Requirements and Service Identification Control Point

For an SOA approach, there is an emphasis on creating services that provide agility and reuse for the business. This first business requirements and service identification control point consists of a high-level review to determine that services are being identified in accordance with the services selection and prioritization policies that were described in Chapter 3, “Building the Service Factory.”

This first business requirements and service identification control point should address the following types of questions:

• Business goals. What are the business goals that the business seeks to attain and how do we measure the benefits or progress toward the business goals via key performance indicators (KPIs)?
• Do the requirements as we currently understand them clearly support those goals, and do they align with the business heat map described in Chapter 3?
• Are those requirements sufficiently understood and agreed to? Are they presented in a form such as use cases, business process models, sequence diagrams, or class diagrams that are consistent with the SOA development approach?
• How do we provide traceability of the requirements so that we can ascertain that those requirements have been met during the development process? Have those requirements been entered into an enterprisewide requirements and business rules catalog? Is there any conflict with existing entries in that catalog?
• Which of those requirements could be translated into good candidate services, either because they represent functionality that may be needed by multiple consumers or that might be needed for process automation? Which requirements could be better supported by deploying applications, automated processes, or manual processes?
• Where we have identified candidate services, have we identified potential consumers, and determined whether any of them have specific requirements that should be considered?
• Given finite IT resources, what development priority should we assign? Is ownership of any new candidate IT asset defined, and is outline funding available for its development?

Solution Architecture Control Point

Different IT developers and groups, if left to make all design decisions on their own, would invariably use completely different platforms, coding languages, tools, styles, methods, and techniques. This variation adds cost and complexity to the ability of the business to make future changes, and makes future maintenance very hard and costly. Further, it reduces the reliability, stability, and interoperability of the organization’s IT assets. We have seen this problem at many organizations that we have visited. Simply put, the purpose of the solution architecture control point is to prevent that expensive multiplicity of approaches from occurring ever again.

Essentially, any proposed IT artifact that makes it past this control point is part of the IT build plan. For the area of solution architecture, the governance should control for a series of criteria the following:

• Do the proposed standards, policies, and reference architectures—the solution architecture—identify the standards, policies, and design patterns to be followed in the service implementation? This will include reference architectures, platform standards for hardware, and software-usage standards.
• Have any reusable assets been identified and assessed for suitability? Has the service sourcing policy been followed?
• Have the nonfunctional requirements been identified and assessed? This includes the number of transactions per time unit, a busy hour analysis, the service performance required, presentation access to the service functionality, data managed by the service, space required for the installation of the service, and any dependency and configuration requirements. Governance must validate that all these are considered and addressed.
• Governance must validate that all security policies are being considered and addressed.
• Governance must validate that all legal and regulatory policies are considered and addressed.
• By this stage in the development of IT assets such as services or automated processes, the technical IT staff involved should have a pretty good idea about the complexity of the tasks involved, and the probable level of resources required to complete development. Should development of the asset be confirmed, the scope reduced, or the asset abandoned?

Service Specification Control Point

A service specification should be created for each service whose development has been approved. Best practices for service design must integrate both an IT and business perspective for the design of the interface and the responsibilities of each service. Because the service specification is, in effect, the organization’s face to business partners, customers, and other stakeholders, the service externals—those details of a service that are to be made public—become an important part of the overall business design. The design should take into account the requirements of all potential service consumers (within reason), and be created at a granularity that maximizes business value. For the area of service identification and specification, the governance should control for a series of criteria the following:

• Does the service identified make sense, is at the right granularity, and is not duplicating an existing service?
• Does the service specification follow all SOA standards and policies?
• Does the service specification follow the messaging model? If not, should an exception be granted?

Service Design Control Point

After the service solution architecture has been turned over to the design team, a number of design elaboration decisions must be made. Collectively, these form the service internals—a set of design models, notes, and advice that will guide the service developers as they create and test the service code. For the area of service design, the governance should control for a series of criteria the following:

• Has a service architect confirmed that the design should be able to meet the nonfunctional and functional requirements for this service?
• Have the service designer and data architect agreed that the service can be made to conform to the signature (that is, inputs and outputs) described in the service externals?
• If a service is wrapping an existing or planned application, are the necessary interfaces to that application well defined and stable (that is, won’t change if a new version of that application is installed)?
• Have the monitoring metrics (for example, usage, quality of service [QoS] levels) been established?
• In the case of automated processes, have the monitoring requirements been defined and planned?
• In the case of long-running automated processes, have all the necessary actions to handle recovery from process errors or technical failures been addressed?
• Is the overall quality and level of completeness of the service specification package good enough that the service developers or process developers can complete development without further input?

Service Build Control Point

After the service design has been turned over to the service build team, a number of implementation decisions need to be made before development of the code or executable model. In the interests of consistency and quality, we strongly recommend the use of code walkthrough reviews, where peers (that is, other service developers or process developers) review the work in progress and offer constructive criticism.

The service build control point is effectively the last of these code walkthroughs, and should be performed with slightly more formality than the others. Questions that should be addressed include the following:

• Was the asset coded in accordance with the design?
• Does the code follow the accepted coding standards?
• Have all the associated artifacts (for example, load libraries, metadata files, resources) been defined to create a transportable build? Have the versions of each of those artifacts been checked to see that there are no version conflicts with services already in production?

Service Test Control Point

Service testing is different from testing complete IT solutions or applications. Because services and automated processes do not have their own user interface, it is not possible to perform user acceptance testing directly on services or automated processes. Code frameworks or specialized tools are needed to exhaustively test services and automated processes thoroughly to avoid uncovering problems during later formal user acceptance testing when the rest of the IT solution that uses those services or processes has been completed.

SOA governance must ascertain that the services test is being performed in a manner conducive to a services approach, and that exhaustive functional and nonfunctional tests have been passed before releasing any SOA asset to production. The service test team must create and use the right service test environment with tools and data to affect a comprehensive test. This should include the following:

• Using the optimum set of service test tools and frameworks.
• The use of an automated build and test environment that can enable fast changes of the tested software and regression testing. This environment must closely resemble the production environment.
• A load/stress test tool to test nonfunctional requirements, specification, creation, and loading of realistic but artificial test data.
• A test management reporting tool to keep management apprised of the testing status.
• Trace the test case to the original user requirements.

Service Certification and Deployment Control Point

The objectives of the deployment are to migrate the services to the production environment while minimizing client downtime and impact on the business. This process is subject to many errors if performed manually. It is vital that the correct version of the services be deployed and that any deployment binding with other services and applications be performed quickly and correctly. Areas for governance to validate include the following:

• The use of a tool that automates the deployment and back-out process.
• Final certification checks have been made against the services to verify compliance with all policies and standards and being able to demonstrate that what was tested matches not only the requirements but what was delivered, and that no corrective changes made during testing have invalidated other test results.
• IT operations have completed acceptance testing and have formally accepted the asset, signifying their confidence in being able to operate it within the terms of the QoS specified for it.
• The service registrar and business service champion have reviewed the service description in the service registry and approved it.

Certification of a service or automated process is a formal “passing out” ceremony, and granting of certification should signify that the SOA enablement team is happy for their reputation to be associated with the performance of the new asset.

Service Vitality Control Point

Service vitality takes place periodically as part of SOA governance to check up on and update the governance processes, procedures, policies, and standards in reaction to the results of the real world. This involves examining any and all lessons learned in any of the SOA planning, program control, development, or operations activities. It also includes such things as comments and feedback from all stakeholders and an examination of any common patterns (for example, common exemption requests or common reasons for failure to pass one or more control points) that need remedial action. Metrics in the efforts required for each stage of the development process can show trends that indicate improvements or declines in their vitality.

A formal service vitality control point review should be conducted every three to six months to determine whether the SOA transition remains on track, and whether the level and style of governance is optimal.

Individual service or automated processes should be reviewed every 6 to 12 months. Usage data of all versions of each service can determine any “stale” versions that can be deprecated or deleted, and whether the deployment options taken and decisions on who should own and who should access each service are optimal.

The Service Development Domain

“Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.”
—Kurt Vonnegut

The Service Development domain covers the lifetime of services or automated processes from an original concept through to deployment into production. This section covers advice on governance of this development domain. Chapter 6, “Managing the Service Lifecycle,” looks in a little more detail at governing specific steps with the service lifecycle.

Most IT departments we have visited currently spend the majority of their resources on system maintenance. One reason for this is that most IT systems consist of applications where there is generally no clear separation between business logic, graphical user interface (GUI) management, and workflow. Any change to an application of this type risks damaging all of these three aspects, and maintenance becomes labor intensive without good design documentation—which is more often than not a major issue.

SOA makes a clear distinction between business logic and workflow. SOA is all about packaging pure business logic as reusable transactional services, and using executable models to manage workflow. SOA does not become involved with any particular style or fashion of GUI or GUI control. In a fully SOA-aligned world, humans will make requests to IT systems to perform tasks, make decisions, or initiate business processes using whatever GUI is best suited to that job; automated business processes can in turn initiate tasks by invoking services or by requesting human intervention or involvement.

In this world, IT solutions grow incrementally as new business processes become automated, and interactions with third parties are increasingly performed using service executions without direct human intervention. Whenever new business initiatives, market forces, or governmental regulations require changes to operating procedures, new or revised automated business processes can be constructed rapidly by reworking or extending existing automated processes. We can expect technology to continue to change rapidly, so the users can interact with the IT systems in radically different ways in the future. Because the SOA approach insulates the user interface from the physical implementation of business function, we can expect that most of the services we create now will probably still exist in some form for the next 20 years or more, whatever interface is used to access them.

End-to-end service development is a complex process. Planning and governance has to be meticulous because there are many complex tasks with many interdependencies. There are critical tasks for governing service development that the governance specialist needs to address in the form of a transition plan that is created and worked just like any other project plan.

Key Capabilities Needed to Govern Service Development

The Service Development domain is highly complex and involves technology that is changing rapidly. Governing such complexity requires a high level of organizational and political skills, together with good knowledge, not just of the SOA technology itself, but how to use it optimally. Few individuals can combine those skills at a world-class level, so practical governance relies on close cooperation between some key technical and nontechnical roles. Close collaboration, and complete trust, among the SOA governance lead, the business service champions, the lead SOA architect, and the lead service architect is critical to ­success.

Table 4.1 describes the capabilities that the organization needs to govern service development, and recommends some key work products that can assist this complex activity. It is organized in the same way as Table 3.1 in Chapter 3.

Table 4.1  Service Development Domain—Capabilities, Risks, and Remedial Work Ducts

Service Development Domain Work Product Definitions

In the preceding section, we introduced a number of work products that have been proven to be effective in helping to govern successful SOA transformations. Although we will describe them as if they are individual text documents or diagrams, in practice, many of the technical work products are best managed as models within tools specifically designed for manipulating them. Models of service internals, for example, should be edited and distributed using a specialized tool that can visualize and validate the interactions between the service components, and then generate most of the service code. No text document or simple picture can do that.

Documenting requirements involves many subtleties and creates multiple opportunities for misunderstandings to occur. A process model contained in a specifically designed process modeling tool that ensures logical continuity, and that requires all possible logical branches to be handled, is much more likely to be interpreted correctly than a use case written as a textual document. Better still if the modeling tool supports full emulation of the process steps.

Many of these work products represent intermediate deliverables that are passed from one professional to another on the service production line. These artifacts must be seen as representing a formal contract between the work product producer and the work product consumer. Delivery of the work product should formally signify that it is of the necessary quality and degree of completeness, and delivery of a substandard work product should be seen as a serious breach of contract. The control points described earlier in this chapter represent checkpoints to assess the quality of the key work products.

Some of the work products that can help govern the Service Development domain have already been described in Chapter 3, where, in addition, the roles of those involved in their production were defined. When creating the SOA governance plan, the SOA governance lead will need to select and create the work products that best manage SOA development service development activities without detracting from the ability to get projects done on time. Some of these work products have already been defined in the preceding chapter. Here are the descriptions of those new work products you should consider adopting, in alphabetic order.

Control Point Minutes

Description: These serve as a record of the results of the key SOA governance reviews, and can provide useful input to any systemic issues and the vitality of the SOA governance approach. The SOA governance lead or program management office (PMO) should examine these minutes to look for any common patterns of issues that need to be addressed by the creation of additional architectural decisions, design standards, best practices, or additional training.

Purpose: Ensure continued vitality of the SOA development approach.

When needed: Should be completed immediately after any service control point.

Responsible: Control point reviewers, PMO.

Accountable: SOA governance lead or PMO.

Consulted: Control point reviewers.

Informed: SOA enablement team.

Executable Modeling Approach Work Product

Description: This defines standards and best practices for developing executable business models, helping to ensure their consistency and quality.

Purpose: Define how automated business processes will be created.

When needed: Create this as soon as the SOA development approach work product has been approved.

Responsible: Service architects, process modelers, process developers, business analysts, monitoring developer.

Accountable: Lead SOA architect or lead service architect.

Consulted: SOA enablement team.

Informed: Process modelers, process developers, monitoring ­developer.

Functional and Nonfunctional Requirements Work Products

Description: For each service, these define exactly what each operation does, and how well it is expected to do it. Nonfunctional requirements include such factors as performance, availability, systems management, and security. There will generally be a fairly standard set of nonfunctional requirements that apply to most services, and individual services should have to define only additions and exceptions to them. Targets such as latency should be defined in measurable terms; for example, “95% of individual executions of this operation should have a latency of less than 1 second, to the glass on a portal screen, and 90% of executions should complete in less than 1.5 seconds.”

As already stated, a good practice for cataloging functional requirements is to maintain a requirements and business rules catalog in a database, indexed by the corresponding business entity in the enterprise data model (EDM) or messaging model (MM). This can avoid wasted effort in duplicating requirements analysis. Requirements should be classified into Mandatory, Valuable, and Optional. In the case where requirements are specific to a single line of business (LoB), this should be made clear in the text describing the requirement.

Purpose: Good management of requirements can avoid duplication of effort and help enable reuse.

When needed: A standard set of nonfunctional requirements should be created as soon as the SOA development approach work product has been approved; functional requirements should be assessed at the business requirements and service identification control point, and nonfunctional requirements should be assessed at both solution architecture and service design control points.

Responsible: Service architects and business analysts (for nonfunctional requirements), business analysts and process modelers (for functional requirements).

Accountable: Business service champion.

Consulted: All service architects, business analysts, process devel­opers, service developers.

Informed: SOA enablement team, QA, testing team.

Functional and Nonfunctional Requirements Checklist Work Product

Description: This checklist is used at the business requirements and service identification point, and nonfunctional requirements should be assessed at both solution architecture and service design control points to ensure that all potential consumers are satisfied that their individual requirements have either been met or have been explicitly ruled out of scope in the current planned service release, and that the design approach for this service should be able to satisfy the NFRs and SLA terms and conditions.

Purpose: Ensure the highest possible quality of services.

When needed: Functional requirements should be assessed at the business requirements and service identification control point, and nonfunctional requirements should be assessed at both solution architecture and service design control points.

Responsible: SOA governance lead creates the template, lead business analysts and service designers complete the checklist for individual services.

Accountable: Business service champion.

Consulted: Business analysts.

Informed: SOA enablement team.

Regulatory Compliance Approach Work Product

Description: Specifies what regulations apply under which circumstances (for example, the country in which the service requestor is based), together with the processes that will be followed to ensure compliance.

Purpose: Avoid the embarrassment and potential punitive consequences of disobeying applicable regulations.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: SOA lead architect, PMO, business service champion, security architect.

Accountable: SOA executive sponsor or existing IT governance ­function.

Consulted: SOA enablement team.

Informed: PMO.

Regulatory Compliance Checklist Work Product

Description: The template for this document is created by the security architect and any existing IT governance group, and then approved by the lead SOA architect. Individual instances of this checklist are completed by the service designer and approved by the security architect. The regulatory compliance checklist for a given service should be endorsed at multiple control points to ensure that no changes have been made to the service that might invalidate the integrity of its security.

Purpose: Avoid the embarrassment and potential punitive consequences of disobeying applicable regulations.

When needed: Should initially be prepared in time for the service specification control point, then re-reviewed at the service build, service test, and service certification and deployment control points.

Responsible: SOA lead architect, PMO, service designer, service architect.

Accountable: Security architect.

Consulted: SOA enablement team.

Informed: PMO.

Service Acceptance Checklist Work Product

Description: A checklist used to confirm that IT operations agree that it can successfully operate and manage a specific service within the terms of its SLA.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed before the service certification and deployment control point, for which it is a prerequisite.

Responsible: IT operations.

Accountable: IT operations.

Consulted: Service architect, service designers, service testers.

Informed: SOA enablement team.

Service Build Management Approach Work Product

Description: The approach to build management must ensure that SOA components can be migrated easily among development, testing, preproduction, and production environments repeatedly, without error or omission.

Purpose: To maintain continuity of operation, it is essential that the approach to build management is error free, and that it is always possible to re-create any given build configuration.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: SOA lead architect, existing build manager.

Accountable: SOA lead architect.

Consulted: IT operations.

Informed: Service developers, process developers.

Service Build Plan Work Product

Description: This is the set of candidate service operations and automated business processes that comprise the formal SOA asset construction plan. This work product is an essential tool for managing SOA development in that

• It defines the results of the service prioritization.
• It’s a key control document for service development project management.
• It communicates the SOA development plan and status to the rest of the organization.

Note that services, in general, have multiple operations—for example, a Customer service may have such operations as lookupCustomer and modifyCustomer. Not all operations will have the same development priority; there is no need to create all operations of each service at the same time.

Purpose: Manage the service development priorities and communicate those priorities to the stakeholders.

When needed: Should be created as soon as any services are planned, and it should be updated weekly.

Responsible: Lead service architect, service registrar, SOA business analysts.

Accountable: Business service champion.

Consulted: PMO, service architect, service developer service designer, process modelers, process developers.

Informed: SOA enablement team, PMO.

Service Construction Estimation Metrics Work Product

Description: These are the resource metrics captured as a result of the service construction monitoring plan. They provide invaluable input to the project management of new services and SOA projects. A steady improvement in these metrics is a sign of growing SOA maturity and effective SOA governance.

Purpose: These are important metrics to enable effective governance of the service factory.

When needed: Should be created as soon as any services are planned and data is captured for every service that is created.

Responsible: Lead service architect, SOA governance lead, PMO.

Accountable: Lead service architect.

Consulted: SOA enablement team, PMO.

Informed: PMO.

Service Construction Monitoring Plan Work Product

Description: This is the plan to capture and continuously update metrics on the resource efforts needed to complete each step in the service and automated business process lifecycle. Typically, resource estimates for each construction step are grouped into complex, intermediate, and simple services/processes.

Purpose: These are essential metrics to enable effective governance of the service factory.

When needed: Should be created as soon as any services are planned and data is captured for every service that is created.

Responsible: Lead service architect, lead SOA architect, SOA governance lead, PMO.

Accountable: Lead service architect.

Consulted: SOA enablement team.

Informed: SOA enablement team, PMO.

Service Deployment Approach Work Product

Description: The current IT deployment approach should be adjusted to allow for the characteristics of services. Typically, the number of deployments cycles in a traditional IT development approach is limited to a small number of major increments each year, to maintain stability of the operational systems, whereas the deployment of services can be almost an everyday occurrence.

Purpose: Ensure that services are deployed in the optimum fashion at the most advantageous times.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: IT operations.

Accountable: Lead service architect.

Consulted: IT operations.

Informed: Service developers.

Service Design Checklist Work Product

Description: This checklist is used to ensure that the service internals contained in the service specification work product are high standard, complete, and unambiguous.

Purpose: Ensures the highest possible quality of services and reduces the need for rework.

When needed: A checklist template should be completed as soon as the SOA development approach has been approved. Instances of this checklist should be completed for each service before the service design control point.

Responsible: Service architect, QA, security architect create the template; service developers complete individual checklists.

Accountable: Service architect.

Consulted: Service designer, service developer.

Informed: SOA enablement team.

Service Design Walkthrough Notes

Description: These are relatively informal notes that describe the results of service design walkthrough sessions (for example, “chalk and talk” working sessions where service architects, designers, and developers meet to discuss the design of individual services, both to optimize that design and to mentor the less experienced staff members).

Purpose: Ensure continued vitality of the SOA development approach by identifying any common concerns that might require the creation of additional architectural decisions, design standards, best practices, or additional training.

When needed: Should be completed after every service design walkthrough session.

Responsible: Service designers, service developers.

Accountable: Service architect.

Consulted: Lead SOA architect.

Informed: SOA governance lead.

Service Deployment Checklist Work Product

Description: This is a checklist used to ensure that services are deployed in the fashion described in the service deployment approach, based on a template created as part of the service deployment approach. It should take into account the fact that some services may have multiple instances, multiple access channels, and different QoS levels for different categories of consumer, according to the requirements specified by the service architect or service designer.

Purpose: Ensures that services are deployed in the optimum fashion.

When needed: The service deployment checklist should be completed before the acceptance process.

Responsible: IT operations creates the checklist template with assistance from service architects. Service developers and service architects fill in a checklist for each individual service.

Accountable: Service architect.

Consulted: IT operations.

Informed: Service developers, service registrar.

Service Granularity, Visibility and Accessibility Checklist Work Product

Description: This checklist is used to ensure that services have the optimum scope and are visible and available to any potential consumer that may need to access them.

Purpose: Ensures the highest possible QoS, with maximum business value and reuse potential.

When needed: Complete this before the solution architecture control point and revalidate it at the service design control point.

Responsible: SOA governance lead creates the template, and lead business analysts and service designers complete an individual checklist for each service.

Accountable: Business service champion.

Consulted: Business analysts, service registrar, service designers.

Informed: SOA enablement team, PMO.

Service Level Agreement Work Product

Description: SLAs represent the terms and conditions of a contract among service consumers and service providers. IT operations is responsible for monitoring that both parties comply with all their terms and conditions. SLAs should include the following:

• Guaranteed QoS levels, based on the corresponding service nonfunctional requirements
• Technical support terms and conditions (hours of operation of the help desk, incident response times by problem urgency, and so on)
• Constraints on the service consumer (specifying, for example, that QoS cannot be guaranteed if the service consumer exceeds a given threshold in the rate of service requests)
• For any services that are being offered for a fee, either internally or externally, the pricing structure of service requests
• How version management will affect consumers such as how many versions of services will be supported, length of time support will be available for deprecated services, how much warning service consumers will have of changes, or service retirement

Purpose: Define contractual terms for service usage.

When needed: Standard SLA terms and conditions should be established by the SOA governance lead as soon as practicable.

Responsible: SOA governance lead, business service champion.

Accountable: Business service champion.

Consulted: SOA enablement team, PMO.

Informed: Service owners, service consumers, PMO.

Service Reusability Guidelines Work Product

Description: Based on the SOA development approach, this work product contains guidance to service designers on how to design services with maximum reusability.

Purpose: Ensures that services are designed so as to maximize their reuse potential.

When needed: Should be created as soon as the SOA development approach work product has been approved.

Responsible: SOA lead architect, service architect, SOA governance lead.

Accountable: Business service champion.

Consulted: Business analysts, process modelers.

Informed: SOA enablement team, QA.

Service Security Approach Work Product

Description: The optimum approach for implementing SOA security to enforce the following:

• Authentication and authorization of all service consumers
• Nonrepudiation of service execution requests
• Protection of enterprise data assets
• Encryption of all data transmitted over channels such as the Internet

Purpose: Create and maintain a secure SOA production environment.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: Security architect, lead service architect.

Accountable: Security architect.

Consulted: Operations management.

Informed: SOA enablement team.

Service Security Checklist Work Product

Description: Individual instances of this checklist are completed by the service designer and approved by the security architect. The service security checklist for a given service should be endorsed at multiple control points to ensure that no changes have been made to the service that might invalidate the integrity of its security.

Purpose: Ensure that services that do not comply with the requirements of the service security approach are never deployed into pro­duction.

When needed: Should initially be prepared in time for the service specification control point, then re-reviewed at the service build, service test, and service certification and deployment control points.

Responsible: The template for this document is created by the security architect and approved by the lead service architect; individual checklists are completed by a service developer and service tester, and then approved by a security architect.

Accountable: Security architect.

Consulted: IT operations.

Informed: SOA enablement team.

Service Sourcing Policy Work Product

Description: Based on the SOA development approach, the service sourcing policy describes how, once the need for a specific service or service operation has been established, the organization should choose between the options:

• Develop the service functionality from scratch.
• Use an existing IT asset or application, wrapped as a service.
• Buy a commercial, off-the-shelf (COTS) product that is or can be wrapped to be exposed as a service.
• Subscribe to an external software as a service vendor who performs that activity.

Purpose: Ensure consistency of approach in buy versus build ­decisions.

When needed: As soon as the SOA development approach has been approved.

Responsible: SOA governance lead.

Accountable: Procurement.

Consulted: Business service champion.

Informed: SOA enablement team, PMO.

Service Specification Work Product

Description: The service specification is not a single document, but rather a package that contains all necessary information needed to use, build, test, and certify that service or automated process. It should include the following:

• The service externals and service internals discussed earlier.
• Details of any interfaces to existing IT assets that the service will need to access.
• Functional and nonfunctional requirements for the service.
• Security information for the service (who can access it, authentication, encryption, nonrepudiation).
• Deployment options (for example, need for geographic diversity; “platinum,” “gold,” “silver” levels of service support)
• Monitoring and systems management requirements.
• Test plan and test data.
• The acid test of the level of completeness and accuracy of a service specification package is that it contains no ambiguity and that it provides a reasonably skilled offshore developer with all the information necessary to develop a high-quality code deliverable without the need for asking any questions to clarify any item it contains. For this purpose, models contained in sophisticated tools are much more valuable than words and pictures in most cases.

Purpose: Ensure the highest possible QoS.

When needed: Service externals need to be completed before the solution specification control point and the whole service specification completed before the service design control point.

Responsible: Lead service architect, QA, SOA governance lead create the templates; the service designer and service architect complete each service specification package.

Accountable: Business service champion.

Consulted: SOA enablement team.

Informed: Service consumers have access to the service externals, and only the SOA enablement team (specifically service developers and service testers) should be given access to service internals.

Service Specification Checklist Work Product

Description: This checklist is used to ensure that all service specification packages are created to the highest possible standards, contain all the information needed, and are clear and unambiguous.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed before the solution specification control point.

Responsible: Service designer, QA, and service registrar.

Accountable: Business service champion.

Consulted: SOA enablement team.

Informed: SOA governance lead.

Service Test Plan Work Product

Description: Thorough functional and nonfunctional testing of services is vital to ensuring their quality. For each service, this plan should describe all the tests that need to be carried out, and what the expected result should be.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed immediately after the service design control point.

Responsible: Service test manager, business analysts.

Accountable: Business service champion.

Consulted: Service architect, service designer, and business analysts.

Informed: Service testers.

Service Test Results Work Product

Description: These document the results of executing the service test plan, and cover both functional and nonfunctional testing. All tests must have been successfully completed before a service can pass through the service test control point.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed after testing is completed successfully and before the service acceptance control point. These test results should be examined regularly to look for any systemic issues that need to be addressed, for example, by additional training or by changing standards or best practices.

Responsible: Service testers, QA.

Accountable: Service test manager or QA.

Consulted: Service architect, service designer, and business analysts.

Informed: SOA governance lead, PMO.

Service Version Management Approach Work Product

Description: This defines how services and automated business processes will be version managed, and assigns responsibility for performing and verifying that this approach is followed in practice. It should include advice on designing services that are as forward compatible as possible—that is, that can be incrementally extended without impact to existing consumers. Chapter 6, discusses service version management in more detail.

Purpose: Define how services will be version managed.

When needed: Should be created as soon as the SOA development approach work product has been approved.

Responsible: Lead SOA architect, service architects, SOA governance lead.

Accountable: Business service champion.

Consulted: IT operations.

Informed: IT operations, service consumers.

SOA Development Performance Report Work Product

Description: These reports are based on continuously monitoring the actual analysis, design, construction, and testing efforts associated with constructing services or automating business processes.

These reports should show actual resources, explain any discrepancies with established service construction estimation metrics, and show trends. In the best case scenario, they reveal a continuous improvement in productivity and decline in rework!

Purpose: Ensure continued vitality of the SOA development approach and the vitality of SOA governance.

When needed: Should be completed and distributed every one to three months.

Responsible: Lead SOA architect, PMO, SOA governance lead.

Accountable: Lead service architect.

Consulted: Service testers.

Informed: SOA enablement team, PMO.

SOA Development Tools Work Product

Description: There are many fine software tools to assist in the development and testing of services and automated business processes, and any organization embarking on a transition to SOA should select a set of tools to improve their productivity. The most effective tools support the principle of model-driven development—that is, the creation of models of services or automated processes that are progressively refined until they are considered complete, at which time the code is generated automatically. Chapter 6 describes this in more detail.

Purpose: Create and maintain a productive development and test environment.

When needed: Should be created as soon as the SOA development approach work product has been created.

Responsible: SOA lead architect, service architects.

Accountable: SOA lead architect.

Consulted: Service developers, service assemblers, SOA business analysts, process modelers, process developers, monitoring developer, enterprise architects.

Informed: SOA enablement team.

SOA Development Lessons Learned Work Product

Description: At the end of any significant task in the service or process automation lifecycle, it is valuable to hold a relatively informal session to discuss any lessons learned from the exercise. Lessons learned should cover areas such as the SOA development process, work products, governance approach and level of governance rigor, and tools and techniques. Whether the lessons learned are positive of negative, they provide valuable insight into the vitality of the SOA development and governance process vitality.

Purpose: Ensure continued vitality of the SOA development approach and the vitality of SOA governance.

When needed: Should be completed and distributed once every four months.

Responsible: All control point reviewers.

Accountable: SOA governance lead or PMO.

Consulted: SOA enablement team.

Informed: SOA enablement team, PMO.

SOA Governance Policy Exemption Work Product

Description: The ability to grant exceptions to having to conform to common standards, best practices, or policies in case of established business need is important, and the exemptions process must be defined in the SOA governance plan, along with a definition of who is empowered to grant such exemptions. The level and type of exemptions and the reasons they were granted or refused are important measures of the SOA governance vitality:

• If there are few exemptions requested, it is possible that either the standards are too lax, the degree of governance applied is inappropriate, or that some developers are ignoring the governance approach or rules altogether.
• If there are too many exemptions requested or granted, the standards might be too restrictive.

Purpose: Record the granting or refusal of requests for exemptions from compliance with standards or best practices.

When needed: Should be completed whenever a request is received for exemption from a policy or standard.

Responsible: SOA lead architect, SOA governance lead, QA, PMO.

Accountable: Lead service architect or enterprise architect.

Consulted: Service architects.

Informed: Exemption requestor (typically a service architect or service designer).

SOA Reuse and ROI Report Work Product

Description: Based on the SOA reuse and ROI monitoring plan, this regular report should assess, as objectively as possible, the real levels of reuse and ROI that have been achieved. Some of the data to produce this report will be obtained from IT projects, through the medium of the project benefits and ROI work product.

Purpose: Measure and report the real business value of the SOA transformation initiative.

When needed: Every one to four months, or alternatively displayed on a real-time governance dashboard.

Responsible: SOA governance lead, lead service architect, PMO.

Accountable: Business service champion.

Consulted: SOA enablement team, service consumers, IT operations.

Informed: Chief executives, PMO, SOA enablement team.

The dependencies among these work products are depicted in Figure 4.3. The format is the same as for Table 3.3 in Chapter 3. Again, those work products marked with an asterisk (*) should be revised every 6 to 12 months to ensure continued vitality.

Figure 4.3 Service Development Domain: Work Product Dependencies

The Service Operations Domain

“Civilization advances by extending the number of important operations which we can perform without thinking about them”
—Alfred North Whitehead

This section covers governance of services and automated business processes in a production environment. SOA offers both benefits and challenges to IT operations. The benefits include the following:

• It’s much easier to monitor the usage and QoS provided by services, and there are some excellent commercial products that support this activity, some of which even provide real-time “dashboards” to display items such as QoS and usage statistics.
• Services offer much richer deployment opportunities and much more information about who uses them than do applications.
• A generic security mechanism can protect all services from security exposures or malicious threats.

The challenges include the following:

• SLAs need to be continuously monitored, and SLA violations need to be recorded.
• Frequent deployment of individual services can represent a threat to the stability of the production environments unless the service quality, build management, and deployment processes are highly effective.

Key SOA Governance Tasks Involved in Operating Services

Key tasks in ensuring that SOA operations are governed effectively include the following:

• Providing effective technical support for services and resolving software quality incidents efficiently and rapidly
• Monitoring the execution of services and automated business processes, most especially in terms of monitoring their compliance with the terms of their SLAs
• Maintaining the vitality, reliability, availability, and performance of the operational systems

Most organizations have a separate IT operations organization to manage the production IT systems. Table 4.2 describes the key capabilities that an IT operations organization needs to enable effective governance of services.

Table 4.2  Service Operations Domain: Capabilities, Risks, and Remedial Work Products

Service Operations Domain Work Product Definitions

This sections contains a list of descriptions of the work products whose production can help govern the Service Operations domain. Most of these work products should exist in any moderately well-governed IT production environment, but some of these need additional extensions for SOA. Again, they are organized in alphabetic order, and work products that have already been defined in Chapter 3 are not repeated. The roles involved in creating these products were also defined in that chapter.

Deprecated or Decommissioned Services Work Product

Description: This is just a list of obsolete services that have been or will eventually be discontinued. Deprecated service should continue to be supported, but no new consumers should be able to access them. The number of such obsolete or obsolescent service versions should help determine the efficacy of the service version management approach—in an ideal world there would be few if any of these.

Purpose: Monitor SOA operational vitality.

When needed: Every four to six months.

Responsible: Service registrar

Accountable: Business service champions.

Consulted: Service consumers, PMO.

Informed: SOA enablement team, PMO, service consumers, IT operations.

Problem Incident Log Work Product

Description: This is a basic IT governance work product that should be updated to reflect the specific needs of service consumers and users of automated business processes. It records details of any technical problems that have occurred and how they were resolved.

Purpose: Used to provide invaluable information about the quality of deployed services. The SOA governance lead and lead SOA architect should look for any system quality issues and correct them as a matter of urgency.

When needed: Should be completed before any SLAs are published, and the SLAs should contain clauses that reflect the level of technical support that will be provided.

Responsible: Help desk / technical support staff.

Accountable: IT operations manager, technical support manager.

Consulted: SOA governance lead.

Informed: Problem reporter, PMO.

Quality of Service Goals Work Product

Description: QoS goals set explicit targets for performance and operational efficiency that services and automated processes will be measured against. The goals should exceed those specified in individual service nonfunctional requirements and SLAs by a small increment to ensure that those contractual conditions are more secure than the QoS goals themselves.

Purpose: Monitor performance of service operations.

When needed: Created as the first services are deployed, then updated every six months or so.

Responsible: Lead service architect, lead SOA architect, SOA governance lead.

Accountable: IT operations manager.

Consulted: Business service champions, PMO, individual business units.

Informed: IT operations, SOA enablement team, PMO.

QoS Monitoring Plan Work Product

Description: This is the plan to monitor execution of services and automated business processes against the QoS goals. This plan should include monitoring the business impact of any SOA infrastructure problem. The breakdown of a single network element might seem relatively insignificant, but if it represents a single point of failure in a major service or function of the SOA infrastructure, it may have significant business impact, unless the operational model includes full redundancy.

Purpose: Ensure that QoS goals are met.

When needed: Created as the first services are deployed, and then updated every six months or so.

Responsible: Lead service architect, lead SOA architect, SOA governance lead, monitoring developer.

Accountable: IT operations.

Consulted: Business service champions, QA, PMO.

Informed: SOA enablement team.

QoS Report Work Product

Description: This a regular report (or ideally a component on a real-time governance dashboard) that compares actual QoS with the QoS goals on a service-by-service basis.

Purpose: Ensure that QoS goals are met.

When needed: At least monthly, ideally updated online in real time.

Responsible: Lead service architect, SOA architect, SOA governance lead, monitoring developer, IT operations.

Accountable: SOA governance lead or IT operations manager.

Consulted: IT operations.

Informed: SOA enablement team, SOA executive sponsor.

Service Operational Vitality Report Work Product

Description: This is a regular summary report that provides an overview of the status of SOA operational vitality, including growth in service usage (both in terms of new service consumers and growth in service execution requests), QoS reporting, and new services deployed during each reporting period. It draws from several sources, such as the QoS report, SLA compliance report, and deployed services and service usage data provided by IT operations.

Purpose: Communicate SOA operational vitality.

Responsible: SOA governance lead, monitoring developer, and PMO define the structure and layout of the report; IT operations and service registrar provide the data.

Accountable: IT operations manager or SOA governance lead.

Consulted: Business service champions, IT operations.

Informed: SOA enablement team, SOA executive sponsor.

Service Usage Data Work Product

Description: One of the major advantages of SOA over more traditional software development styles is that it is possible to capture a great deal of operational information about usage of services and automated processes. In fact, it is impossible to govern the Service Operations domain, or to bill third parties for service usage, unless this information is captured and recorded.

It is impossible to capture usage statistics manually, so it is essential that the SOA infrastructure itself automates this task. Data that should be captured for both services and automated processes include the ­following:

• Who invoked each service operation or automated process?
• Were there any attempts to invoke a service or process by unauthorized requesters?
• What was the total time taken to execute the request, and was it within the SLA and QoS targets?
• What were the overall transaction rates for each service, hour by hour?
• In the case of automated processes, additional data needs to be recorded:
• Which of the several possible logical branches were taken in each execution?
• When an automated process invoked a manual task, how long before that task completed?
• Are any manual tasks “hung up”—that is, not completed within the QoS thresholds for that task?

The volume of data this represents will be formidable, and it will need to be summarized in a report or dashboard display.

Purpose: Capture and summarize essential data on performance and utilization of services and automated processes.

Responsible: SOA governance lead, monitoring developer, and PMO define the structure and layout of the report or dashboard display; IT operations provides the raw data.

Accountable: IT operations manager or SOA governance lead.

Consulted: Business service champions, IT operations.

Informed: SOA enablement team, SOA executive sponsor.

SLA Compliance Report Work Product

Description: There are two types of SLA compliance report:

• Regular SLA compliance confirmation. Most, and ideally all, SLA compliance monitoring reposts should show actual QoS numbers achieved that are well within the SLA terms.
• The more important—but rare, we hope—SLA compliance failure reports. In the event of SLA compliance failures, notifications should be sent urgently to the service consumers, the lead SOA architect, business service champions, and the SOA governance lead, apprising them of the situation and the actions taken to prevent recurrence.

Purpose: Monitor SLA compliance and handle incidents.

When needed: Regular SLA compliance reporting should be performed monthly, in support of the SLA monitoring plan described next. In the event of a SLA violation, immediate corrective action should be taken, and all effected service consumers informed as soon as possible.

Responsible: IT operations, monitoring developer, SOA architect, service architects.

Accountable: IT operations manager.

Consulted: Service architect, service designer, QA in the event of SLA violations.

Informed: PMO, SOA enablement team, help desk / technical support staff, service consumers.

SLA Monitoring Plan Work Product

Description: This is the plan to monitor all service and process executions, consumer by consumer, to ensure that they are executed with the terms of the SLAs appropriate to that individual consumer. SLA monitoring needs to be performed using a formal systems management tool or framework; it is not a task that can be performed manually.

Purpose: There is no point in having SLAs if you don’t know whether you are meeting them. There is little value in SOA governance without formal SLAs being in place and enforced.

When needed: At the same time as the SLAs are defined.

Responsible: PMO, lead service architect, lead SOA architect, IT operations, SOA governance lead, monitoring developer.

Accountable: SOA governance lead or PMO.

Consulted: Business service champions, IT operations.

Informed: IT operations, QA, PMO, SOA enablement team.

Technical Support Approach and Targets Work Product

Description: This is a basic IT governance work product that should be updated to reflect the specific needs of service consumers and users of automated business processes. It defines the level and speed of technical support that internal and external service consumers can expect. Enhanced levels of support should be provided for high-severity problems, and for high-value services. Assured levels of technical support should be included in service and automated process SLAs.

Purpose: Ensure that and SLAs honored and that service consumers receive adequate technical support.

When needed: Should be completed before any SLAs are published, and the SLAs should contain clauses that reflect the level of technical support that will be provided.

Responsible: Lead service architect, SOA governance lead, PMO.

Accountable: IT operations manager.

Consulted: Business service champions.

Informed: Help desk / technical support manager, QA, PMO.

The dependencies among work products are shown in Figure 4.4. Again, the format is the same as for Figure 3.3 (in Chapter 3) and Figure 4.3.

Figure 4.4 Service Operation Domain: Work Product Dependencies

Case Study

“To regret one’s own experiences is to arrest one’s own development. To deny one’s own experiences is to put a lie into the lips of one’s life. It is no less than a denial of the soul.”
—Oscar Wilde

Service transformation planning was one of the capability priorities that SOA governance needed so that it could work with the EA group and help govern the resultant business service priorities. Service development lifecycle controls (SDLCs) represent another area of great concern. After all, the adherence to best practices and a consistency of approach across the development organizations are needed, especially to help enforce the results of the service transformation planning.

Service Development Lifecycle Controls

Ideation has known for some time that it needs a common and structured development process. Some groups perform peer reviews from time to time on their code, but the reviews tend to be haphazardly completed.

Another group at Ideation is considering a standardized development approach. Your SOA governance team has been asked to propose governance control gates for the service development lifecycle of

• Business requirements
• Solution architecture
• Service identification and specification
• Service build
• Service test
• Service certification

Control Gates for Ideation

In consultation with the development stakeholders, you decide to create the following control gates for the Ideation SDLC:

• Business Requirements control gate
• Solution Architecture control gate
• Service Design control gate
• Service Build control gate
• Service Test control gate
• Service Certification and Deployment control gate

As a first step, you create the template for the Business Requirements control gate and elicit feedback, as shown in Table 4.3.

Table 4.3  Ideation Business Requirements Control Gate

As a next step, you need to create and get feedback on the control gate for the Solution Architecture control gate, as shown in Table 4.4.

Table 4.4  Ideation Solution Architecture Control Gate

Conclusion

“Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police”
—Albert Einstein

This chapter described a practical work-product approach to governing an efficient service factory—a software engineering-based approach to defining, developing, testing, deploying, and operating functional services and automated business processes.

The work-product approach helps to manage the complexity and interdependencies of the tasks involved, by introducing several intermediate deliverables, documenting the transitions between the various states of service and project lifecycles, and creating a set of control points to act as a governance mechanism to ensure that those deliverables have been constructed to the quality needed. Governance is enabled by formal or informal contracts between work-product creators and work-product consumers; such an arrangement enables early detection and resolution of any quality issues, instead of relying on the imposition of rigid centralized controls.

Our approach is not authoritarian—such an approach simply doesn’t work in managing anything nearly as complex as migration to SOA. Instead, our approach uses work products and short, efficient control point reviews to act as a collaborative set of checks and balances to apply continuous feedback to improve the quality and completeness of the SOA assets that the enterprise deploys.

In Chapter 6, we revisit the service factory to look a little more closely at the how the production line operates, and how governance is applied to individual transitions in the life of each service or automated process.

---

**This chapter is an excerpt from the book, SOA Governance: Achieving and Sustaining Business and IT Agility, authored by William Brown, Robert Laird, Clive Gee and Tilak Mitra, published by IBM Press, Dec. 2008, ISBN 0137147465, Copyright 2009 by International Business Machines Corporation. For more info, please visit the publisher site (www.ibmpressbooks.com).The book is also available via the Safari Books Online digital library and readers can learn about a 15-day free trial offer here: http://www.safaribooksonline.com/informit/customize?cid=200911-informit-blog-custom