building an soa governance product portfolio: how to ... · building an soa governance product...

VI Annual Enterprise Integration Summit L. Frank Kenney

April 10-11, 2007 WTC Hotel São Paulo, Brazil

Building an SOA Governance Product Portfolio: How to Select the Best Products

These materials can be reproduced only with written approval from Gartner.Such approvals must be requested via e-mail: [email protected].


Page 1L. Frank KenneyBRL28L_116, 4/07, AE

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2007 Gartner, Inc. and/or its affiliates. All rights reserved.

Strategic Planning Assumption

Through 2010, lack of working SOA governance arrangements will be the most common reason for SOA failure (0.8 probability).

With the widespread adoption of service-oriented architecture (SOA), the challenges associated with SOA projects are emerging. Through 2010, the biggest barriers to SOA adoption will be nontechnical issues related to inadequate governance, lack of clear value metrics, poorly defined requirements and scope, and insufficient business involvement in project prioritization and service identification. The bigger the SOA is, the more governance it needs, and the more-complex the governance roles and mechanisms must be. Governance arrangements take a long time to design and install, and are difficult to enforce, but without them, every SOA project out of pilot phase is at risk (see "Gartner Research Index on SOA Governance," G00141567).Service reuse is only possible through carefully designed and consistently enforced governance procedures. Consequently, SOA governance offerings have proliferated in the market in two forms:1. SOA governance software that builds on policy management (but beware that the majority of the self-defining SOA governance offerings in the market only address a narrow set of design policies, missing the wider SOA governance picture) 2. SOA governance consulting services that are built on general service identification methodologies, and rotate around some concept of an SOA center of excellence (CoE — an ICC empowered by stronger governance processes) Action Item: Assess and extend your SOA governance starting from IT governance (if in place). Firmly cast governance processes onto enforceable policies. Communicate the importance of mitigating SOA project risks to ensure that you have executive-level buy-in and sponsorship.

Fact: Growing an effective, disciplined SOA by enforcing service reuse and avoiding service duplication is a major issue for technology users and technology providers.




Technology Trigger

Peak ofInflated

ExpectationsTrough of

Disillusionment Slope of Enlightenment Plateau of Productivity

time

visibility

Years to mainstream adoption:less than 2 years 2 to 5 years 5 to 10 years more than 10 years

obsoletebefore plateau

As of July 2006

J2EE

Presentation Integration Servers

Integration Competency Centers

Programmatic Integration ServersBasic Web Services

Integration Service ProvidersMicrosoft .NET Application Platform

Integration Suites

Open-Source J2EEEnterprise-Scope Application Platform SuitesSOA

Advanced Web Services

XML AppliancesB2B Gateway Software

Managed File TransferEnterprise Service Bus

Web Services Management

Packaged IntegrationBusiness Activity Monitoring

Service RegistryIntegration Repositories

Extensible Microkernel-Style PlatformsEvent-Driven Architecture

Distributed Caching PlatformsBusiness Process Networks

Vocabulary-Based Transformation

Grid-Based Application PlatformsEvent-Based

Application Platforms

Service Component Architecture

Alternative Open-Source Application Platforms

Is SOA Doomed or Is It Inevitable?

"Hype Cycle for Application Integration and Platform Middleware, 2006," 13 July 2006

Is SOA Doomed?Certainly, for many companies, an "SOA environment" is very difficult to get to. It's easier for new projects to define new services without integrating (and possibly modifying) pre-existing services, thus replacing application stovepipes with SOA stovepipes. SOA will succeed, in the sense that applications using it will be better than if they'd been implemented using monolithic or distributed object architectures. SOA is clearly more-sensible and manageable than any other form of distributed application architecture (which is why everyone is pursuing it).Is SOA Inevitable?Yes. The majority of new applications are designed on a service-oriented model. Big applications vendors, such as Microsoft, SAP or Oracle, will be shipping their functionality according to a service-based model; some pure-play integration vendors, such as Axway or Informatica, already have partitioned their software offerings in services. All multichannel and composite applications are or will be architected according to an SOA. No IT department, not even in Type-C companies, will be exempted from an SOA. SOAs are already widespread in Type-A and Type-B companies.

