Improve your SOA project plans

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Yvonne Balzer (yvonne.balzer@de.ibm.com), Senior IT Management Consultant, IBM Global Services ITMC

16 Jul 2004

Service-Oriented Architecture (SOA) has the potential to vastly improve IT's efficiency. But to implement one at an organization, you need more than just technical know-how: you have to be skilled in management as well. In this article, Yvonne Balzer outlines governance principles that can help turn any SOA engagement into a success.

Business and IT value chains today have started to merge together in the industry. We now speak of enterprise architecture and Service-Oriented Architecture (SOA) that are independent from IT implementation. With this change, we also need to adapt the way we structure businesses and IT landscape, define and develop architectures like SOA, and run enterprise-focused client engagements.

For all these reasons, governance plays a more important role in today's IT than it ever has before. In this article, I share IBM IT Management Consulting (ITMC) team's best practice governance approach, which we developed and implemented in several client engagements. Starting from proven IT governance structures and practices, I enhanced our governance model to meet SOA requirements.

Motivation and objections

Because of the challenges and issues of the industry, the role of IT in the modern organization has changed radically. Today, IT must react very quickly and flexibly to enable business almost in real time. IT has to design and manage part of a highly integrated and complex enterprise architecture, with increasingly blurred boundaries between business and IT components. This article proposes key governance functions that will help you achieve these goals and implement successful SOA engagements.

Governance provides an overarching structure in order to support the customers' business objectives on strategic, functional, and operational levels. It defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to achieve customers' business needs and challenging targets. Finally the governance model defines:

• What to do.
• How to do it.
• Who should do it.
• How it should be measured.

The model also defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to meet the customer's business needs and challenging targets.

Here are some key questions for defining an appropriate governance structure within SOA engagements:

• What are the advantages that the client can take from this engagement? What are the client's objectives and expectations?
• What roles, responsibilities, structures, and procedures already exist at the client site for IT planning, steering, and decision-making?
• How can skill and leadership competency be developed?
• What principles and guidelines are necessary to optimize the alignment of business and IT?
• What is the appropriate way to structure how business and IT will interact so as to both maintain consistency and keep flexibility enough to quickly adapt to new changes?
• What standardization of services, service definitions, and descriptions is appropriate?
• How can services and service providers be controlled and measured? Who should monitor, define, and authorize changes to existing services?
• How should you decide on the sourcing strategy of services?
• What problems exist and how can the engagement support the client to solve them?

Based on our experience, we believe that an accepted and formalized governance model is key for successfully achieving business objectives. Therefore, we propose to establish governance functions in SOA engagements. The governance model should also address the fundamental requirement of incremental adaptation, with a focus on using the lessons learned in each step to define and execute the next step. The creation of a governance body for the adaptation and implementation of SOA is a core requirement of the governance model. To achieve fast and high acceptance, we advocate using the client's existing organization and working together to adapt it to the SOA engagement.

Back to top

The governance model: The right shape for SOA engagements

There are different definitions of IT governance. The one from the IT Governance Institute (see Resources for a link) gives a good overview of IT governance in general:

IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes to ensure that the organization's IT sustains and extends its strategies and objectives.

The purpose of IT governance is to direct IT endeavors to ensure that IT's performance meets the business objectives so that:

* IT's alignment with the enterprise results in the promised benefits being realized.
* IT enables the enterprise so that opportunities are exploited and benefits are maximized.
* IT resources are used responsibly.
* IT-related risks are managed appropriately.

Our governance model illustrated in Figure 1 is a combination of organizational structure, joint processes, and relationships based on the strategic direction and accepted ground rules called governance principles. This approach was developed from our experience in large and complex engagements, where we realized that these elements are fundamental for any kind of a project.

Strategic direction and guiding principles

The definition of a client's strategic direction is the key to success for developing an appropriate SOA and sustaining focus on business needs. A common understanding of the business strategy and objectives is fundamental for both business units and IT.

Governance principles and guidelines are the fundamental basis for any decision. They will shape the solution area and define the way that collaboration takes place. Therefore, they should be well understood and agreed to by executive management. One main guideline is the governance approach. You can diffentiate between two main approaches:

