1. art and entertainment
2. visual art and design
3. architecture

How to Select Technologies for Your SOA
Backplane
Enterprise Integration Summit
April 13-14, 2010
WTC Hotel
Sao Paulo, Brazil
Notes accompany this presentation. Please select Notes Page view.
These materials can be reproduced only with written approval from Gartner.
Such approvals must be requested via e-mail: [email protected].
Gartner is a registered trademark of Gartner,
Gartner Inc.
Inc or its affiliates.
affiliates
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. © 2010 Gartner, Inc. and/or its affiliates. All
rights reserved.
Jess Thompson
How to Select Technologies for Your SOA Backplane
Tactical Guideline: New externally focused applications should be designed to interface with a
plurality of access devices and delivery channels (including Web services).
The "traditional"
traditional Web is increasingly complemented by other means of accessing the Internet
Internet, enabled by such
devices as PDAs, cellular phones, digital set-top boxes, digital TVs, electronic books and game consoles.
Successful business strategies will soundly balance and effectively harmonize a proper combination of
traditional channels — already a mainstream approach in industries such as banking and retail, which have
adopted new e-channels to serve clients effectively and inexpensively. A multichannel strategy is just one part
of a multitier application architecture that enables quick deployment of new, externally focused applications
composed of a mix of new and prebuilt business components. Core business applications will be packaged into
business services, which will be recombined into lower tier business object services that implement the
CRUDs that manage data across multiple applications and middle-tier services implementing domain-specific
business flows. These composite applications will expose business functions accessible across channels and
tailored to each of them through proper adapters. A channel adapter is typically an application that provides
channel-specific services and allows users (or external applications) to access the front-end services as needed,
via devices (or access protocols) held up by that particular channel. A middleware-based SOA backplane will
enable interoperability and integration throughout the layers by also enforcing the logical and physical
decoupling needed to support rapid business process adaptation and reshaping.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 1
How to Select Technologies for Your SOA Backplane
Today, application infrastructure vendors offer many different types of products that support the development,
Today
development
deployment and operation of services in a service-oriented architecture (SOA). As the size and use of an
organization's portfolio grow, the complexity of the resultant system increases, and the number of application
infrastructure products required to establish reliable, scalable applications grows.
This presentation focuses on selecting technologies for a comprehensive SOA application infrastructure. We'll
begin by introducing a reference framework for SOA application infrastructure that identifies features required
to support the application integration, BPA and CEP that can be a part of SOA projects. We
We'll
ll examine the
types of products that provide these features and the types of providers that offer those product types.
Finally, in the third Key Issue we'll describe the steps in a rigorous approach to selecting and implementing the
application infrastructure required for SOA projects.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 2
How to Select Technologies for Your SOA Backplane
Key Issue: What features are required for a comprehensive SOA application infrastructure and
what types of products provide these features?
The application infrastructure required to support a single SOA-style
SOA style application can be really minimal. Often in the
initial stages of SOA adoption, a simple application infrastructure is sufficient. However, as the scope of the SOA
initiative expands as the number of applications, service consumers and service providers grows, requirements for
integration of packaged, pre-SOA and software as a service (SaaS) applications emerge, the complexity and
sophistication of the required application infrastructure also grows. Middleware technologies such as ESB suites, user
experience technologies such as portals, business process management technologies, composition, high- and low-level
community management for B2B integration, master data management, complex event processing, business activity
monitoring business rule engines and others come into play.
g g, deploying
p y g and managing
g g such a complex
p infrastructure are extremelyy hard
The costs and risks associated with designing,
to justify in the context of a single application project. In most cases, such a massive effort pays off only if the relevant
investment is spread across multiple projects implemented over several years. A best practice to minimize costs and
mitigate risks is to assemble the application infrastructure to support an SOA initiative in an incremental fashion. This
means deploying an initial basic foundation (as an example, comprising enterprise application servers, portals and ESB)
that is then extended on a project-by-project basis as requirements for specific new application infrastructure capabilities
emerge. This way it is possible to minimize the initial upfront investment and justify (at least partially) further
investments in the context of a small number of parallel or consecutive projects.
p should plan
p
a phased
p
implementation
p
off your
y
SOA backplane.
p
The
Action Item: CTOs, chieff architects and developers
first components should be in place before reaching the "tipping point" (typically 25 to 30 services and four applications
using those 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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 3
How to Select Technologies for Your SOA Backplane
Decision Framework: The most-significant difference between ESB suites is the breadth of
features packaged with the ESB. Not all organizations will require all features. Ensure that
engineers do a thorough job of establishing requirements and evaluating products.
Integration suites were originally designed to support data consistency,
consistency multistep processes and composite
application integration. They were built on a robust messaging platform and initially used proprietary
messaging protocols to provide efficient and reliable messaging. ESBs were originally designed to support the
deployment of applications built using Web services. Since the inception of ESBs, integration suite vendors
have extended their offerings to provide the five features that define ESBs: synchronous and asynchronous
program-to-program communication; support for fundamental Web service standards; implementation of
service bindings; an architecture that enables users to extend the processing of in-flight messages; and the
pp of typed
yp messages
g that are foundational to multiple
p forms of mediation. The result was a proper
p p
support
superset of ESB functionality termed an ESB Suite. To implement this new set of functionality, vendors are
transitioning to new OSGi-compliant architectures that are "service-oriented inside." OSGi-compliance results
enables organizations to make changes to a deployed product by plugging in new or modified service without
stopping the deployed product. ESB vendors have not been standing still. They've extended bare-bones ESB
functionality with features such as orchestration engines and robust transformation functionality. Note that,
when all ESB suite features are purchased, the price equals (and in the case of some vendors, exceeds) that
charged for integration suites.
Action Item: Select mediation technology based on a comprehensive view of your technical and business
characteristics. The wide set of features in an ESB suite can be overkill in some cases.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 4
How to Select Technologies for Your SOA Backplane
Decision Framework: SOA governance solutions provide the technology to create, discover,
reference and sometimes enforce policy.
Agility, choice
Agility
choice, coordination and trust (ACCT) are the criteria that any service provider and service consumer
should use to judge the usefulness, predictability and reliability of the application in which they are used. SOA
governance solutions provide the technology to create, discover, reference and sometimes enforce policy.
Enforcement is not absolute; however, a policy management solution geared toward performance management
can create and discover (dependent on their relationships with third-party vendors) policies around security or
service-level agreements. The capability to enforce these policies may be absent or severely limited. More
often, however, policy management solutions have the ability to dynamically auto-discover and register new
and unknown assets, add that capability to the map and document actual dependencies. Because this
deployment life cycle intersects the development life cycle, policy management is present at both design and
during operation.
Early adopters of policy management technologies tend to focus on two types of policies: service level and
access control. Service-level policies define, among other things, how services are expected to perform. Access
policies define who or what can access a service or set of services. Although policy management technologies
can create
t these
th
policies
li i from
f
scratch
t h or from
f
predefined
d fi d templates,
t
l t normally
ll they
th are defined
d fi d andd stored
t d in
i
enterprise management tools, enterprise access management tools and directories.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 5
How to Select Technologies for Your SOA Backplane
Tactical Guideline: Metadata for a system of applications with SOA is inherently diverse and
difficult to manage. You will need to work pragmatically and incrementally, because complete,
uniform solutions are unattainable for the near term.
Strategies for managing metadata are to: (1) do nothing — leave your SOA artifacts spread out and
unmanaged; (2) create a comprehensive repository to physically hold a complete set of SOA metadata; or (3)
create a centralized repository with some complementary SOA metadata, but leave that metadata created by
separate software tools in the technologies designed to manage that metadata and federate that metadata with
that managed centrally. Doing nothing is the default solution; you'll be ignoring one of the most important
benefits of asset management — cost reduction. The hidden costs of not providing comprehensive asset
management will include longer development times, unforeseen side effects after a change is made, lower
service quality and higher operational costs. However, doing nothing often occurs, even if a repository is
provided with one of the products in the SOA application infrastructure.
SOA application infrastructure suites typically include a repository. Look for the ability to record and manage
messages and their component attributes, transformation maps, process specifications (for complex interfaces),
intelligent routing logic, policies governing the design, deployment and operation of services and security.
To support your SOA application infrastructure, establish a management strategy that adds metadata
incrementally. Include metadata for business processes and data, as well as SOA governance and integration
artifacts. This may involve federating repository products.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 6
How to Select Technologies for Your SOA Backplane
Decision Framework: BPM pure-play products address the requirements focused process
coordination needs, such as projects that are primarily human workflow-oriented or
document-centric.
Functionality and technologies: Process Execution Engine: Orchestrates the sequence of multiple process interaction
patterns and maintains the state of process instances and activity steps based on the metadata and process flow that was
modeled. Model-Driven Dev: Drag-and-drop modeling, including process wizards, templates and development tools to
model and architect all process artifacts, including process design, human interaction, rule interaction, user interface,
system interaction and electronic forms. Document and Content Mgmt: Technology for storing, archiving, indexing,
picking and tracking all types of structured and unstructured content inside and outside the context of a process flow.
User and Group Collab: Design and runtime human teamwork tools. Design-time tools enable team members to help
close the communication gap between them. Runtime tools enable work teams to drive work to completion faster, as well
as have the ability detect, suggest and change system behavior for more-optimal system performance. System
Connectivity:
i i To enable
bl system architects
hi
to publish
bli h and
d subscribe
b ib to system services,
i
choreograph
h
h service
i interaction
i
i
and set up bidirectional connections to various back-end business application via prepackaged system connectors, such as
EJBs or SOAP. Business Event, BI and Activity Mgmt: Business monitoring and reporting tools for alerting workers
and managers on current and changing business operation behaviors. Inline and Offline Simulation and Optimization:
Tools that use real-time, historical and estimated data values to detect and suggest process optimization opportunities. The
simulation tools should have tight integration to the development environment to enable round-trip engineering. Business
Rule Mgmt: The ability to execute business policies and decisions/rules that are externalized from application code and
make more-flexible process change possible. System Mgmt. and Admin: Tools to set up and maintain system and
human access
access, as well as provide monitoring tools to govern the health of running systems
systems. Process Component
Registry/Repository: Stores all process definitions, components, models, rules and other process data that can be
browsed by humans and called by systems.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 7
How to Select Technologies for Your SOA Backplane
Today, application infrastructure vendors offer many different types of products that support the development,
Today
development
deployment and operation of services in a service-oriented architecture (SOA). As the size and use of an
organization's portfolio grow, the complexity of the resultant system increases, and the number of application
infrastructure products required to establish reliable, scalable applications grows.
This presentation focuses on selecting technologies for a comprehensive SOA application infrastructure. We'll
begin by introducing a reference framework for SOA application infrastructure that identifies features required
to support the application integration, BPA and CEP that can be a part of SOA projects. We
We'll
ll examine the
types of products that provide these features and the types of providers that offer those product types.
Finally, in the third Key Issue we'll describe the steps in a rigorous approach to selecting and implementing the
application infrastructure required for SOA projects.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 8
How to Select Technologies for Your SOA Backplane
Tactical Guideline: By itself, a strategic partnership is poor rationale for purchasing
application infrastructure from a vendor.
The term "megavendor"
megavendor characterizes large vendors that provide products and services whose applicability
extends far beyond application infrastructure. Most megavendors (with the exception of IBM) were late in
providing products, with initial offerings starting about 2000. Early products could be characterized as "testing
the water." The solutions were more limited in scope and often contained immature or unintegrated
components. Moreover, buying the products usually results in vendor lock-in; most megavendor products are
not well-suited to a best-of-breed approach to assembling a comprehensive SOA application infrastructure.
Megavendors' offerings are reaching functional parity with specialists' offerings. Often they have more
g
application
pp
infrastructure pproducts
features,, but the features lie outside an ESB suite. Some megavendor
require that vendors' application server products act as the runtime container. Although specialists seek to
outmaneuver megavendors by providing innovation, megavendors counter by expanding the sale to include a
broad set of assets complementary to integration (such as solutions, services, patterns and templates) that can
add significant value to organizations embarked on deploying SOA.
Action Item: System architects and IT managers should consider a megavendor when their technology
architecture has established a relatively homogeneous environment, and when they intend to acquire and
p y broad solutions for
f SOA and business p
process improvement
p
initiatives (f
(for example,
p , a packaged
p
g
deploy
application or packaged integrating processes) that can only be hosted on infrastructure from that
megavendor.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 9
How to Select Technologies for Your SOA Backplane
Tactical Guideline: Specialists expect you to mix and match application infrastructure;
enabling you to use best-of-breed development tools, portals, applications servers and so
on.
The term "specialist"
specialist is used to characterize vendors that have products and services focused on application
integration. Some specialists such as Tibco, Vitria and webMethods (now Software AG) entered the market in
the early to mid-1990s offering products that provided a graphical approach to specify the business logic
required to transform and intelligently route data among applications. Gradually, the features provided with the
early mediation capabilities expanded to become a suite. Today's ESB suites evolved the same way — adding
features to support BPM and CEP.
Characteristic of early specialists was a broader set of integration services, newer more innovation features
than megavendors, suite components that fit well together (a single, comprehensive architecture) and products
designed for a heterogeneous environment, encompassing disparate application servers. With the exception of
the last characteristic, this differentiation from megavendors has disappeared.
Nonproduct assets, such as solutions (for example, a preconfigured order-to-cash process) and knowledgebased assets (for example, patterns, templates and best practices) are not as extensive as those offered by the
megavendor competitors. However, specialists' functionality remains more mature and often richer.
Action Item: System architects and IT managers should consider specialist integration vendors when the
objective is to eventually establish the broad set of functionality comprised in an SOA backplane (see "Toolkit:
Request for Proposal for ESB Suite Software," G00171999).
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 10
How to Select Technologies for Your SOA Backplane
Tactical Guideline: CIOs, CTOs and chief architects must ensure that OSS technology in
production deployment has the necessary support and maintenance.
The creation of most OSS products is driven by a combination of the notion of a community
community, the existence of standards
and the availability of OSS technology components. This potent combination led to the creation of multiple OSS
infrastructure technologies, such as portals and Java EE applications servers. In the same way, OSS ESBs are being
driven by a collection of standards, including JMS, BPEL, JAX-RPC and JAX-WS.
ESB technology is also available from open-source communities, including Apache, ChainBuilder, MuleSoft, OW2 and
Eclipse (Swordfish). Productized version of OSS technologies are available from vendors that offer it in conjunction with
maintenance and services for that technology. Sample vendors include MuleSoft, Progress (Fuse), Red Hat (JBoss ESB
became available in February
y 2008)) and Sopera.
p
Note that these vendors,, while offering
g supported
pp
OSS ESB technology
gy
as stand-alone products, use it as a leader to broader, more-complex suites.
Combined, there have been approximately 2 million downloads of OSS ESB offerings, but it is impossible to identify
how many of those downloads are in production. The primary reason for this is that while OSS communities track
downloads, there are no license fees, thus it's nearly impossible to track how many of those downloads are in production.
While OSS technology does not result in capital expense, license fees are only one component of the total cost of
ownership. OSS technology is gaining a track record of supporting large, mission-critical systems. However, it requires
devoting highly skilled technical staff to provide support and maintenance when OSS ESBs are used in a production
environment. This significantly adds to the TCO.
Action Item: CIOs, CTOs and system architects considering the use OSS ESB technology must ensure that they have the
staffing required to administer and maintain that technology.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 11
How to Select Technologies for Your SOA Backplane
Today, application infrastructure vendors offer many different types of products that support the development,
Today
development
deployment and operation of services in a service-oriented architecture (SOA). As the size and use of an
organization's portfolio grow, the complexity of the resultant system increases, and the number of application
infrastructure products required to establish reliable, scalable applications grows.
This presentation focuses on selecting technologies for a comprehensive SOA application infrastructure. We'll
begin by introducing a reference framework for SOA application infrastructure that identifies features required
to support the application integration, BPA and CEP that can be a part of SOA projects. We
We'll
ll examine the
types of products that provide these features and the types of providers that offer those product types.
Finally, in the third Key Issue we'll describe the steps in a rigorous approach to selecting and implementing the
application infrastructure required for SOA projects.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 12
How to Select Technologies for Your SOA Backplane
Strategic Imperative: An integration architecture, or IT "city plan," brings consistency to
interapplication exchanges without interfering with intra-application design decisions.
An SOA city plan complements an enterprise architecture,
architecture and it is sometimes considered part of the enterprise
architecture in a broad sense. The core of a city plan is its set of best practices, which should include
developing business process and data models. Additional artifacts to be managed include the exchange
mechanisms and formats (for example, XML documents, messages, printed reports, transaction files, APIs and
screen layouts). All artifacts should be managed in a way that enables sharing and reuse of the interface
artifacts. A city plan should also document the charter of the SOA center of excellence (COE), fully defining
its relationship as a service to the application development groups. Positive relationships to other IT
g
, including
g operational
p
support
pp ggroups,
p , data administration,, database administration,, network
organizations,
support, system administrators and a steering committee (if one exists), are essential to success. The third
aspect of a city plan is the technical architecture of the integration infrastructure. The purpose of these
standards is to control the number of disparate middleware products to maximize interoperability and
minimize support and software license costs.
Action Item: The SOA COE should establish and maintain a city plan that contains a repository, governance
policy and infrastructure standards. The plan should be reviewed and revised periodically as infrastructure,
p
, is deployed
p y and as strategies,
g , such as STP and ZLE,, are pursued.
p
such as an SOA backplane,
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 13
How to Select Technologies for Your SOA Backplane
Tactical Guideline: Architect your SOA backplane carefully. Begin its implementation by
addressing your organization's primary concern. Although most users will initially focus on
the communication and messaging infrastructure (including ESB), in some cases,
management and security (such as WSM) or a service registry must be implemented first.
The purpose of your SOA application infrastructure is to enable seamless
seamless, open interoperability between consumers and
service implementations that possess the quality of service required for production applications. Organizations don't
usually implement all the components of a comprehensive SOA application infrastructure at one time. In the early stages
of SOA adoption, technical and business requirements are not fully understood, and often there's not enough budget to
support the implementation of a fully fledged SOA backplane. The benefits and necessity of some components (service
registry, policy managers and orchestration) might not be as evident when the number of deployed services and
applications consuming them is relatively small. Therefore, most organizations implement their SOA application
infrastructure incrementally, adding components as necessary and as relevant investment can be justified. In most cases,
the first piece of infrastructure laid down is the basic communication and mediation layer (at times,
times this includes an
orchestration capability), often implemented via an ESB and an appropriate set of adapters to integrate custom or
packaged pre-SOA applications. This reflects the fact that most SOA projects aim at the "reuse" of established
applications in the context of new, composite applications or process integration projects. However, in a significant
number of cases, the first pieces of SOA application infrastructure deployed are those relevant to management, security
and policy management (typically by implementing Web services management [WSM] tools or XML appliances). In
these cases, the primary concern is to manage and secure a network of Web services exposed by packaged or legacy
applications, or sourced as SaaS. The service registry is rarely the first deployed SOA backplane element, but, at times,
when this happens,
happens usually it is to help the organization regain control and impose governance on an SOA initiative
grown spontaneously and without centralized control for part of the SOA CoE.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 14
How to Select Technologies for Your SOA Backplane
Tactical Guideline: CIOs and purchasing agents must recognize that selecting the right
product for your organization is contingent on a disciplined, rigorous selection process.
Taking shortcuts (for example, relying on a vendor with which you have a strategic
relationship) significantly increases the potential of deploying a suboptimal product.
To identify products that support more-complicated
more complicated use scenarios
scenarios, consider these qualification criteria:
• Robust messaging infrastructure for request/response, store-and-forward and publish-and-subscribe
interactions.
• Support industry interoperability standards, including SOAP, XML and WSDL.
• Functionality acts as a value-added intermediary for communication between senders and receivers.
Mediation is key for service address indirection, message validation, rule-based routing, transformation
and other features.
• Support for microflow (orchestration).
• Manage metadata that describes, at a minimum, service interfaces and message schemas (message layouts).
Also see "SOA application infrastructure Selection Criteria, 2009," G00170722 and "Evaluating IBM,
Microsoft, Oracle and SAP Application Infrastructure Strategies for SOA Application Projects," G00169655.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 15
How to Select Technologies for Your SOA Backplane
Tactical Guideline: CIOs and purchasing agents must recognize vendors have become adept
at responding to RFPs. Nevertheless the RFP becomes the basis of tracing from your
requirements to the products and features that implement your requirements.
Organizations realize that they can't
can t make simplistic decisions based only on marketing hype and vendor size,
size
but they're often unsure how to proceed with vendor selection. A comprehensive service-oriented architecture
(SOA) platform contains a complex set of features (see "SOA Infrastructure Selection Criteria, 2009,"
G00170722). Selecting the elements of that platform is a challenging task that's complicated by diverse project
requirements, ranging from complex integration through establishing a mediation layer for your SOA
initiatives. Consequently, Gartner strongly advocates that you assemble your SOA platform by purchasing and
deploying components as the need for those components arises.
The features included in SOA application infrastructure products such as an ESB suite can vary dramatically
from vendor to vendor. Additionally, the products are expensive with the cost of initial deployments often
exceeding $500,000. To justify such an investment it is critical that you conduct a formal, rigorous RFP
process. The bidding process associated with an RFP is one of the best methods for leveraging your company's
negotiating ability and purchasing power with suppliers. Moreover it is the means by which you ensure that
products meet all your requirements and that products proposed by vendors address the requirements you've
documented; that is, the vendor isn't attempting to sell you something you don't need. The purpose of the RFP
pprocess is to evaluate a variety
y of companies'
p
ppricing
g and qqualifications. Knowing
g how to write a successful
proposal is invaluable. For comprehensive advice on conducting an RFP see "Toolkit: Request for Proposal for
ESB Suite Software," G00171999.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 16
How to Select Technologies for Your SOA Backplane
Tactical Guideline: CIOs, CTOs and chief architects should ensure that product selection
includes a hands-on evaluation conducted by your IT staff, not the vendor's.
Vendors are very adept at responding to RFPs.
RFPs Additionally,
Additionally today
today'ss products are becoming very similar in
appearance since most provide Eclipse-based tooling. Finally, using the same product suite can result in
significantly different productivity even among organizations with comparable skills in the same vertical. For
this reason, it's essential that you conduct a hands-on evaluation of the products you're considering.
Plan your evaluation so that the products are evaluated by the same staff that will be expected to use those
products. Test the products against a small, manageable project whose completion results in a deliverable that
addresses a business need for your organizations rather than a demonstration solution such as the classic Pet
Store application.
Ensure the necessary training precedes the evaluation. Most vendors offer sales support engineers whose job it
is to make the product look efficient in addressing the needs of your project. While it's acceptable for them to
provide guidance it's critical that your staff conducts the evaluation. Most vendors will charge for such support
if they do not receive the contract. Although it's an added expense it's worth the investment to ensure that all
products are evaluated on a "level playing field."
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 17
How to Select Technologies for Your SOA Backplane
The functionality of products from different vendors is similar,
similar but the way in which users from different
organizations interact with the functionality varies widely. Often, only evaluation via a "proof of concept" will
establish how well the products support the enterprise's needs. A trial during which your IT staff employs the
products under consideration will reveal whether the product meets the evaluation criteria and whether the IT
staff has the skills to implement interfaces using the product suite(s) being evaluated. A proof of concept is also
useful for testing the product's performance, scalability, reliability and ease of use, as well as the vendor's
responsiveness, support capability and its understanding of your business issues.
There are many ways to proceed with a proof of concept.
concept The optimal approach is to run one proof of concept
for each product on the shortlist; this is more expensive, but it gives the broadest information base for
decisions. Regardless of the approach, rate the vendor/product combination — for example, product viability
and momentum — with how products and services meet the evaluation criteria. Although limiting the proof-ofconcept evaluation to a single vendor is less expensive, it only validates a decision that has implicitly been
made. See "Toolkit: Request for Proposal for ESB Suite Software," G00171999.
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 18
How to Select Technologies for Your SOA Backplane
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 19
How to Select Technologies for Your SOA Backplane
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. © 2010 Gartner, Inc. and/or its affiliates. All rights reserved.
Jess Thompson
BRL37L_109, 4/10
Page 20