Fact: SOA is inevitable.




Strategic Imperative: SOA governance isn't optional — it's imperative. Without it, return on investment (ROI) will be low and every SOA project out of pilot phase will be at risk.

Key Issues

1. What is SOA governance and why is it so important?

2. What SOA project decisions must be disciplined by governance?

3. What's the role of the various ICC components in governing an SOA project?

SOA is becoming increasingly widespread and will form a major part of application portfolios by 2010. As organizations progressively grow their post-pilot SOA projects, they face two major challenges:1. Extending the initial pilot technology infrastructure to support the SOA (often starting with Web services, but extending to guarantee the required levels of performance, scalability, reliability and connection into legacy, non-Web-services-enabled applications, dynamic discovery of services, routing of service invocations, mediation or transformation of service interfaces, load balancing, failover management, security and more).2. Growing their SOAs with discipline by enforcing service reuse and avoiding service duplication. This is only possible through carefully designed and consistently enforced governance procedures.This presentation will focus on the second challenge, providing an overview of the importance of governance in a midsize-to-large SOA project, and the role an integration competency center (ICC) plays in it. The various components of an ICC play a fundamental role in the definition of high-level, highly reusable services, and in the governance processes associated with making a successful SOA project.




SOA Governance Defined

• SOA governance addresses how reusable services are defined, designed, accessed, executed, operated and maintained.

• SOA governance identifies decision-making authority for:- Defining or modifying the business processes that will be

supported with SOA techniques.- Identifying the service levels (including performance) required

and the access rights.• SOA governance is also an important mechanism

for determining service ownership and cost allocation in a shared-service organization.

• SOA governance can't just be about following rules:- It must also measure use and compliance, and specify

incentives to promote the adoption of those rules.

IT governance specifies decision-making authority and accountability to encourage desirable behaviors in the use of IT. Also, IT governance provides a framework in which the decisions made about IT issues are aligned with the enterprise's overall business strategy and culture (see "The Need For IT Governance: Now More Than Ever," AV-21-4823). SOA governance identifies decision-making authority for defining or modifying the business processes that will be supported with SOA techniques, the service levels required, the service performance requirements, the access rights and so on. In addition, SOA governance addresses the way reusable services are defined, designed, accessed, executed and maintained. SOA governance is also an important mechanism for determining service ownership and cost allocation in a shared-service organization.Most important, SOA governance can't just be about following rules; it must also measure use and compliance, and specify incentives to promote the adoption of those rules. "Compliance" is a set of activities to ensure that the policies, procedures and rules are followed. Thus, SOA governance defines the policies, procedures and rules regarding how an organization implements and manages its SOA. Furthermore, compliance steps need to be built into the various processes used to develop/deploy software to demonstrate that SOA governance is "happening." Some design rules can be enforced through the use of policy management tools (such as WebLayers, Infravio [acquired by webMethods] or AmberPoint).Bottom Line: Governance is part of management; SOA governance is part of IT governance; and policy management is part of SOA governance.

Key Issue: What is SOA governance and why is it so important?




What's an SOA Failure?

• Improved responsiveness to business change (agility)

• Improved resource use• Consistent, progressive

and flexible policy implementation

• IT cost savings

You design and implement

reusable services.

You reuse them.

You get the benefits.

An SOA failure is an SOA that doesn't deliver benefits.

Successful SOA projects hinge on a collection of technology and organizational factors, including:• Organizational structure (see "Applied SOA: Conquering IT Complexity Through Software Architecture," G00128127 and "Gartner Research Index on SOA Governance," G00141567)• Managed services (see "CIO Update: Effective Web Services and SOBAs Require Management," G00124466)• Service-oriented development of applications (SODA) requirements (see "SODA, Reuse and Return on Investment: A Model," G00123523 and "Reuse Is the Key to the SODA ROI Model," G00123522)• Underlying software infrastructure (see "Middleware Convergence and Application Platform Suites: Understanding the Business Benefits," G00129353 and "Software Architectures Will Evolve From SOA and Events to Service Virtualization," G00126246)• Evolving service-oriented business applications (see "Client Issues for Service-Oriented Business Applications, 2005," G00127943)Action Item: SOA is a simple equation: You design and implement reusable services, then you must reuse them. Only after that do you get the benefits. The equation doesn't stand if services aren't reused, or if they aren't designed to be reused.

