Building an SOA Governance Product
Portfolio: How to Select the Best Products
VI Annual Enterprise Integration Summit
L. Frank Kenney
April 10-11, 2007
WTC Hotel
São Paulo, Brazil
These materials can be reproduced only with written approval from Gartner.
Such approvals must be requested via e-mail: vendor.relations@gartner.com.
Building an SOA Governance Product Portfolio: How to Select the Best Products
Fact: Growing an effective, disciplined SOA by enforcing service reuse and avoiding service
duplication is a major issue for technology users and technology providers.
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 morecomplex 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 1
Building an SOA Governance Product Portfolio: How to Select the Best Products
Fact: SOA is inevitable.
Is SOA Doomed or Is It Inevitable?
visibility
Enterprise Service Bus
Managed File Transfer
Packaged Integration
Business Activity Monitoring
Web Services Management
Service Registry
Integration Repositories
B2B Gateway Software
XML Appliances
Extensible Microkernel-Style Platforms
Event-Driven Architecture
Alternative Open-Source
Application Platforms
Business Process Networks
Distributed
Caching
Platforms
J2EE
Integration Competency Centers
Advanced Web Services
Vocabulary-Based
Transformation
Event-Based
Application
Platforms
Presentation
Integration Servers
Programmatic Integration Servers
Basic Web Services
Integration Service Providers
Microsoft .NET Application Platform
Integration Suites
Open-Source J2EE
Enterprise-Scope Application Platform Suites
SOA
Grid-Based Application Platforms
Service Component Architecture
As of July 2006
Technology
Trigger
Peak of
Inflated
Expectations
Trough of
Disillusionment
Slope of Enlightenment
Plateau of
Productivity
time
Years to mainstream adoption:
less than 2 years
2 to 5 years
5 to 10 years
more than 10 years
obsolete
before plateau
"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 moresensible 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 pureplay 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 2
Building an SOA Governance Product Portfolio: How to Select the Best Products
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
important?
so
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 3
Building an SOA Governance Product Portfolio: How to Select the Best Products
Key Issue: What is SOA governance and why is it so important?
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 4
Building an SOA Governance Product Portfolio: How to Select the Best Products
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.
What's an SOA Failure?
You get the benefits.
You design and
implement
reusable services.
You reuse them.
• Improved
responsiveness to
business change (agility)
• Improved resource use
• Consistent, progressive
and flexible policy
implementation
• IT cost savings
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 5
Building an SOA Governance Product Portfolio: How to Select the Best Products
Tactical Guideline: SOA without governance simply doesn't deliver enough ROI, and in most
cases, it kills the SOA project.
SOA Without Governance
(aka, Degenerated SOA Projects)
"Wild West" SOA
Shelfware SOA
Duplicated 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
- 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
- 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?"
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 6
Building an SOA Governance Product Portfolio: How to Select the Best Products
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.
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 7
Building an SOA Governance Product Portfolio: How to Select the Best Products
Fact: The ICC already contains the roles and responsibilities necessary to drive a successful
SOA.
Classic ICC Roles and Responsibilities
ICC Administration
Maintain Integration
Documentation*
Best Practices*
Metadata Management*
Enterprise Architecture
Vision and Integration
Architecture*
Selection of Technology*
Platform Architecture
QA
Process*
Test Scripts
Testing Tools
Business Analysts
Business Modeling*
Business Domain
Knowledge*
Integration
Project
Database Administration
Data Modeling Expertise
Modeling Tools
Enterprise Data Knowledge*
Operations and System Administration
Middleware Installation and Configuration
Server and Network Configuration
System Management*
Internal Marketing
Communicating
the Vision*
Demonstrating
the Value
(Success Stories)*
Suggesting Projects*
Security
Corporate Security
Knowledge*
Development
Project Management
Application Knowledge
Development Skills
Product and Application Vendors
Application Data Model*
Integration Middleware*
Pilot Project Support
Adapters*
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 fulltime 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 8
Building an SOA Governance Product Portfolio: How to Select the Best Products
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.
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-tolarge 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 9
Building an SOA Governance Product Portfolio: How to Select the Best Products
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.
What's the Difference Between an ICC
and an SOA Center of Excellence?
QA
Process*
Test Scripts
Testing Tools
Business Analysts
Business Modeling*
Business Domain
Knowledge*
• Simply put, very little:
ICC Administration
Maintain Integration
Documentation*
Best Practices*
Metadata Management*
Internal Marketing
Communicating
the Vision*
Demonstrating
the Value
(Success Stories)*
Suggesting Projects*
- The skill set is roughly the same.
- Both areIntegration
typically headed by enterprise architects.
Project
- Both do a lot of integration work.
Development
Project Management
Application Knowledge
Development Skills
IBM SOA
• But the SOA CoE is heavily involved in
governance work:
SOA Governance Services & Center of Excellence Services
Approach
ƒ
-
-
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.
Business
Services
Interaction
Services
Process
Services
Information
Services
Enterprise Service Bus
Business
App
Services
Access
Services
Managemen
t Services
Operations and System Administration
Middleware Installation and Configuration
Server and Network Configuration
System Management*
Product and Application Vendors
Application Data Model*
Integration Middleware*
Pilot Project Support
Adapters*
Apps &
Info Assets
Database Administration
Data Modeling Expertise
Modeling Tools
Enterprise Data Knowledge*
Security
Corporate Security
Knowledge*
Development
Services
Enterprise Architecture
Vision and Integration
Architecture*
Selection of Technology*
Platform Architecture
- 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.
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
Partner
Services
Infrastructure
Services
Governance
Services
Leverages IBM SOA
Foundation:
ƒ WebSphere Registry & Repository
ƒ Rational Method Composer
7
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 businessunit-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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 10
Building an SOA Governance Product Portfolio: How to Select the Best Products
Strategic Imperative: Disciplining the five key decisions in an SOA is a matter of channeling
them to the appropriate roles via appropriate governance mechanisms.
RACI Tables
Responsible
Accountable
Consulted
- They're
typically SOA
project leaders,
such as:
- 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.
- 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).
„ CIOs,
or
„ Enterprise
architects, or
„ Heads of
integration,
or
„ Heads of
development
Informed
- Board-level
SOA sponsors
are typically
involved in
this way.
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 twoway 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 11
Building an SOA Governance Product Portfolio: How to Select the Best Products
Key Issue: What's the role of the various ICC components in governing an SOA project?
Main RACI Table for SOA Governance
Accountable
Consulted
Informed
Which services Enterprise Architects,
to do?
Application Developers
Enterprise
Architects
Process Owners,
Application Developers,
Security Experts**,
DB Experts**
All ICC
Enterprise Architects,
Application Developers,
Which services
ICC Internal Marketing,
to do first?
Process Owners,
SOA Project Sponsor*
Enterprise
Architects,
ICC Internal
Marketing,
Process Owners
Process Owners,
Application Developers,
Security Experts**,
DB Experts**
All ICC, SOA
Project Sponsor
Decision
Responsible
If a new reusable
Application Developers,
service is agreed,
Process Owners*,
Is this really a
all ICC. If not,
Integration Tech Vendors*,
new, reusable
service owners
Security Experts **,
service?
of the services
DB Experts**
that are reused.
Who's going to
Process Owners,
Enterprise Architects,
SOA Project
Application
pay for
Application Developers,
Process Owners,
Sponsor,
Developers,
development &
Operations,
Application Developers,
IT Budget
Service Owners
maintenance
Security Experts**,
IT Budget Committee
Committee
of this service?
DB Experts**
Enterprise
Process Owners,
Architects,
Application Developers,
Enterprise Architects,
Who owns
Application
Operations,
All ICC
Application Developers,
this service?
Developers,
Security Experts**,
Process Owners*
Process Owners*
DB Experts**
Enterprise Architects,
ICC Administrators,
Application Developers,
Process Owners*
Enterprise
Architects,
ICC
Administrators
*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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 12
Building an SOA Governance Product Portfolio: How to Select the Best Products
Tactical Guideline: Enterprises use multiple mechanisms to help implement their IT
governance arrangements. SOA governance arrangements use and extend them where
necessary.
How Are the Decisions Formed?
Enacted?
Governance Mechanisms
Likely Involvement in SOA
Executive committee Enforces decision paths; decides on funding
Discusses funding; enforces proper
IT council of business, IT executives business owner involvement
IT leadership committee
Supports cooperative working practices
across several IT departments into the ICC
Architecture committee Really drives the SOA project
Business/IT relationship managers Ensures involvement of business owners
Are part of the ICC already — before SOA;
Process teams with IT members imperative to include BPM PCEs, if in place
Service-level agreements Measure the value of the SOA: fundamental
Chargeback arrangements Shape behavior, assign and recoup costs
Source: Adapted From Weill and Woodham, 2002; M. Broadbent & P. Weill, "Leading Governance, Business and IT Processes," ITEP Findings, 1998
Source: MIT Sloan CISR (Weill and Woodham); Broadbent and Weill
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 13
Building an SOA Governance Product Portfolio: How to Select the Best Products
Tactical Guideline: Before starting with a comprehensive SOA project, assess your company's
IT governance effectiveness.
Assess Your IT Governance Effectiveness
IT Governance
Effectiveness Indicators
Disagree Disagree
Agree
Agree
Strongly Somewhat Somewhat Strongly
(Score 0) (Score 1) (Score 2) (Score 3)
1. We have strongly differentiated
business strategies.
0
1
2
3
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.
4. Our IT governance is stable, with
few major changes year-to-year.
0
1
2
3
0
1
2
3
0
1
2
3
5. We use well-defined, formal IT
exception processes.
0
1
2
3
6. We use multiple formal communication
methods to engage business leaders.
0
1
2
3
6 or less: No effective IT governance
10-13: Maturing IT governance
?
7-9: Low-level IT governance
14+: Top performer; guard against complacency
Total
© 2002 Gartner, Inc. and MIT Sloan Center for Information Systems Research (Weill)
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 governance
7 to 9 = Low-level IT governance
10 to 13 = Maturing IT governance
14+ = 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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 14
Building an SOA Governance Product Portfolio: How to Select the Best Products
Strategic Planning Assumption: By 2007, 60% of B2B gateways will develop WSRP-compliant
portlets that enable integration among their trading partners (0.8 probability).
Infrastructure Providers Continue to
Mature and Segment
Policy Management
Infrastructure Focused
Testing & Validation Focused
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 15
Building an SOA Governance Product Portfolio: How to Select the Best Products
Tactical Guideline: Consider SOA governance as a service, especially if you're a midsize or
geographically distributed company.
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.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 16
Building an SOA Governance Product Portfolio: How to Select the Best Products
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).
Recommendations
9 Make the complexity of governance arrangements proportional to
company size.
9 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.
9 Assess your IT governance effectiveness
and 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.
9 Identify where you need to go and be realistic:
- Focus on a few goals, desirable behaviors, metrics and mechanisms.
9 There's no one-size-fits-all governance mechanism set:
- Different mixtures of mechanisms work best in different companies.
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.
L. Frank Kenney
BRL28L_116, 4/07, AE
Page 17