• Central governance: Best for the enterprise. The governance council has representation from each service domain (more on this later) and from subject matter experts who can speak to the people who implement key technological components of the solution. The central governance council reviews any additions or deletions to the list of services, along with changes to existing services, before authorizing the implementation of such changes.
  
  
• Distributed governance: Best for distributed teams. Each business unit has control over how it provides the services within its own organization. This requires a functional service domain approach. A central committee can provide guidelines and standards to different teams.

Each principle should be defined with a rationale that explains that principle's purpose and implications. Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles -- for architecture design or service definition, say -- are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behavior for the style of design and should cover the following aspects of the project:

• Guiding principles:
  • Reuse, granularity, modularity, composability, and componentization
  • Compliance to standards (both common and industry-specific)
  • Services identification and categorization, provisioning and delivery, and monitoring and tracking
• Specific architectural principles:
  • Encapsulation
  • Separation of business logic from the underlying technology
  • Single implementation and enterprise-view of components
  • Leveraging existing assets wherever an opportunity exists
  • Life cycle management
  • Efficient use of system resources
  • Service maturity and performance

By understanding the principles of the SOA style of architecture and design, along with the benefits of those principles to the business and IT communities, you can determine the applicability of SOA when designing a solution. These principles drive certain characteristics that are essential to the design of a service. You can trace back each of the characteristics to one or more SOA principles that provide integrity to the principles and the characteristics.

Governance processes

Governance processes are those processes needed for strategic IT planning and steering, such as:

• Strategy development
• IT planning
• Portfolio management
• Sourcing
• Innovation management
• Architecture management.

Within SOA engagements, you should establish the Architecture Management Process (AMP) at the very beginning of the engagement. The primary objective of the AMP is to ensure the consistent and efficient development and vitality of the defined SOA.

Based on our experience at many engagements, we developed a standard AMP that you can use and adopt within client engagements quickly and easily. The process consists of four subprocesses, illustrated in Figure 2, that are well-defined and available as an asset using IBM LOVEM notation. (LOVEM stands for line of visibility engineering methodology; see Resources for more information).

Let's look at some of the elements of the picture in more detail:

• Architecture review and approval process:
  • Defines a structured approach to review and approves changes to the existing SOA; makes decisions in accordance with the SOA roadmap.
  • Formal design and service evaluation reviews are key control points.
• Architecture exceptions and escalation process:
  • Provides means to appeal architectural decisions.
  • Allows exceptions to the SOA architecture to meet unique business needs.
• Architecture maintenance process:
  • Ensures that the SOA is maintained and that changes are communicated to stakeholders as new services are incorporated into the architecture.
  • Variances to the architecture are documented and communicated.
• Architecture communication process:
  • Ensures that the SOA is available to everyone who needs access.
  • Promotes the understanding of the importance of the SOA.

Organizational structure

To provide architectural governance, some structures have to be established within an organization, defining all required roles and responsibilities as well as appropriate decision-making structures. Experiences in the field have shown that it is very useful to establish an architecture office, especially in large and complex engagements. The architecture office is responsible for keeping the SOA aligned with the business requirements on strategic, tactical, and operational levels. It includes an architecture design authority, who is the owner of the architecture management process. Furthermore, roles and responsibilities are defined on each level.

From our work on client sites, we recognized two effective ways to establish and run such an architecture office:

• If the client organization already has an institution with more or less the same functions as an architecture office, then you should interlink with this existing structure. You need to ensure that all functions and responsibilities are on board for making architectural decisions. For the SOA engagement, the board members should be involved with SOA decisions and need to be kept informed on progress.
• If there is no governance council at the client's site, we recommend that you establish an architecture office within the context of the SOA engagement and have it make decisions about key project deliverables. Staff the architecture office temporarily with client and project personnel who are involved in the SOA engagement. Members should be decision makers, and should include the CIO as a sponsor. At the end of the engagement, the architecture office can be integrated into the client organization.

Figure 3 represents the architecture office and the roles and responsibilities it fills on each level. On the strategic level there is the architecture board, which is the decision board responsible for submitting standards and principles and prioritizing services aligned with the business and IT strategy. On the tactical level, the architecture group operates as an architecture design authority responsible for defining the architecture management process, along with decision criteria for changing, removing, or adding services and managing domains. On the operational level, the project team develops and implements the services.