Strategic Imperative: SOA can bring direct business benefits to organizations, but it requires investing in skills, IT organizational processes and structures, and technology — all of which can be expensive and difficult.




SOA Without Governance (aka, Degenerated SOA Projects)

Shelfware SOA- A working SOA is

implemented, but few applications actually use the public services

- Most applications remain as they are

- There's little buy-in from several business units, no agreed-on application architecture companywide, and reuse is a promise that's never kept

- The intentions are good, but SOA is a waste of resources and won't deliver benefits

"Wild West" SOA- The most-common case

of a degenerated SOA- Services proliferate

wildly because no formal service-definition process is in place

- Frequently fueled by widespread enthusiasm about Web services' ease-of-use

- No central registry; nobody knows how many services are in place, where they are or what they do

- Extremely difficult situation to fix and gain control of

Duplicated SOA- Slightly more-disciplined and

more-devious version of a Wild West SOA

- Simply too large — may contain more than 1,000 services

- Although "things work well," many services have been duplicated twice or more

- Rewarding mechanisms for creating reusable services and reusing established services is vague

- Little-reuse multiplies maintenance costs

- Companies are often reasonably happy with this SOA, even though the savings they could achieve would multiply if they reduced the level of duplication

Companies that grow SOAs without governance normally suffer from one or more of the following issues:1. "Wild West" SOAs: This is, by far, the most-common case of a degenerated SOA. Services proliferate wildly because no formal service-definition process is in place. Frequently, this is fueled by widespread enthusiasm about the ease-of-use of Web services technology. Most of the IT infrastructure is exposed as a Web service, but there's no central registry. Nobody knows how many services are in place, where they are or what they do, so there's no leverage and no reuse. It's an extremely difficult situation to fix and gain control of.2. Duplicated SOAs: This is actually a slightly more-disciplined and more-devious version of a "Wild West" SOA. These SOAs are simply too large and contain many services (sometimes more than 1,000). Although "things work well," many services have been duplicated twice or more, and rewarding mechanisms for creating reusable services and reusing established services is vague. Consequently, there's little reuse and maintenance costs multiply, going much higher than needed. The most-disappointing aspect is that companies are often reasonably happy with these SOAs, even though the savings they could achieve would multiply if they reduced the level of duplication.3. Shelfware SOAs: A working SOA is implemented, but few applications actually use the public services. Most applications remain as they are, using point-to-point, unstructured integration mechanisms to connect to other parts of the IT infrastructure. There's little buy-in from several business units, no agreed-on application architecture companywide, and reuse is a promise that's never kept. The intentions are good, but SOA is a waste of resources in this context and won't deliver benefits.Action Item: Ask yourself: "Can I see any of the worrying signs described above? Is my SOA degenerating?"

Tactical Guideline: SOA without governance simply doesn't deliver enough ROI, and in most cases, it kills the SOA project.




What Decisions Must Be Made?

• Which services to do:- Which are the clearest components of

our IT infrastructure that can be reused the most by our applications?

• Which services to do first:- Which services deliver the highest payback?

• Is this really a new, reusable service?- Or should we reuse one or more

services?

• Who's going to pay for the development and maintenance of this service?

• Who owns this service?- Does ownership change throughout

development, operation and maintenance?

These fundamental decisions are also completely different in nature:Which services to do: This is a classic architectural decision. In every IT infrastructure, certain components logically present themselves as intuitive, reusable services (for example, for this <customer name> and this <current account #>, please give me the balance).Which services to do first: A strategic decision that normally depends on where the highest payback is in the value the project has to deliver. It certainly isn't a technical decision, but is possibly architectural.Is this really a new service? Reuse hinges on this decision, related to the never-ending problem of identifying the "right" service granularity. Some of these decisions are quick (for example, when a service already exists and can be promptly reused in the service implementation), but some others are incredibly painful (for example, when you realize that a specific service would be much more reusable if modified, and all the service consumers have to be analyzed to see how they would cope with the change).Who's going to pay for development and maintenance of this service? This is a management decision, not necessarily related to the next decision.Who owns this service? This is an organizational decision, typically related to developers' knowledge and incentives for reuse.

Key Issue: What SOA project decisions must be disciplined by governance?Tactical Guideline: Many decision types (architectural, organizational, technical and strategic) are best taken by different groups of people, all linked to the ICC.




Fact: The ICC already contains the roles and responsibilities necessary to drive a successful SOA.

IntegrationIntegrationProjectProject

Classic ICC Roles and Responsibilities

Enterprise ArchitectureVision and Integration

Architecture*Selection of Technology*

Platform Architecture

Database AdministrationData Modeling Expertise

Modeling ToolsEnterprise Data Knowledge*

Internal MarketingCommunicating

the Vision*Demonstrating

the Value(Success Stories)*

Suggesting Projects*

Operations and System AdministrationMiddleware Installation and Configuration

Server and Network ConfigurationSystem Management*

QAProcess*

Test ScriptsTesting Tools

ICC AdministrationMaintain Integration

Documentation*Best Practices*

Metadata Management*

Business AnalystsBusiness Modeling*Business Domain

Knowledge*

DevelopmentProject Management

Application KnowledgeDevelopment Skills

SecurityCorporate Security

Knowledge*

Product and Application VendorsApplication Data Model*Integration Middleware*

Pilot Project SupportAdapters*

Above, we compare the set of resources needed in a typical integration project (the whole slide) with the ones that are common in a mature ICC (in red and with an asterisk). Having the right IT organizational structure and sensible design practices can ameliorate many of the problems that arise from the diversity of applications and their platforms. Large companies will rarely be able to avoid acquiring a few different enterprise service buses, integration suites and application platform suites, even if they attempt to standardize on just one. However, they can at least reduce the complexity of cross-domain interactions by centrally documenting and managing the integration metadata. Well-run enterprises are implementing centralized or federated ICCs, which typically consist of four to eight full-time employees (but may be 0.5 to 150 people). The development side of each ICC provides expertise to assist the application development (AD) teams in their integration work. It also should maintain common integration standards (for example, canonical message definitions) and metadata in general, such as XML Schema definitions and WSDLs for Web services messages. The operational side of this team installs and maintains the integration infrastructure. Most young ICCs centralize integration work for the organization, using the organization's governance policies as much as possible. As ICCs mature, the amount of integration work needed and the associated time pressure make them grow in size. In strong governance organizations, when the demand for application integration can be satisfied by the organic — that is, internal (and potentially substantial) — growth of ICC resources, a central corporate ICC maintains control of (and delivers) integration work into maturity. In most cases, the evolving, consolidated ICC simply can't cope with the workload and time constraints of the projects it has to deliver. At that point, the ICC tends to get leaner, maintaining key training, governing and mentoring skills, and offloading other skills to other teams in the IT department or outside the company.Action Item: Executives should create a full-time, centralized or federated ICC to design, deploy and maintain the enterprise nervous system, including its middleware technology, SOA service definitions, event-driven architecture message schemas and other integration metadata.




Why Is It a Good Idea to Use an Established ICC for an SOA Project?

• Mainly because the ICC has been doing similar work for structured integration for years.

• Most SOAs are about integration and recomposition of established functionality.

• The ICC already contains all the necessary skills to deal with the complex issues of public services:- Design, reuse, operation

and maintenance

• However …- SOA requires more-formal discipline

and governance than ordinary structured integration work.

The ICC and the enterprise architecture group typically establish the SOA vision and the SOA reference architecture. The ICC is built and empowered while the approach to structured application integration matures (see "The Four Steps to Building an Integration Competency Center," G00123448). About 40% of all midsize-to-large companies worldwide have an ICC, and that number is growing steadily.An SOA project will be easier in companies that already have ICCs because ICCs contain most of the competencies (and works under similar, but looser, governance arrangements) needed to construct an SOA. For example, the ICC carries out projects, such as the single customer view, and sets general guidelines and standards for integration work. These projects have high business value, must assemble different and diverse portions of an IT infrastructure, and the integration interfaces must be reused across different applications.In most ICCs, reuse of integration work is more or less automatic, because decisions on how to perform integration work are made in the ICC, and reuse is part of the "good housekeeping" rules by which all ICCs function. In SOAs, implementation decisions are typically made in separate development groups, and unless strict governance provides the necessary coordination, different groups (or even individual programmers) will make different decisions, multiply diversity and inhibit reuse. Imposing decision rules and localizing them in the ICC seems to be the best option available.

Facts: 1. The ICC already contains the roles and responsibilities necessary to drive a successful SOA. 2. To extend its responsibility into driving SOA growth, an ICC must adopt new, structured procedures for the design, reuse, operation and maintenance of services.




IBM SOA

7

SOA Governance Services & Center of Excellence ServicesApproach- The IBM SOA Governance and Management Practice

combines SOA specialists, process modeling experts and organizational change specialists.

- Armed with IBM’s SOA Governance & Management Method, which spans the services lifecycle, consultants implement an approach to further align business and IT by establishing chains of responsibility, authority and communication to empower people (decision rights). In addition, they establish measurement, policy and control mechanisms to enable people to carry out their roles and responsibilities efficiently. Through the enablement of process automation, increased productivity and reuse is achieved across the business and IT operations environments.

Assets – SOA Governance & COE engagement provides:- Customer tested Governance and Management Method- Detailed governance process guidance - Comprehensive framework and processes span lifecycle of

SOA governance- Methodology to help clients establish SOA Centers of

Excellence

Governance Services

Interaction Services

Information Services

Partner Services

Business App

Services

Access Services

Dev

elop

men

tSe

rvic

es

Man

agem

ent S

ervi

ces

Infrastructure Services

App

s &

In

fo A

sset

s

Process Services

Business Services

Enterprise Service Bus

Leverages IBM SOA Foundation:

WebSphere Registry & RepositoryRational Method Composer

IntegrationIntegrationProjectProject























QAProcess*


QAProcess*


ICC AdministrationMaintain Integration

Documentation*Best Practices*

Metadata Management*


Knowledge*


Knowledge*






Knowledge*


Knowledge*





What's the Difference Between an ICC and an SOA Center of Excellence?

• Simply put, very little:- The skill set is roughly the same.- Both are typically headed by enterprise architects.- Both do a lot of integration work.

• But the SOA CoE is heavily involved in governance work:- Setting up the necessary policies and processes.- Being one of the mechanisms that executes governance

processes.- Suggesting corrective actions when a specific process

has been broken.

Clients shouldn't have two different groups (an ICC and an SOA CoE) because it would be confusing. They would overlap too much and end up in turf wars. There needs to be a single point of coordination, not two. However, it's true that:• An ICC does some things that a pure "SOA CoE" might not do — for example, it should address batch integration and all forms of (non-SOA) data integration using extraction, transformation and loading; replication; federated queries and so on; not just real-time, message-at-a-time integration, as found in SOA.• An SOA CoE does some things that a pure ICC might not do — for example, it could grow its own service community (adding new, custom consumers and service provider components, growing sequentially and incrementally on a coherent, internally defined information model) rather than linking to externally (independently) designed legacy applications or purchased software packages — and in this case, the application integration aspect of the SOA CoE would be rather small.However, these two are extreme cases, and there's a substantial overlap between what the two groups do. Having a single group (whether it's called ICC or SOA CoE) is still the right answer in most cases. Large ICCs often have internal specialists and can be internally subdivided into speciality subgroups. We've already seen such specialization in some ICCs — for example, a business-to-business (B2B) specialty, a legacy/mainframe specialty, a geographically based or business-unit-based subgroup, a business intelligence/data warehouse specialty or a business process management (BPM) specialization. Treating SOA as one of these specialities, with a subgroup for SOA, may make sense, especially where there's a lot of new custom AD (internally consistent, as in the second bullet above).Action Item: Collapse the ICC and the SOA CoE into a single organizational unit.