Each team needs a role description defining its tasks and responsibilities and the mode of operation.

SOA governance introduces the notion of domain ownership, where domains are managed sets of reusable services sharing some common business cohesiveness. In many cases these are subsets of business services, such as customer information, case information, merchant dispute statistics, and the like, as well as dispute references like merchant risk rating, product analysis, and planning services. Each domain is responsible for maintaining its own business objects and for publishing interfaces to its services to other domains. The domain offers retrieval and maintenance services for the business object, encapsulating business logic, location, and the format associated with its objects and services. When the people in charge of one product or product area want a service from a domain, they makes a request and the two groups determine the relationship, creating a service-level agreement. These relationships and agreements also exist between domains.

With the concept of domain ownership, there are some more new roles and responsibilities that should be provided for the development life cycle in a SOA engagement, as outlined in Table 1 below.

Table 1. Roles and responsibilities in SOA engagement

The people working within a given service domain are responsible for developing the business and technical integrations to produce business services that are shared across the lines of business to benefit members and regions. This introduces a change in the organizational structure (roles and responsibilities) for application development, as they shift from developing functionality within an application to developing functionality within a service domain.

Back to top

Launching the governance model

The process you can use to develop a governance model is based on a three-phase approach. This approach was developed based on time-constrained client engagements. The key to success is the establishment of the governance functions from day one of the engagement.

• Step 1: Operationalize
  • Set the core governance functions in place and support the client's business operation.
  • Learn by doing; deliver quick wins.
  • Use well-experienced practitioners to act at the top management level.
• Step 2: Professionalize
  • Build up the necessary structures, processes, methods, and tools.
  • Adapt experiences from Step 1.
  • Use experienced architects and method practitioners.
• Step 3: Stabilize
  • Teach and train the client personnel to run the operation.
  • Change from operation mode to coaching mode.
  • Use consultants and specialists with coaching expertise.

Figure 4 outlines these steps in more detail.

Back to top

Hints and tips

Here are some practical lessons we learned from real engagements:

• Communicate regularly to everyone who needs access (through a project newsletter, perhaps, or meetings). SOA creates cultural as well as technological change, which can create barriers; therefore, communication is critical.
• Document each decision, constraint, and assumption to ensure buy-in and transparency in decision-making.
• Define key deliverables and necessary tool sets and templates.
• Set up practical tools for life cycle management and versioning.
• Define decisions with a rationale, then document and communicate those decisions.
• Be sure to keep strong sponsorship from all stakeholders and buy-in from decision-makers.

Back to top

Conclusion

This article showed you why governance is important and what is needed in SOA engagements. It gave you an overview of the key elements of our SOA governance model. It started with SOA principles as guiding directions, followed by the architecture management process as one key process to ensure ongoing consistency and conformity to the Service-Oriented Architecture. It described how to establish the organizational structure with required roles and responsibilities for appropriate decision-making and development. Finally, the article described how to launch the governance model and provided you with some hints and tips from the lessons we already learned in the field.

Resources

• Get more information from the article "Service-Oriented Architecture: Implementation challenges," E. G. Nadhan (MSDN, April 2004), which discusses the two governance approaches.
  
  
• Discover a methodology for the design, definition, visualization, and documentation of processes -- IBM LOVEM, or Line of Visibility Engineering Methodology. For more information, check out the IBM redbook "Business process reengineering and beyond."
  
  
• Read "Ten emerging best practices for building SOAs," Jason Bloomberg (SearchWebServices, February 2003).
  
  
• Learn more about the IT Governance Institute.
  

About the author

		Yvonne Balzer received a Bachelor's degree in the Computer Sciences of Business Administration from the University of Mannheim, Germany. She is a Senior IT Management Consultant in IBM Global Services, where she provides thought leadership for IT governance and IT strategy with focus on architecture management and Service-Oriented Architecture. Yvonne worked for several years as an IT architect and has consulted with both national and international clients in the financial, public, and automotive sector. She is leading the market initiative IT Governance in Europe, the Middle East, and Asia. She is a member of the IBM Technical Expert Council and contributes to IBM Women in Technology. You can contact her at yvonne.balzer@de.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top