Facts: Most SOA projects are also integration projects, and most integration projects are also SOA projects; therefore, the difference between an ICC and an SOA center of excellence is minimal, if not nil.




RACI TablesResponsible

- They're typically SOA project leaders, such as:

CIOs, orEnterprise architects, orHeads of integration, orHeads of development

Accountable- In SOA projects,

this is typically an enterprise architect, or a committee that the enterprise architect chairs, and frequently senior app. developers, depending on the granularity of the service.

Informed- Board-level

SOA sponsors are typically involved in this way.

Consulted- In an SOA,

a variety of possible roles is consulted, depending on the nature of the service (e.g., some high-granularity services may need strong security, in which case a security expert is consulted).

Responsible, accountable, consulted and informed (RACI) is a method used to identify the role and authority of the various players in projects. RACI can help determine the sphere of influence/control for the SOA project across all lines of business.• Responsible: Refers to the person(s) responsible for the deliverables produced — the executor(s). They're typically SOA project leaders, such as CIOs or enterprise architects.• Accountable: Characterizes the person who has the ultimate decision-making authority — the overseer. In an SOA, this is typically an enterprise architect, or a committee that the enterprise architect chairs (see Slide 13), and frequently senior application developers, depending on the granularity of the service.• Consulted: Refers to the person(s) who must be consulted before action is taken — the advisors. This is a two-way communication and occurs before an activity is completed. In an SOA, a variety of possible roles are consulted, depending on the nature of the service (some high-granularity services may need strong security, in which case a security expert is consulted).• Informed: Characterizes those who should be informed that a decision or action is being taken, even though they have no control over the action. This is a one-way communication and may occur after an activity has been completed. Board-level SOA sponsors are typically involved in this way.

Strategic Imperative: Disciplining the five key decisions in an SOA is a matter of channeling them to the appropriate roles via appropriate governance mechanisms.




Main RACI Table for SOA Governance

All ICC

Process Owners, Application Developers,

Operations, Security Experts**,

DB Experts**

Enterprise Architects, Application Developers,

Process Owners*

Enterprise Architects, Application Developers,

Process Owners*Who owns this service?

Application Developers,

Service Owners


Operations, Security Experts**,

DB Experts**

SOA Project Sponsor, IT Budget Committee

Enterprise Architects, Process Owners,

Application Developers, IT Budget Committee

Who's going to pay for development & maintenance of this service?

If a new reusable service is agreed,

all ICC. If not, service owners of the services that are reused.

Application Developers, Process Owners*,

Integration Tech Vendors*, Security Experts **,

DB Experts**

Enterprise Architects,

ICC Administrators

Enterprise Architects, ICC Administrators,

Application Developers, Process Owners*

Is this really a new, reusable service?

All ICC, SOA Project Sponsor


Security Experts**, DB Experts**

Enterprise Architects,

ICC Internal Marketing,

Process Owners

Enterprise Architects, Application Developers, ICC Internal Marketing,

Process Owners, SOA Project Sponsor*

Which services to do first?

All ICCProcess Owners,

Application Developers,Security Experts**,

DB Experts**

Enterprise Architects

Enterprise Architects, Application Developers

Which services to do?

InformedConsultedAccountableResponsibleDecision

*For coarse granularity, highly reusable services**Depending on the nature of the service

This slide summarizes best-practice RACI arrangements in an SOA for the five fundamental SOA decisions. Most of the roles and skills involved belong to the ICC (see Slide 7). A few considerations are worth making regarding the RACI tables above:• The roles in black always have influence and control in the relevant table column, as do the ones in red, depending on the conditions listed under the table.• Budget decisions regarding who pays for the development or maintenance of specific coarse granularity, highly reusable services are best taken within the context of an IT budget committee.• A new figure, the service owner, emerges as a fundamental player in maturing SOA projects. Service owners are typically senior developers, although for highly reusable services, enterprise architects should step in as owners (if only temporarily) to resolve conflicts among developers, with a view toward making the service as reusable as possible.Action Item: Carefully analyze who's making the five key SOA decisions in your organization and map the roles into a "current governance arrangements RACI table," similar to the one above. Finding out who calls what may not be straightforward, especially in large companies. Next, compare your RACI table to the one above and locate the differences.

Key Issue: What's the role of the various ICC components in governing an SOA project?




How Are the Decisions Formed? Enacted?

Source: Adapted From Weill and Woodham, 2002; M. Broadbent & P. Weill, "Leading Governance, Business and IT Processes," ITEP Findings, 1998Source: MIT Sloan CISR (Weill and Woodham); Broadbent and Weill

Service-level agreements

Business/IT relationship managers

IT council of business, IT executives

Architecture committee

Process teams with IT members

Executive committee

IT leadership committee

Chargeback arrangements

Measure the value of the SOA: fundamental

Ensures involvement of business owners

Discusses funding; enforces proper business owner involvement

Really drives the SOA project

Are part of the ICC already — before SOA; imperative to include BPM PCEs, if in place

Enforces decision paths; decides on funding

Supports cooperative working practices across several IT departments into the ICC

Shape behavior, assign and recoup costs

Governance Mechanisms Likely Involvement in SOA

This is a list of the most-used IT governance mechanisms and how they can be used within an SOA project:Executive committee: Typically enforces decision paths and decides on funding. In an SOA, it can also serve as a supreme SOA steering committee to decide on issues that the SOA council (see below) can't resolve. IT council of business, IT executives: Discuss funding and enforce the proper business process owners' involvement. When turned into an SOA council, it's the place where key SOA governance decisions (such as 'is this really a new, reusable service') are discussed, and in some cases made, normally by a restricted subset of the participants, as per the table above. When agreement can't be reached, it escalates issues to the SOA steering committee. IT leadership committee: Supports cooperative working practices across several IT departments. In an SOA, it's fundamental to foster developers' buy-in and enforce the new way developers are measured (on reusing services and developing reusable services, not simply on developing services). Enterprise architecture committee: This is the center of the ICC and a major decisional center for the SOA. Business/IT relationship managers: Fundamental in ensuring the involvement of business process owners, and for fostering agreement on the reusable, high-granularity services. Process teams with IT members: They're often part of the ICC already, even before SOA is discussed. Sometimes called the "process CoE" if strong BPM practices are in place. Their work really shapes the SOA, especially when defined from the top down, starting from business processes (very common in some vertical industries, such as insurance). Service-level agreements: They range from technical quality-of-service requirements on service response times, to more high-level reusable service development times to business process owners. Use them extensively. Chargeback arrangements: Generally very useful to shape behavior, assign and recoup costs. They're commonly used in an SOA to split the maintenance costs of reusable services among various application owners, proportional to measured service use.Action Item: There's no one-size-fits-all governance. Understand the different mechanisms that can be used to implement effective IT governance, and see which ones are or must be applicable in your company, to further your SOA project.

Tactical Guideline: Enterprises use multiple mechanisms to help implement their IT governance arrangements. SOA governance arrangements use and extend them where necessary.




Assess Your IT Governance Effectiveness

© 2002 Gartner, Inc. and MIT Sloan Center for Information Systems Research (Weill)

IT GovernanceEffectiveness Indicators

DisagreeStrongly(Score 0)

2. We have clear business objectives for evaluating every type of IT investment.

3. Executives are engaged in IT governance and can describe these arrangements.

1. We have strongly differentiated business strategies.

5. We use well-defined, formal IT exception processes.

4. Our IT governance is stable, with few major changes year-to-year.

6. We use multiple formal communication methods to engage business leaders.

10 2 3

DisagreeSomewhat(Score 1)

AgreeSomewhat(Score 2)

AgreeStrongly(Score 3)

10 2 3

10 2 3

10 2 3

10 2 3

10 2 3

6 or less: No effective IT governance10-13: Maturing IT governance

Total7-9: Low-level IT governance14+: Top performer; guard against complacency

?

The six leading indicators of effective IT governance provide the basis for a mini-self-assessment so you know where you stand. No. 2, No. 3 and No. 6 are particularly significant and fundamental for SOA success. Executive management can also use this assessment to measure current status and spot areas that need improvement. Scoring of the indicators is as follows:

6 or less = No effective IT governance7 to 9 = Low-level IT governance10 to 13 = Maturing IT governance14+ = Top performer; watch for complacency

Action Item: Score your enterprise IT governance indicators. If the score is 6 or less, you must indicate to executive management that any enterprisewide SOA initiative presents a high risk of failure. The SOA executive sponsor, if identified, can help you begin to address the most-important issues.

Tactical Guideline: Before starting with a comprehensive SOA project, assess your company's IT governance effectiveness.




Infrastructure Providers Continue to Mature and Segment

Policy Management

Testing & Validation Focused

Infr

astr

uctu

re F

ocus

ed

Registry Focused

Gartner is seeing the larger vendors, which have been slow to market their SOA framework technologies, finally making an impression in this space and on these markets. The results are acquisitions, partnerships and segmentation. Some vendors are addressing the "lower-hanging fruit": internal SOA and SOA security. Although still extremely important, the bulk of vendors entering this market are attempting to market and sell to companies that are only focused on internal deployments, or "overly" focused on security. We still see the need for technologies that can control B2B-centric service interactions. (Incidentally, B2B gateways are first to offer solutions in this space because of their portal functionality and superior trading partner management functionality.)Action Item: Consider B2B gateway vendors with suitable portlets (WSRP-compliant) or portals as a way to achieve tactical, B2B-centric SOA.

Strategic Planning Assumption: By 2007, 60% of B2B gateways will develop WSRP-compliant portlets that enable integration among their trading partners (0.8 probability).




Services on SOA (Governance)• Two main players have

announced SOA-specific governance offerings:- IBM Global Svcs. and HP Svcs.

• Accenture recently announced massive investments in SOA.

• Some ESPs address SOA governance through business process transformation portfolios:- BearingPoint and CSC

• Some ESPs incorporate SOA governance support into their standard IT governance offerings:- Deloitte and Capgemini

Because (SOA) governance arrangements are difficult to set up and enforce, and change widely from company to company, systems integrators and IT service providers are increasingly offering services in this space. Because these offerings are rapidly maturing, they become increasingly attractive, especially to midsize and geographically distributed companies (which typically struggle to find resources for proper governance enforcement).• IBM Global Services offers a wide range of services centered on SOA governance and its CoE. IBM's SOA governance offering is the most-holistic and most-tightly aligned with process governance.• HP Services offers an SOA governance and architecture service to establish an SOA architecture program office, and to oversee enterprise architecture and the SOA governance model. Currently, this is more SOA-management-oriented than SOA-governance-oriented.• Accenture addresses SOA governance through its SOA Capability Development and Enterprise Architecture/SOA Transformation offerings.• BearingPoint addresses SOA governance in its Enterprise Business Process Management service portfolio, which includes a specific offering for business process governance.• CSC's Application Renewal and Transformation (ART) services address SOA governance.• Some ESPs incorporate SOA governance support into their standard IT governance offerings:

— Deloitte handles SOA governance with its IT Strategy & Management service portfolio.— Capgemini addresses SOA governance with its Integration Competency Center set of services.

Tactical Guideline: Consider SOA governance as a service, especially if you're a midsize or geographically distributed company.




RecommendationsMake the complexity of governance arrangements proportional to company size.Ensure that you have appropriate executive-level buy-in and a dependable executive sponsor:- Communicate the importance of mitigating

project risks due to the lack of SOA governance.Assess your IT governance effectivenessand extend your SOA governance starting from IT governance (if in place):- Unfortunately, your current IT governance often won't

be enough- Understanding who makes decisions in your

company could be far from simple.Identify where you need to go and be realistic:- Focus on a few goals, desirable behaviors, metrics and mechanisms.

There's no one-size-fits-all governance mechanism set:- Different mixtures of mechanisms work best in different companies.

Strategic Planning Assumption: By 2010, fewer than 25% of large companies will have sufficiently mature technical and organizational skills necessary to deliver enterprisewide SOA (0.8 probability).

building an soa governance product portfolio: how to ... · building an soa governance product...

Documents