service connectivity. · service connectivity. page 3 partner connections new services existing...

SOA connectivity

Executive brief

Service connectivity.

Scenarios supporting the connectivity SOA entry point

July 2006

Contents

Achieve new levels of flexibility in linking the software that runs your business

In order to integrate the people, processes and information in your business,

it is necessary to ensure seamless flow of information from anywhere at any

time using anything. Although connectivity has long been a requirement in

business environments, service-oriented architecture (SOA) brings new levels

of flexibility to such linkages. The connectivity provided by an SOA has a

distinct value on its own and as a building block for additional SOA initiatives.

This executive brief describes three examples of how you can improve

connectivity across and beyond your enterprise to improve organizational

flexibility and responsiveness. These approaches can help combat the com-

plexities associated with programming and coding that lead to application

“spaghetti.” And they can help accelerate the implementation of your SOA

and hasten your return on investment. The brief’s final objective is to help you

map out a successful strategy for building an easy-to-define and easy-to-

manage SOA.

Connect the assets and services that support your business processes

Over the years, most companies have built their IT environments using multi-

vendor systems that cannot effectively communicate with one another. The

myriad of heterogeneous systems makes it difficult to connect applications

and processes. Given the complexity of these environments, they are

2 Achieve new levels of flexibility

in linking the software that

runs your business

2 Connect the assets and

services that support your

business processes

4 Connect internal services

5 Repurpose a whole process

through a new business

channel

5 Securely connect to external

service providers using a

gateway

6 Minimize SOA project risk

7 Define an SOA connectivity

approach that works for you


Innovation is all about the ability

to change quickly, easily and

economically. Innovation that

matters is all about differentiating

yourself in your market. Recogniz-

ing market needs and responding

more quickly than your competitors

with innovative business models,

products and services are what

make your business grow. But how

can you achieve innovation that

matters when your business is only

as flexible as the IT environment

that supports it? An SOA helps

you innovate by enabling your IT

systems to adapt quickly, easily

and economically to your changing

business needs.

expensive to manage and difficult to integrate. To overcome these challenges

and improve the flexibility, cost-effectiveness and responsiveness of opera-

tions, connectivity is essential. And to facilitate connectivity, you need to:

• Enable any-to-every linkage and communications between applications,

processes and people inside and beyond your company.

• Access the timely business information required to make rapid and

informed decisions.

• Simplify connectivity by decoupling the interface from the

application/service.

You can choose from a number of SOA-based approaches to begin improv-

ing connectivity across and beyond the enterprise. Depending on your

specific business needs and goals, you can start with one of the following

approaches or combine them:

• Connect internal services

• Repurpose whole processes through new business channels

• Securely connect to external trading partners and service providers


Partnerconnections

New services

Existingapplications

Connectivity

People Process Information

Figure 1. Deliver a security-rich, consistent user

experience by extending processes through new

business channels and devices

Connect business systems based on open standards

SOA connectivity delivers business value on a number of levels. It enables

you to deliver a security-rich, consistent user experience by extending

processes through new business channels and devices, and it enables you

to strengthen trading partner relationships with well-managed connections.

At the same time, decoupling functions and interfaces helps to reduce devel-

opment and maintenance costs, and you can potentially reduce integration

costs by two to four times compared to traditional connections.* In addition,

SOA connectivity can help you minimize business complexity and increase

flexibility and responsiveness by supporting any-to-every connectivity. As a

result, you can access the right information in the right format at the right time.

Connect internal services

A lack of connectivity within companies is one of the most significant impedi-

ments to flexible, responsive operations. And it’s an all too common situation

across many companies. For example, systems and services within a regional

office may have the ability to communicate well with each other, but not to

connect reliably with central office systems. As a result, it’s virtually impos-

sible to access timely information, and collaboration is effectively stymied.

Open-standards-based connectivity simplifies integration between key pro-

cesses, people and information. It facilitates real-time data sharing and team

communication, so your employees can better respond to changing customer

and business needs. This kind of connectivity offers:

• Support for multiple business processes accessing an existing service.

• Packaged adapters to plug directly in to dozens of commercial applications

(like SAP, Siebel and Oracle).

• Built-in, standards-based connectivity to facilitate reuse of what you

already have.


Repurpose a whole process through a new business channel

Your existing business logic is one of the most valuable assets your company

owns. With SOA connectivity, you can more easily expand the use of this

existing logic into new areas of your business to deliver a consistent user

experience across all channels.

For example, you may have an existing business process (such as open-

ing new accounts) that you currently provide to customers through a call

center. What if you wanted to give customers the choice to do business with

you through a self-service Web portal? Or maybe a kiosk, automated teller

machine or handheld device? SOA connectivity enables you to do so without

altering—or even touching—the original back-office systems and applica-

tions used to support your call center process today. The advanced IBM

Enterprise Service Bus (ESB) capabilities make this possible by delivering the

right information in the right format to the right destination.

Securely connect to external service providers using a gateway

To optimize the efficiency of your business and overall responsiveness to

changing customer needs, close collaboration with external partners is

critical. Yet technical inhibitors and security concerns have long prevented

companies from scaling to incorporate service providers and trading partners

into their businesses.

SOA appliances enable a hardened connectivity infrastructure so you can

establish flexible, security-rich and cost-effective connections between your

business and external service providers. You can establish the role that third

parties will play and set policies and performance metrics. The appliances

provide a drop-in hardware device that delivers state-of-the-art security and

performance. You’re able to centrally monitor, manage and report on

exchanges, service-level agreements and policy enforcement.


Deliver an existing process through a new

business channel

Firewall

Securely connect to external third parties and

trading partners

Governance and

best practices

Assemble

Deploy

Manage

Model

Minimize SOA project risk

Whatever your approach to connectivity—linking internal services, repurposing

whole processes through a new business channel or securely connecting to

external service providers using a gateway—SOA projects are best pursued by

following the SOA life cycle. You can think of this life cycle comprehensively and

approach it tactically by focusing on the phases that provide the most value for

you. Underpinning all phases is a governance framework to help you provide

guidance and oversight for your projects and implementations.

The SOA life cycle

The SOA life cycle offers a holistic view of connectivity projects in the context

of an integrated business and information systems strategy. It spans the four

phases shown at left: model, assemble, deploy and manage. Feedback is

cycled iteratively among the phases for ongoing process improvement.

The model phase of the SOA life cycle establishes a common understanding

of the business processes, objectives and performance metrics. You begin

by gathering business requirements and then simulating what-if scenarios to

determine the optimum process for achieving desired business outcomes.

These optimized processes prescribe how the process should work and pro-

vide a baseline from which to measure results. Modeling enables businesses

to visualize entire systems, evaluate different options and communicate

designs more clearly before taking on the technical and financial risks of com-

mitting business and IT resources.

An SOA life-cycle approach is the best way to under-

take any SOA project.


Once the business processes have been optimized, you’re ready to imple-

ment them by assembling newly created and existing services to form

composite applications. The assets are then deployed into a secure and

integrated environment, taking advantage of specialized services that provide

support for integrating people, processes and information. After deployment,

you monitor key performance metrics and performance and use the results to

identify ways to refine the business and information design.

SOA governance enables organizations to maximize the business benefits

of SOA, which include increased process flexibility, improved responsiveness

and reduced IT maintenance costs. It also helps ensure a successful SOA

project by establishing decision rights, guiding the definition of appropriate

services, managing assets and measuring performance.

Define an SOA connectivity approach that works for you

IBM can help you lay out an approach to SOA connectivity that is right for

your business and implement a solution to help you meet your specific goals.

We have the technology, know-how and business process expertise to help

you link the services that support your business processes, whether you want

to connect your internal systems, deliver a process through multiple business

channels or link to external trading partners and service providers.

For more information, talk to your IBM representative about your business

goals or contact IBM directly at [email protected]. Let’s get started today!


© Copyright IBM Corporation 2006

IBM Corporation

Software Group

Route 100

Somers, NY 10589

U.S.A.

Produced in the United States of America

07-06

All Rights Reserved

IBM, the IBM logo and WebSphere are trademarks

of International Business Machines Corporation in

the United States, other countries or both.

Other company, product and service names may

be trademarks or service marks of others.

The information contained in this publication is

provided for informational purposes only. While

efforts were made to verify the completeness

and accuracy of the information contained in this

publication, it is provided AS IS without warranty of

any kind, express or implied. In addition, this infor-

mation is based on IBM’s current product plans

and strategy, which are subject to change by IBM

without notice. IBM shall not be responsible for

any damages arising out of the use of, or otherwise

related to, this publication or any other materials.

Nothing contained in this publication is intended

to, nor shall have the effect of, creating any war-

ranties or representations from IBM or its suppliers

or licensors, or altering the terms and conditions of

the applicable license agreement governing

the use of IBM software.

References in this publication to IBM products

or services do not imply that IBM intends to

make them available in all countries in which

IBM operates.

* “Enterprise Integration Challenge.” Software

Strategies, 2005.

G507-1942-00

SOA services creation and reuse

Executive brief

Service creation.

Scenarios supporting the reuse SOA entry point

July 2006

Contents

Minimize SOA adoption complexity and cost

Services—the building blocks of service-oriented architecture (SOA)—are

self-contained, reusable business tasks. Reusing these services to extend,

enhance or create new processes enables you to substantially increase busi-

ness flexibility and responsiveness through reduced development time and

elimination of duplicate processes. By service-enabling your core IT assets,

you expand access to proven systems and achieve greater value from your

existing technology investments. In fact, a study by Software Productivity

Research found that it can be up to five times less expensive to reuse existing

services and applications than to rewrite them.* Services can also be created

by accessing third-party service providers or by creating new ones. However

your services are developed, they must be stored and managed for easy

access and controlled use.

This executive brief explains in more detail the three key sources of services

for SOA, the benefits of reuse and a proven methodology for service-enabling

existing IT assets and creating value through new services. The objective is

to help you map out a successful strategy for building an easy-to-define and

easy-to-manage SOA.

Start by comparing what you need to what you already have

You’ve finished modeling and simulating your business processes, and you

know how you want your business to run. But how will the individual tasks

that make up the business process be accomplished? Each task needs to

be supported by a service, and an SOA makes it possible to string these

2 Minimize SOA adoption

complexity and cost

2 Start by comparing what you

need to what you already have

3 Reuse proven, high-value

assets

4 Consume externally provided,

commodity services

5 Create new services to fill

portfolio gaps

5 Minimize SOA project risk

7 Define an SOA approach that

works for you

Service creation.

Page 2

Create new services from scratch

Service-enableexisting assets

Consume external services

Innovation is all about the ability

to change quickly, easily and

economically. Innovation that

matters is all about differentiating

yourself in your market. Recogniz-

ing market needs and responding

more quickly than your competitors

with innovative business models,

products and services are what

make your business grow. But how

can you achieve innovation that

matters when your business is only

as flexible as the IT environment

that supports it? An SOA helps

you innovate by enabling your IT

systems to adapt quickly, easily

and economically to your changing

business needs.

services together into flexible, modular systems that enable you to respond

quickly to opportunities and competitive threats. Deciding where these

services will come from is the first step in implementing your vision for an

optimized business process.

There are three main sources for services. You can create them from scratch,

purchase them or service-enable existing packaged or custom software. The

recommended approach is to leverage all three sources by:

• Service-enabling tasks that are supported by in-place, high-value software

applications and systems.

• Using externally provided services to support commodity tasks.

• Creating new services only to fill in the remaining gaps.

Reuse proven, high-value assets

Reusing applications and systems you already have is a sound business

decision—not only because you reduce investment in new technologies.

Existing business logic is one of the most valuable assets any company

owns. It is proven and time tested. As a result, service-enabling current

applications can significantly accelerate and lower the risks of SOA projects.

In addition, maintenance overhead shrinks, because tested code for common

functions has already survived the rigors of production use.

Sophisticated IBM analysis tools can help automate the process of locating

and selecting existing assets for service enablement. Such tools scan

source code where it resides to provide a comprehensive view of your

mainframe-based and distributed application assets and their relationships

and dependencies. You can quickly identify components that could be

reused to support your new flexible business processes.

Service creation.

Page 3

Service-enable existing IT assets

Consume externally delivered services

An individual service can draw upon one packaged or custom application

or multiple systems to deliver its intended function. For example, an address

record in an SAP customer relationship management system can be

combined with functionality from a legacy mainframe-based accounting

system to create a service to support the opening of a new customer account.

The combined service might be invoked as part of a sales order entry busi-

ness process that involves delivery and billing. By combining functionality

that originates in separate systems and exposing this combined functionality

as a single service, you reduce system complexity and eliminate redundancy.

The resulting composite applications enable greater flexibility to adapt as

markets and business strategies change.

Consume externally provided, commodity services

During the process of breaking business processes into tasks for service-

enablement, you will find functions that can be more efficiently delivered by

partners and third-party vendors. For example, consider a company that

enables customers to place orders and select a shipping method online.

The system can utilize the shipper’s remote services to calculate the shipping

cost. This is a commodity-level task that doesn’t make sense for the online

retailer to develop on its own.

By accessing such an external service, users can reallocate resources

toward higher value undertakings that help them grow their business and

stay ahead of their competition. IBM makes it easy to locate available external

services and incorporate them into broader business processes just as easily

as if these services originated from within the company.

Service creation.

Page 4

Create a new service from scratch

Create new services to fill portfolio gaps

There are times when SOA projects require the creation of net-new services

to support tasks. For example, it may not be possible to support a highly

specialized task using existing IT assets or externally available services.

It is also possible that some aspects of an existing application have become

obsolete and don’t make sense to service-enable, because you simply

cannot extract any reusable components. In these cases you will need to

decide whether and how to rewrite these functions as new services.

Using IBM service development tools, you’re able to leverage the knowledge

of your legacy-systems developers. These tools allow business-oriented and

procedural developers who may not have in-depth Java™ skills to develop,

test and debug new services using intuitive, visual design methods. That way

they can focus on designing and creating business logic and services while

relying on the IBM service development tools to automate everything from

the Web services description language file and code generation to test-client

generation and conformance verification.

Minimize SOA project risk

Whatever your approach to creating services—service-enabling existing

assets, consuming externally available services or creating net-new

services—SOA projects are best pursued by following the SOA life cycle.

You can think of this life cycle comprehensively and approach it tactically by

focusing on the phases that provide the most value for you. Underpinning all

phases is a governance framework that provides guidance and oversight.

Service creation.

Page 5

The SOA life cycle

The SOA life cycle offers a holistic view of services development projects

in the context of an integrated business and information systems strategy.

It spans the four phases depicted at left: model, assemble, deploy and

manage. Feedback is cycled iteratively among the phases for ongoing pro-

cess improvement. All of these phases are underscored by SOA governance

to provide the necessary oversight and control to make the project a success

at every life-cycle stage.

The model phase of the SOA life cycle establishes a common understanding

of the business processes, objectives and performance metrics. You begin

by gathering business requirements and then simulating what-if scenarios to

determine the optimum process for achieving desired business outcomes.

These optimized processes provide a baseline from which to measure results.

Modeling enables businesses to visualize entire systems, evaluate different

options and communicate designs more clearly before committing business

and IT resources.

Once the business processes have been optimized, you’re ready to imple-

ment them by assembling newly created and existing services to form

composite applications. The assets are then deployed into a secure and

integrated environment, taking advantage of specialized services that provide

support for integrating people, processes and information. After deployment,

you monitor key performance metrics and performance and use the results to

identify ways to refine the business and information design.

Service creation.

Page 6

An SOA life-cycle approach is the best way to undertake

any SOA project.

Governance and

best practices

Assemble

Deploy

Manage

Model

SOA governance enables organizations to maximize the business benefits

of SOA, which include increased process flexibility, improved responsiveness

and reduced IT maintenance costs. It also helps ensure a successful SOA

project by establishing decision rights, guiding the definition of appropriate

services, managing assets and measuring performance.

Define an SOA approach that works for you

IBM can help you lay out an approach to services-creation and reuse projects

that’s right for you. Initially you might want to understand your business better

and identify which assets you want to use more effectively. You might want

to gain better insight into applications that enable key business processes

across functional areas. Perhaps you want to perform more in-depth analysis

of your business rules in preparation for possible componentization. We have

the experience, understanding and analysis to help you:

• Identify assets for continued investment and reuse.

• Service-enable programs and create services and composite applications.

• Deploy reused, purchased and new services into robust, flexible and scal-

able multiplatform run-time environments.

For more information, talk to your IBM representative about your business

goals or contact IBM directly at [email protected]. Let’s get started today!

Service creation.

Page 7

© Copyright IBM Corporation 2006

IBM Corporation

Software Group

Route 100

Somers, NY 10589

U.S.A.

Produced in the United States of America

07-06

All Rights Reserved

IBM, the IBM logo and WebSphere are trademarks

of International Business Machines Corporation in

the United States, other countries or both.

Java and all Java-based trademarks are trade-

marks of Sun Microsystems, Inc. in the United

States, other countries or both.

Other company, product and service names may

be trademarks or service marks of others.

The information contained in this publication is

provided for informational purposes only. While

efforts were made to verify the completeness

and accuracy of the information contained in this

publication, it is provided AS IS without warranty of

any kind, express or implied. In addition, this infor-

mation is based on IBM’s current product plans

and strategy, which are subject to change by IBM

without notice. IBM shall not be responsible for

any damages arising out of the use of, or otherwise

related to, this publication or any other materials.

Nothing contained in this publication is intended

to, nor shall have the effect of, creating any war-

ranties or representations from IBM or its suppliers

or licensors, or altering the terms and conditions of

the applicable license agreement governing

the use of IBM software.

References in this publication to IBM products

or services do not imply that IBM intends to

make them available in all countries in which

IBM operates.

* “The ROI on COTS: Industry’s Study Reveals

Scale of Savings.” Grid Computing. September 2,

2002: Vol.1, No.12.

G507-1940-00

LINEARPERSPECTIVE A professional article series dedicated to

extending the value of your SAP investments

Extend the value of SAP investments through

integration best practices—a catalyst

for productivity, innovation and efficiency

Leveraging and maximizing existing investments

Since the earliest days of trying to get systems to communicate with each other, the industry

has searched for ways to align heterogeneous and complex IT infrastructures to support agility

and flexibility for the business. Clients don’t want, nor do they have the ability to just throw

away previous investments to start again. They need a way of leveraging and maximizing their

existing investments while having the flexibility to build new solutions.

Service-oriented thinking is gaining popularity in both the business and the IT communities

because it allows interoperability between heterogeneous systems, reuse of components,

and flexible and efficient business processes. Investments in middleware to implement service

oriented architecture (SOA) have become strategic: they have a long-lasting and positive

impact on a company’s ability to operate and compete. And significant resources will go into

these investments over time.

The main difference between SOA and other approaches is that in SOA all assets are

represented as services whether they are components, applications, data sources, processes

or whatever else. At the heart of a service is a well-defined interface that enables reuse of

the assets.

This separates the business view of what the technology does from the actual technical

implementation. As a result, a stronger bond is created between business and information

technology (IT) because:

• Business analysts can identify, analyze, and model the principal business processes

(‘as is’ and ‘to be’) across the enterprise, putting that understanding in context against

the goals and trends of the organization;

• IT can then take action quickly to improve the execution, mapping the assets as

services, and integrating the business processes with the underlying infrastructure.

LINEAR PERSPECTIVE 2

This interaction (parallel or iterative) between business and IT delivers a structure for

continuous business improvement.

IBM WebSphere® solutions enable clients to leverage their existing and newly created

assets to participate in an SOA by abstracting the individual complexities of their applications

and systems into a more meaningful business representation. This means that although the

underlying technologies might change (such as applications, data sources, middleware,

IT vendors and suppliers) the business view of the assets can remain stable. Conversely,

the business view of the assets can change whenever the business deems necessary—

allowing for business flexibility— independent of the technology changes. This alignment but

separation of business and IT needs is driving the rapid adoption of SOA and standards

across the industry.

Extend the potential of your SAP environment

There are many factors to consider when evaluating a business integration solution:

capability, productivity, performance and cost. A solution capable of supporting complete

business processes end-to-end helps define winners more completely than solutions based

around specific applications.

As a user of SAP software, you understand and appreciate the advantages of SAP business

applications for your enterprise resource planning (ERP). And with the rapid growth and

evolution of the business environment, the importance of IT to support business processes

increases constantly.

Integrating business applications is key to a company’s improved productivity and potential

for innovation. But the organic growth of heterogeneous IT environments too often leads to

hidden cost factors. Therefore, infrastructure and process optimization is an important element

in helping lower your costs and increasing your flexibility.

Even in an SAP environment, the whole must be more than the sum of its parts. Only if you

can create an integrated unit from the individual applications and processes will you be able

to work more efficiently, faster and better in the future. The integration of data, applications,

business processes and employees — also while interacting with clients and suppliers — can

help create the competitive advantage that you need.


Hanaro Telecom — connects existing and new services and other assets using WebSphere software

Hanaro Telecom

Location: Seoul, Korea, AP

Industry: Telecommunications

Headquartered in Seoul, Korea, Hanaro Telecom (Hanaro) is a full-service communication provider.

Its offerings include wired telecommunications services, including local and long-distance phone

services; Internet services, including very high bit-rate digital subscriber line (VDSL) and asymmetric

digital subscriber line (ADSL) services; and wireless local area network (WLAN) service.

Business challenges: To gain market share and increase its competitiveness, Hanaro needed to

streamline its business operations and increase its efficiency by implementing an enterprise resource

planning (ERP) solution. But the company’s complex and inflexible back-end IT infrastructure did not

enable easy integration between Hanaro’s internal systems and a new ERP application. To maximize

the effectiveness of a new application environment, Hanaro needed to implement an efficient,

flexible and robust infrastructure that would integrate its existing IT systems with a new front-end

ERP application environment.

Business solution: Hanaro engaged IBM and IBM Business Partner MOCOCO to develop and deploy

an enterprise application infrastructure (EAI) to manage transactions between its new SAP ERP system

and its existing internal applications. The EAI allows the SAP application to integrate with other back-end

systems without requiring a point-to-point interface.

Benefits:

• Increased business flexibility and competitive advantage

• Speed and ease of use

• Solid foundation for building an SOA

• Cost-effective integration of new technologies being added

• Scalability and longevity

The client’s new integrated SAP system provides it with an ERP solution that is more flexible, faster and

easier to use than competing solutions. And because the EAI solution allows it to integrate seamlessly with

the client’s existing back-end applications, the SAP system can access accurate business data in a timely

fashion. The IBM EAI, based on IBM WebSphere software and an IBM System p5™ 550 server, is the client’s

first step in building an overall SOA. In the future, Hanaro will be able to easily, quickly and cost-effectively

integrate new technologies into the EAI. And the flexible and scalable IBM System p5 550 environment

helps ensure that the client will be able to leverage this solution for many years.

Solution synopsis: The IBM WebSphere Message Broker software, which routes messages from

the back-end applications to the SAP environment and conversely, converts code from each system

into a usable format, transforms data formats and uses intelligent routing to ensure efficient and

reliable transmission of data. The IBM WebSphere Adapter software allows the client’s existing client

relationship management (CRM), billing, human resources (HR), rating, groupware, code management,

statistics, online bidding and external gateway applications to integrate with its new SAP environment.

Approximately 2000 Hanaro personnel are directly or indirectly affected by this solution.

Software, services and applications: The EAI includes IBM WebSphere Message Broker, Version 5

software, IBM WebSphere Adapter for mySAP V2.6 software and an IBM System p5 550 server.


Integration — unsolved, complex and a priority for SAP clients

Thinking in terms of business process and application integration

SAP software clients need to address business needs by reducing the cost and complexity of

integration across multiple enterprise applications and disparate systems. However, for many

SAP clients, the integration challenge can be extremely complex. In fact, many SAP users

indicate that the integration of their SAP applications with other enterprise applications is a

critical 2006 priority.

In an effort to achieve greater business efficiency and to become more responsive to change,

today’s business leaders place great importance on being able to make better reuse of

existing assets. By leveraging these assets (in the form of applications and data) in new ways,

and being able to do this faster than previously possible, the organization is better equipped

to quickly respond to changes in market conditions with less new spending, and with reduced

complexity, lowering ongoing maintenance costs.

Get connected

Integrating systems, applications and data across your enterprise

As a user of a strategic business applications such as those provided by SAP software, you

generally have a multitude of systems in your corporation. The integration of these systems

along the supply chain, and across different platforms and applications, is a key factor in your

company’s success. Your company can be more competitive and successful if you are able

to connect and integrate data from various heterogeneous systems. To accomplish this, all

factors—people, information and business processes—have to be integrated, regardless of

whether the associated systems are SAP, from another vendor or developed in-house.

Today’s businesses are acutely aware they need to move from rigid siloed application

approaches to more flexible business process focused solutions. This is driving the need

for transparency in the underlying technologies, and for better levels of standardization

and virtualization of the infrastructure, along with consideration of the value chain including

suppliers and clients.

Best practices in connectivity

Underlying connectivity to support business-centric SOA

One of the key needs of SAP clients is to be able to integrate SAP applications into an SOA to

increase business process and application integration, reuse flexibility and optimization. By

using IBM’s WebSphere software solutions to integrate your SAP ERP and SAP NetWeaver

solutions with other applications in your IT Infrastructure, you can feed data and implement

business processes directly from other systems in right time—without reentering, duplicating

or omitting vital steps in your process.


Many organizations are integrating SAP applications using WebSphere software as it allows

them to integrate heterogeneous systems, applications and data across the enterprise in a

secure, reliable and scalable fashion. Connecting business applications and SAP systems

using WebSphere Message Broker and WebSphere Adapter software can help you maximize

business flexibility, reduce total cost of ownership (TCO) and earn a faster return on investment

(ROI) on existing SAP software assets.

IBM WebSphere Adapter for SAP software, when combined with IBM enterprise service bus

(ESB) offerings, allows SAP applications to be exposed as services and integrated with other

applications, so SAP clients get more value out of their existing application asset base.

A banking and financial services organization achieves a win-win situation using WebSphere Adapter

for mySAP

Industry: Banking and financial services

Summary: A leading banking and financial group connects business applications and a SAP system

using IBM WebSphere Adapters and IBM WebSphere Message Broker software.

Business challenge: Running a varied and complex IT infrastructure that included an ERP system from

SAP and many dependent business applications required the management of multiple standards, varied

resources and different skill sets. The client wanted to implement a technology solution that would simplify

administration of the infrastructure and ease the burden on its IT staff. The organization was looking to

reduce operational costs and improve efficiency; additionally, it had created approximately 180 point-to-

point connections and interfaces using IBM WebSphere Message Broker software. These connections

were difficult to manage and increased the complexity of the infrastructure.

Business solution: To simplify communication between its applications and the SAP system, the banking

group implemented IBM WebSphere Adapter for mySAP software, creating a cost-effective and easy-to-

use connection between the IBM WebSphere Message Broker software and the SAP system.

Benefits:

• Simplified administration of the infrastructure

• Eased the administrative burden on IT staff

• Reduced operational costs

• Improved efficiency

IBM WebSphere Adapters software provided a more cost-effective connection between business

applications and the SAP system by simplifying the complexity of the overall IT infrastructure, and thereby

reducing the number of IT administrators that were required to manage the infrastructure. In fact, in this

instance, the client was able to redeploy some of its staff to other critical IT tasks.

After it had been deployed, the new system efficiently managed calls from all 180 connections, routing

them to the SAP system to ensure real-time application integration. Ultimately, more than 1000 users within

the organization were positively affected by the implementation of this solution.


IBM WebSphere is uniquely able to help SAP clients better address their business needs

by helping reduce the cost and complexity of integration across their multiple enterprise

applications and disparate systems within and beyond their SAP environment. As the leading

worldwide integration platform, IBM WebSphere offers you an excellent extension to integrate

a multitude of applications for your employees.

• IBM WebSphere Message Broker offers powerful mediation between services, enabling

standards-based, nonstandard applications, systems and data sources to be integrated.

It leverages and extends the universal connectivity of WebSphere MQ and complements

IBM WebSphere ESB. These products maximize reuse of existing investments so that

they can be used in multiple business processes.

• WebSphere Message Broker Toolkit, based on the latest release of IBM Rational®

Application Developer and Eclipse, is included in the WebSphere Message Broker

license. The toolkit runs on either Microsoft® Windows® or Linux® on Intel® platforms,

and enables the client to configure the system, develop the message flows and manage

deployed environments.

• IBM WebSphere Adapters help clients complete the last part of the integration of their

technology and business application investments. WebSphere Adapters expose the

structure and processes within applications as services, which extends the reach of the

ESB into the heart of critical business applications and touch points in a client’s SOA.

WebSphere Adapter for SAP software

IBM WebSphere Adapter for SAP: provides bidirectional, multithreaded, real-time integration

between SAP and other applications, using all SAP’s interfaces capabilities.

Any

application

Adapter

Enterprise service bus

Adapter

Adapter

SAP

PeopleSoft


• The prebuilt WebSphere Adapter for SAP software discovers how information is

stored in your SAP application and integrates it into your infrastructure. The adapter

accurately maps and controls the inbound and outbound flows of information between

your SAP application and your infrastructure.

IBM application integration solutions for SAP software offer you a logical step in helping to

achieve the benefits you need today.

Mission accomplished integration

Taking the next logical step in achieving greater business flexibility

IBM WebSphere offers you an SOA platform for EAI, which defines the seamless

connection and integration of business processes and applications in your company.

The combination of IBM’s ESB offerings combined with WebSphere Adapters results

in “mission accomplished” integration.

Staying ahead of the game requires the ability to react to market changes quickly. Increasing

flexibility and keeping costs low are factors that can help to contribute to a faster ROI. By

integrating your existing application environment, reusing existing assets and services, and

improving connectivity, you can protect investments while automating and optimizing critical

business processes.

An industrial products giant stays ahead of the game with a fully integrated ERP system that enables

profits and costs to be viewed in real time

Industry: Industrial products

Summary: An industrial products organization gains the ability to view profits and costs in real time, using

a fully integrated ERP system based on mySAP modules and IBM WebSphere software, reducing manual

data-entry tasks, eliminating several mainframe applications that were nearing end-of-life status and

acquiring a better understanding of costs and profit margins.

Business challenges: This industrial products giant relied on a cumbersome and predominantly manual

accounting system that made it difficult to manage costs and profits efficiently. Powered by various

mainframe accounting applications and aging Oracle databases that pre-dated the time when integrated

solutions were readily available, the ERP system required employees to manually enter important

information into databases—a process that was both time consuming and prone to human error.

Business solution: Recognizing the limitations of this system, the organization embarked on a project to

upgrade the existing ERP system with a robust, integrated solution that provided real-time cost and profit

information online. IBM Business Consulting Services was engaged to design and implement the new, fully

integrated ERP system.


Benefits:

• Reduced manual data-entry tasks

• Eliminated several ageing mainframe applications

• Gained a better understanding of costs and profit margins

• Achieved greater insight into the business’ position in the marketplace

• Improved the visibility and understanding of the business in preparation for market

expansion and growth

Solution synopsis: At the core of the solution was a suite of mySAP modules, providing real-time

access to a wide array of critical profit and cost information. The ERP modules were then integrated

with the organization’s asset-management, production-planning and packaging systems using IBM

WebSphere Message Broker and IBM WebSphere Adapter for mySAP software.

• The WebSphere Message Broker software allowed important transactional data, such as

materials consumption and purchase orders, to be freely exchanged from the Oracle database to

all of the company’s systems, reducing the amount of manual data-entry required.

• The WebSphere products delivered tight integration between the mySAP modules and the

organization’s back-end systems, resulting in a resilient new ERP system that provided real-time

views of critical cost and profit information for every key decision.

• The new WebSphere software-based solution allowed the organization to integrate back-end

systems with robust mySAP ERP modules, giving immediate online access to critical cost and

profit information.

• The WebSphere software solution promoted cohesion and integration among a wide array of

systems, improving information sharing throughout the organization.

Overall, approximately 3500 users were positively affected by this solution.

Implementing integration solutions based on IBM WebSphere software can help organizations

achieve benefits such as:

• Increased agility— flexible connectivity infrastructure allows easy addition and change

of services and reduction in number and complexity of interfaces.

• Increase cost savings—you can reduce your integration costs substantially when using

prebuilt adapters, compared with traditional methods.

• Speed time to market—prepackaged, ready-to-use adapters mean that you are not

bogged down in coding, helping you to get to market more quickly and focus on

achieving business results.

• Lower your business risk— IBM provides expertise in interfacing disparate systems.

Each specialized adapter offers a proven solution to meet your integration needs.


• Exploit extensive functionality and ease of use —a common architecture provides event

detection, full application programming interface (API) support, asynchronous and

synchronous messaging, and transactional support.

• Leverage existing investments in legacy applications— enable wider sharing of business

data and manage complexity through end-to-end enterprise integration, making use of

all applications and systems.

A major chemicals manufacturer quadruples its monthly business-to-business (B2B) transactions by

replacing an existing electronic data interchange (EDI) solution with IBM WebSphere Message Broker

and corresponding SAP Adapter software

IBM WebSphere Adapters enable software to easily communicate with the SAP environment

Industry: Chemicals and petroleum

Summary: An organization’s approach to integration and networking offers a unique competitive

advantage that helps generate continued long-term growth and profitability from its activities.

Business challenges: To continue to keep up with demand, the organization wanted to buy and sell more

frequently over existing connections. But, the incumbent EDI solution used to send and receive payment

orders from suppliers and clients already presented problems that needed to be resolved:

• The particular platform in place was unable to provide the level of service that was required.

• The system lacked any local support and it was difficult to use.

• The environment was unreliable, resulting in frequent data loss for which the organization had

to financially compensate its partners. As a result of these deficiencies, any increase in data

volumes was certain to further tax the system.

Business solution: IBM WebSphere Message Broker and corresponding WebSphere Adapters for mySAP

software were selected as the new interface between the organization’s SAP systems. After replacing the

existing EDI solution, the chemical manufacturer was able to reliably exchange approximately 1.1 GB in

orders, payments and other information each month.

Benefits:

• Faster B2B implementations

• Increased B2B transactions

• Increased partner connections

• Efficiency and speed

• Responsiveness to business changes

• Improved vendor and partner communications

Business benefits:

• Expanded its base of partners from 37, to more than 57 banks, suppliers and clients

• Resulted in an increase in transactions from 4500 to 8300 each month, which represented a jump

in monthly B2B transactions to US$200 million, up from US$50 million.

• An additional benefit discovered— bringing each new EDI partner implementation into full

production took significantly less time than the previous system, requiring on average only

56 hours.


Getting ahead faster together

You, IBM and SAP: A range of technologies to help innovate and improve

Whether you are running R/3 or mySAP applications, IBM can help you address your

connectivity needs today. Connectivity has always been a requirement, but connectivity

in the context of an SOA brings new levels of flexibility. As well as acting as a building

block for additional SOA initiatives, connectivity provided through an SOA has distinct,

stand-alone value—helping align your IT infrastructure with your business goals and

maximizing your organization’s ability to be flexible and responsive to competitive threats

and new opportunities.

Getting more value from your SAP investments using application integration solutions from IBM

Enhance existing SAP R/3 • Gain responsiveness: Real-time ability decreases time to market

environments with a proven • Gain flexibility: Leverage SAP assets in new business

IBM SOA today without the opportunities

pain of migration • Gain openness: Extend your SAP environment to include other

applications.

• Gain reliability: Proven technology reduces your risk

Profit from best-of-breed • Reduce time, cost and complexity of building and maintaining

integration in an SAP application interfaces

environment • Simplify and improve the performance of moving information

between all your applications

• Accelerate your time to value with best-of-breed, prebuilt

SAP adapters

Extend your current IT • Save migration cost and effort

environment, integrating not • Leverage SOA from your SAP R/3 environment

only SAP-to-SAP but also • Consolidate and migrate with a proven solution — easy, efficient,

all other applications low-risk

Reduce application • Productive tools

integration costs in • Application adapters for all leading applications

heterogeneous • Minimal changes to leverage coreexisting applications

environments

Make the most of your • IBM WebSphere is synonymous with innovative middleware

existing investments — technology offering openness, independence, scalability

through openness, and security

independence, scalability • IBM participates in both open standards, demonstrated through

and security the recent release of more than 500 software patents

• IBM is committed to the definition and timely implementation

of open standards such as JMS, SOAP, .NET, Linux,® Eclipse,

SDO and SCA)


To achieve this flexibility, you need to make the most of existing SAP systems and investments

by allowing them to participate in new business processes, integrating them with new systems

and applications. An SOA-based infrastructure can align your business processes with the

strategic business objectives to drive your success.

With more than 1500 unique ways to connect into an SOA (across IBM WebSphere, IBM

Rational®, IBM Lotus®, IBM Tivoli® and IBM DB2® brands), IBM and its Business Partners

provide a strong solution to client integration challenges, offering you the flexibility to

implement the right solution for your needs.

In fact, IBM can connect more of your assets and services and has the product breadth to

support the most connected SOA platforms in the industry, to help you maximize reuse.

Many of these solution options are available through the IBM SOA Business Central initiative,

an ecosystem that showcases IBM and Business Partner solutions.

So where should you start?

In partnership with Mercer Management Consulting, we found that there are three types of

problems customers tend to be dealing with when facing integration challenges: extending

existing systems, accessing data across divisions or partners, and consolidated customer

management. Case studies of IBM’s SOA engagements identified these as SOA entry points.

These were also validated with in-depth interviews with customers. (Mercer QCV Study for

WebSphere, 2005.)

Through business-centric SOA, you can tie IT projects to the business need, directly

addressing your organization’s immediate pain points:

• People: Productivity though people collaboration

Improve people productivity by aggregating views that deliver information and

interaction in the context of a business process. This enables human and process

interaction with consistent levels of service.

Start by building a view of a key business process by aggregating information to help

people make better decisions. Next steps: tighter management of performance with

alert-driven dashboards that link to more processes.


• Process: Business process management for continuous innovation

Deploy innovative business models quickly with reusable and optimized processes,

adapting the enterprise to changing opportunities and threats.

Start by modeling an underperforming process, remove bottlenecks, and then simulate

and deploy the optimized process. Next steps: create flexible linkages between multiple

processes across the enterprise and outside the firewall to suppliers and partners. Then,

monitor the process to measure and track performance.

• Information: Delivering information as a service

Improve business insight and reduce risk with trusted information services delivered

inline and in-context.

Start by discovering and understanding information sources, relationships and the

business context. Next steps: expand the volume and scope of the information delivered

as a service across internal and external processes.

Individually, each approach has the potential to deliver strong ROI. In combination, the potential

for SOA to transform business performance rises sharply. IBM calls this the multiplier effect.

Two IT-centric starting points can help your enterprise integrate business-centric SOA and

to build and reuse SOA services effectively.

• Connectivity: Underlying connectivity to support business-centric SOA

Connectivity has always been a requirement. But SOA brings new levels of flexibility.

As well as acting as a building block for additional SOA initiatives, connectivity

provided through SOA has distinct, stand-alone value.

• Reuse: Creating flexible, service-based business applications

Cut costs, reduce cycle times and expand access to core applications through reuse.

Analysts estimate it is up to five times less expensive to reuse existing applications than

to write new applications.*

Use portfolio management to consider which assets you need to run your company. Identify

high-value existing IT assets and service-enable them for reuse. Satisfy remaining business

needs by creating new services. Finally, create a registry or repository to provide centralized

access to and control of these reusable services.


SAP User Integration Download page

View the growing number of links and resources in the Integration Resource Downloads

Center. A single sign-in gives you access to the SAP User Integration Download page

(registration required). View, read, download and visit more than 25 resources—including

white papers, Web broadcasts, articles, analyst reports, links to useful sites and customer

reference books. New materials will be added to the resource download page as they

become available.

For more information

IBM can help you lay out an approach that’s right for you to help you reach your goals.

To find out more about how IBM WebSphere solutions can help you achieve your SAP

integration, contact your IBM representative.

View the Web event entitled, Extending your ESB with WebSphere Adapters:

Mission Accomplished at www.bulldogsolutions.net/IBMWebSphere/IBW05232006/

index.aspx?bdls=4089

For further exploration, visit the WebSphere Adapters home page, ibm.com/software/

integration/wbiadapters

To find out more about SOA, or to take a self-assessment, visit ibm.com/soa


About the authors

Mark Simmonds, Application Integration Product Marketing, IBM

Mark Simmonds is a worldwide WebSphere product marketing manager covering the

Application Integration and Business Process Management portfolios. Prior to joining

the marketing team, Mark was a systems architect in IBM Global Services, designing and

implementing middleware infrastructure solutions. Mark has been with IBM for ten years.

Neil Postlethwaite, project manager, SAP Initiatives, IBM

Neil is a worldwide marketing and project manager focused in SAP software. With twelve

years’ experience in IBM Software Group, Neil’s focus has been on the middleware portfolio

and he has delivered many business integration products to the marketplace.

Karen Lewis Caldecott, marketing manager, IBM

Karen is a worldwide marketing and programs manager, currently covering SAP software

and IBM application integration interests. Karen has more than twelve years’ experience

within IBM software, services and partner marketing.

© Copyright IBM Corporation 2006. All Rights Reserved. 05-06

IBM, the IBM logo, AIX, AIX 5L, DB2, Lotus, POWER5, Rational, System p5, System z, Tivoli and WebSphere are

trademarks of International Business Machines Corporation in the United States, other countries or both. Intel is a

trademark of Intel Corporation in the United States, other countries or both. Microsoft and Windows are trademarks

of Microsoft Corporation in the United States, other countries or both. Linux is a trademark of Linus Torvalds in the

United States, other countries, or both. Other company, product, or service names may be trademarks or service

marks of others.

* “New IBM Software and Services Help Drive Customer Adoption of SOA” IBM press release, April 3, 2006,

ibm.com/press/us/en/pressrelease/19501.wss

BUSINESS INSIGHTS December 2005

Business Flexibility Removing dependencies between business process

and technical infrastructure with SOA Contacts:

Many of today’s businesses have already moved from rigid siloed application approaches to more flexible business process focused solutions. This is driving the need for transparency in the underlying technologies, and for better levels of standardisation and virtualisation of the infrastructure, along with consideration of the value chain that includes a company’s suppliers and customers.

Clive Longbottom Quocirca Ltd Tel +44 1189 483 360 [email protected]

Elaine Axby MAIN POINTS Quocirca Ltd

The business is increasingly in charge – the technology must be more suppor tiveTel +44 20 8874 7442 Windows of opportunity in the business world have shrunk alarmingly (for example, the lifecycle for many consumer packaged goods is now measured in weeks, rather than months), and large projects lasting many months are increasingly perceived as incapable of supporting the business. Flexibility is required, at a far more granular level than has been required in the past.

[email protected]

Service Or iented Architectures (SOAs) are becoming the norm Organisations are looking to the utilisation of SOA as a means of matching business tasks with technical functionality. However, an SOA has to be built on a flexible foundation that creates a platform independent of hardware and operating systems.

Heterogeneity is here to stay – removing dependencies is key Organisations have invested heavily in existing hardware and software solutions, and it is unlikely that wholesale change in the short term will occur. Virtualisation of the underlying technologies and integration of existing application services points the way towards meeting the needs of tomorrow’s organisations.

Now is the time for change A Service-Oriented Architecture, based upon an open and flexible underlying architecture, utilising an enterprise bus providing solid data transaction, transposition and transport will provide enhanced flexibility for the future. Standards are now in place with broad industry acceptance – SOA is being accepted by companies as the way forwards.

There are issues with application centr ic approaches An application-centric approach to creating a suitable application platform/middleware solution may not provide the end-to-end flexibility required by the business, and may make a company more dependent on the ongoing capabilities of the application vendor in tracking and managing the changes in standards and process flows in the market.

REPORT NOTE: The “Glass Walls” between an organisation and its par tners are disappear ingThis report has been written independently by Quocirca Ltd to address certain issues found in today’s organisations. The report draws on Quocirca’s extensive knowledge of the technology and business arenas, and provides advice on the approach that organisations should take to create a more effective and efficient environment for future growth.

Business processes go beyond the control of the organisation’s control – technology solutions must be capable of supporting and reporting on processes that move along supplier and customer lines.

Tooling, matur ity and independent software vendor suppor t are key for a platform choice A suitable platform must be capable of utilising common tooling so that skilled resources are easily available. It is also key that the platform has adequate support within the independent software vendor (ISV) sector.

CONCLUSION Organisations wanting to create a more flexible, responsive environment to support their business processes must look towards the evolution of an environment that removes the process dependencies from the underlying hardware and software infrastructure. This can only be done through the provision of suitable intermediary technologies such as a Service Oriented Architecture utilising application servers with integrated middleware providing solid support for existing application integration and future business process requirements. A solution capable of supporting complete business processes end to end will define winners more completely than solutions based around specific applications.

An independent report by Quocirca Ltd.

www.quocirca.com

Commissioned by IBM

December 2005 Business Flexibility Page 2

© Quocirca Ltd 2005 http;//www.quocirca.com

ContentsCONTENTS ......................................................................................................................................................................................... 2

1 INTRODUCTION ......................................................................................................................................................................... 3

2 IT CHALLENGES – MANAGING HETEROGENEITY AND DELIVERING FLEXIBILITY............................................... 4

3 THE DEVELOPMENT OF SERVICE ORIENTED ARCHITECTURES............................................................................... 5

4 APPLICATION CENTRICITY VERSUS SERVICES CENTRICITY .................................................................................... 7

5 PURCHASING TECHNOLOGY SOLUTIONS........................................................................................................................ 8

BUSINESSISSUES................................................................................................................................................................................. 8TECHNOLOGY ISSUES. ....................................................................................................................................................................... 10

6 TOTAL VALUE PROPOSITION ............................................................................................................................................. 11

VALUE, RISK AND COST.................................................................................................................................................................... 12GAME THEORY.................................................................................................................................................................................. 12SIMPLE COST OF OWNERSHIP AND RETURN ON INVESTMENT................................................................................................................ 12

7 CONCLUSIONS AND RECOMMENDATIONS .................................................................................................................... 13

APPENDIX A – USE CASE SCENARIOS – FACING UP TO BUSINESS CHALLENGES..................................................... 15

CHANNEL OPTIMIZATION IN RETAIL .................................................................................................................................................. 15PULLING TOGETHER THE CUSTOMER AND VENDOR CHAINS IN FINANCE............................................................................................... 16BUILDING DYNAMIC BUSINESS REPORTS FROM MULTIPLE DATA SOURCES IN THE TELECOMS SECTOR................................................... 17

ABOUT QUOCIRCA ........................................................................................................................................................................ 18



1 Introduction Process is King

IT departments must provide on-demand solutions maximising use of existing investments and utilising open standards to help enable working across the value chain

Service Oriented Architecture is the key way forward – but must be positioned around an open and flexible framework

In today’s business environment, success is driven by the need to support the transactional and knowledge processes1 used within and across the organisation in the quickest and most effective way possible. A recent International Conference of Chief Information Officers and IT Directors in food retailing positioned “Improving Business Processes” at the top of their current agenda, ahead of gaining competitive advantage, cost control and innovation.2 One has only to compare the performance of organisations that use IT effectively with those who do not to see how important IT is to the business: take the contrasting fortunes of UK supermarkets Tesco, which has made widespread use of IT to improve business performance, and the merged Morrison/Safeway chains, where significant IT issues, particularly around the accounting solution, have thrown doubt on the potential success of the merged organisations3.

The role of partners – suppliers and customers - in the business is increasing, and these members of the value chain (see Figure 1) are being heavily incorporated into the business’ core processes. Each company generally has a number of suppliers and customers with whom it has direct contact. However, each of these customers and suppliers has their own supplier/customer ecosystem as well. The need for information to flow easily and securely up and down these value chains is increasingly important – and many members of these chains may be several steps removed from the business itself.

The New Information Supply Chain

Su

pp

liers

Cu

stom

ers

Co

mp

any

SuppliersCustomersCompany

Figure 1

Cross-Corporate Value Chain

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Su

pp

liers

Cu

stom

ers

Co

mp

any

Figure 1: “Butterfly” Value Chains

1 In business terms, the usage of the term ‘process’ here describes end-to-end activities which create distinct value for the company, and generally for the customer.2See:Information Technologies Management Programme from CIES, the Food Business Forum May 2005 3 See Morrison’s statement, May 2005



As well as dealing with more complex value chains, businesses need to move increasingly quickly to take advantage of shrinking windows of opportunity: from finance to heavy industry, product lifecycles are shrinking fast and competitive responses often need to be measured in hours or days, not weeks or months.

IT departments find themselves faced with an increasing demand for on-demand solutions – supporting variability of process and variability in process load, whilst at the same time financial pressures mean that legacy IT investment cannot be thrown out and a complete replacement solution sought.

All this leads to a requirement for evolutionary architectures which will help maximise existing investments in hardware and software as well as enable new applications to be added as the business changes. The IT industry’s most recent solution to this problem is SOA. Quocirca research shows many organisations are considering a more open approach based on SOA going forward. However, it is easy to get SOA wrong, and to hurt the business further. The business must be the priority – and the technologies must support the business processes as they evolve. This paper aims to give senior IT and business managers a strategic view of the technology and business issues to consider when purchasing new technology solutions in an increasingly open environment.

2 IT challenges – managing heterogeneity and delivering flexibility

Heterogeneity is a given – existing investments must be maintained

Businesses are paying too much on IT maintenance – rather than on IT investments

Standardisation is the way to future flexibility

Virtually no-one can start from scratch with their infrastructure. The vast majority of companies have different existing hardware platforms, operating systems, applications, development tools, reporting systems and systems management solutions, either developed within the business over the years, or gained through merger and acquisition activity. The silo mentality of past years, with many applications and hardware environments being managed in isolation to each other, has led not only to the need for multiple human resources replicating jobs being carried out by others, but also to a lack of capability in being able to identify where real root cause problems lie. Indeed, today’s businesses are spending between 70-85% of their IT budgets4 just in maintaining the existing systems – if this can be lowered through better centralised management, greater re-use of services and better root cause analysis, then more money can be allocated to investment in new functionality, rather than in running existing non-optimised systems.

Further heterogeneity is introduced through the increasing automated interactions between organisations and their partners within the value chains – customers and suppliers. An organisation cannot be prescriptive in the systems these partners utilise, and so any standardisation within its own environment will have only a certain degree of effect over the whole value chain. However, the organisation needs to manage the process as far as it possibly can – and this means being able to manage the interactions between its systems and the partner’s systems as far as it can.

The fast pace of organisation activity however requires a fast and cost-effective response from the IT department, and may influence its choice of technology going forward. Technologies need to enable existing investments to continue to be used - they need to be forwards and backwards compatible - not to have to upgrade to the latest software version when new hardware is purchased, for example, or for a complete “fork-lift” upgrade to be carried out when a new standard appears in the market.

Technologies also need the support of accepted industry standards. The support for specific standards may constrain the capabilities for the organisation to be flexile in its dealings in the value chain.

Greater flexibility is also needed within the development environment – as new IT solutions are developed to support new processes, there will be a need to change parts of the solution, without impacting the rest. It will need to be possible to implement new solutions without the need for wholesale regression testing of the overall solution. The IT architecture should allow more “what ifs?” and greater flexibility in building and managing solutions and exceptions.

4 Quocirca Report, Grid Index Cycle III, November 2005



3 The development of Service Oriented Architectures

High-level standards are driving SOA adoption

Existing applications can be enabled as services

Existing hardware assets can continue to be utilized within an SOA

The latest IT industry solution to this problem is SOA (see Figure 2). Here, business applications are broken down into individual components, called services, which are generally loosely coupled through standard interfaces rather than being hardwired together as they would be in the traditional world of single applications integrated through fixed proprietary interfaces. A “calling service” (the user interface) makes calls to other services (which may then call other services themselves, or return data to the interface). A service might be common across a number of different business processes – checking customer credit for example – and in an SOA environment, it would be defined as such and integrated across the process, independent of the applications on which it runs. Therefore, services are based on repeatable business tasks that remove the constraints of a hard coded application. This enables optimisation of services, lessens process redundancy and increases consistency. Service orientation is then the means that these services are interlinked to to provide support for the business processes, and these linkages produce a composite application – an aggregation of individual, independent services that provide the desired solution. Composite applications are therefore far more flexible than hard-coded applications, and new services may replace old services as required with minimum impact on the overall process itself.

Figure 2

Business Process

Responding Services

Calling Service

Service Oriented Architecture

Figure 2: Basic SOA Architecture

SOA has extremely broad vendor support – from the hardware manufacturers, through the platform providers to the application vendors. It has IT buy-in – SOA provides a means of providing a more manageable and optimised environment. It has business appeal – SOAs are designed to provide better responsiveness to market forces and better utilisation of existing assets. SOA should not just be seen as a technical issue – demonstrable value add may be provided directly to the organisation through increased flexibility, information availability and capacity to enable corporate growth.

SOA is happening now – Quocirca’s research shows that a large percentage of companies have basic levels of hardware standardisation in place, and have begun to adopt software standards mature enough for SOA to be considered. Independent Software Vendors (ISVs) are moving towards Web Service based solutions,



providing the building blocks required for an enterprise SOA. The main software vendors such as Oracle and SAP have stated SOA directions, with smaller software vendors racing to provide associated services that will work alongside these enterprise solutions.

SOA “bus” architectures (see Figure 3) also help enable existing applications, new services and new service-capable applications to be easily brought together. Existing applications can be “wrappered” to create either a single callable application service, or can be deconstructed into sets of individual services. Here, the “bus” is a managed environment for controlling the flow of information between services, while logging all transactions and managing any problems where the transmitting or receiving service is not available for any reason.

Figure 3

Enterprise Bus

= Existing Applications = Services

Enterprise BusProvides:• Data Transport• Data Transposition• Service Registry• Transaction monitoring• …..

The Enterprise Bus

Figure 3: Enterprise Bus Architecture

SOA and bus concepts are not new concepts in IT. In the early 1990s, object-oriented coding and reusable code were put forward as possible solutions, but suffered from a lack of available standards and interfaces to create a functional enterprise environment. There have also been a number of ‘middleware’ solutions developed to meet this need for flexibility. During the mid- to late-1990s, EAI (Enterprise Application Integration) was developed as a means of creating a bus across which information could flow from one application to another. Although this approach was more successful than the previous re-usable code, the solutions tended to incur high up-front costs, and some vendors struggled, with many of them being acquired by the companies that have now evolved to offer advanced SOA and application platform solutions.

What is new is the introduction of industry standards for Web Services. As already mentioned, these have broad support from both vendors and standards communities, and enable services to be connected without the need for expensive and time-consuming custom development. Packaged application vendors in areas such as ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) have begun to implement standard interfaces so that their applications can be more easily integrated with others. Vendors such as IBM, Microsoft, Oracle, SAP and others have common frameworks which offer software platforms to integrate existing components as services and to rapidly build and implement new ones.

Within the Web Services world, a “service” can be defined and utilised like any other piece of reusable code. However, through the use of a central repository, known as the Universal Description, Discovery and Integration (UDDI) repository, services can be logged and then called by any request – without the need for hard-coding the linkages – in a form known as “loose coupling”. The Web Services standards, utilising eXtensible Markup Language (XML) metadata, can call for either specific services via the UDDI, or can make a call for any service that will meet its requirements, via a “contract” request. In this manner, an existing service can be easily upgraded without requiring extensive regression testing of dependent



services, or can even be swapped out completely for a new service with better performance or greater functionality.

A prime means of providing this base infrastructure is through the provision of an “application server” platform. An application or service which has been written for a specific application server platform will run on that platform irrespective of the underlying operating system and hardware – without the need for re-coding or re-compiling. This enables companies to grow rapidly as required, with the hardware scaling to meet the application or service needs, or to meet changes in workloads through changing the physical box itself. For example, a company may find that there is a need to move from an initial low-end server system to a system more capable of dealing with high numbers of on-line transactions. Previously, this would have meant not only moving from, say, an Intel-based server to a mainframe, but would have required a complete re-coding of the application serving the need. Now, by utilising a common application server platform, the application itself can be more easily moved from one platform to another.

4 Application Centricity versus Services Centricity

Application-centricity may lead to constraints on flexibility

Services-centricity provides an enterprise platform – and provides value-chain automation capabilities

There are two main approaches to creating a suitable enterprise infrastructure based upon middleware and application server platforms. One is to look at a starting point of the organisation’s main enterprise applications and work out from the vendor’s platform (i.e. “application centricity”), while the other is to start from a base infrastructure focus and look at implementing a “standard” platform for all applications and services within the organisation (i.e. “services centricity”).

Application Centricity

Figure 4

Application Platform

Enterprise

Application

Partner

Application

Existing Application

Partner

Application

Existing Application Existing Application

Application Connectors Application Connectors

Figure 4: Application Centric App Server approach

Both approaches have their benefits and their challenges. By taking an application-centric approach (see Figure 4), organisations can have a high degree of trust in the integration of the basic platform into the application itself, and also that the vendor concerned should have a measure of long term buy-in to the strategy. It would also be normal for the vendor’s dedicated ISV community to build external solutions that adhere to the platform’s standards. However, for parts of the process solution that are more peripheral to the application itself (e.g. common reporting tools across a range of applications, or an information look up service that aggregates information across multiple applications), it is less likely that there will be ISVs that



will have ported and optimised their solutions for an application-centric platform, and the availability of off-the-shelf adaptors and connectors may be low.

A services-centric approach tends to provide a broader scope, building from the existing infrastructure upwards to create an open and flexible structure on which applications and services can be run. If one looks at the retail application described in Appendix A, there is not likely to be a single application available to service the entire requirement. Indeed, several of the applications may not even be hosted by the retailer itself – the repair and installation services may not be sourced internally, but may be hosted by the sub-contracted company that provides the service. Therefore, an application-centric approach to creating the required solution along with ongoing flexibility would be impossible. Through the use of a services-centric approach, an open and inclusive environment can be created that helps enable the process flows to move seamlessly between the applications and services required to reach the desired outcome.

Similarly in finance, the issues revolve around the number of different applications and services which are involved. Taking an application-centric route drives further dependency on a specific vendor’s capabilities in areas that are probably not their core competency. For example, taking the front-office view, the centre of the application world will be the CRM system. If an organisation makes its solution dependent on the CRM vendor’s application server and middleware stack, how will this support the back-office functionality that is required, or the remote working needs of the intermediaries? If taking the back-office view of making transactional systems the central point, how well will the application vendor’s platform support customer-facing systems? The need is for flexibility – and a services-centric view independent of the applications, server hardware and operating systems is designed to create greater flexibility for the future

To achieve the desired level of information analysis and provision described in the third scenario, an organisation must have an environment that is independent of the underlying applications and the databases they are built upon. Application-centric approaches may have more of a dependence on the databases supported by the application vendor. A services-centric approach should provide a more open framework for accessing and manipulating data sources, feeding the information back via a suitable business intelligence (BI) service or tool to the client.

Within this environment, an organisation also has to look at how new applications and services are developed. Here, it is necessary to start from a process focus – the new solution may span several traditional applications and may well break out of the confines of the traditional organisational walls, either to partners or to utilise external services hosted by a third party. Development, testing, implementation, monitoring and management tooling must be capable of working in a dynamic environment. Through this means, the flexibility of the platform is kept at an optimum level, and re-use and industry best practices may be fully utilised.

For many organisations, it may be a hybrid solution that wins through. For an organisation that is highly dependent on a specific enterprise application, it makes sense to utilise the vendor’s specific platform for the core application. However, as soon as the process moves away from the application, it makes far more sense to utilise a services-centric approach, helping to enable greater flexibility across the entire IT infrastructure.

5 Purchasing technology solutions

The business must drive technology decisions – not the other way round

Stability and maturity of platform are key

Security both inside the organisation and across the value chain must be supported

Industry support for the solution must be broad

What then should an organisation look at when purchasing a service-oriented solution going forward?

Business Issues. The key business issues that need to be taken into account are:

The business must retain the business strategy, not be led by the technology strategy: the technology must enable the ongoing changes in the processes that are required to enact the strategy –



so high levels of flexibility will be required. The key to flexibility lies in the adoption of standards across the whole platform stack

The technology must be built on a suitably mature foundation: the use of middleware and application platform technologies is so strategic that the use of unproven solutions should not be countenanced. Key areas to look at here are the messaging and workflow capabilities of the chosen solution – both must be open enough to interoperate with other systems embedded within applications, yet must have the capability to retain the state of the work packet – that is, be able to “hold” information in place - should an application or service not be available for any reason, being able to then re-start the flow from a known position automatically once the application is back on line.

The platform itself must be stable: with today’s business processes being so complex and spanning multiple applications, multiple sites and multiple companies, it is an imperative that the system not be the weak link in the chain. Here, it is important to look at how resilience can be built into the solution: failover, load-balancing and n+1 redundancy are all areas that should be investigated to make sure that you are not dependent on any weak link for the capabilities of your solution.

The solution must support existing investments: irrespective of the hardware and operating systems already in place, whether looking at mainframe systems, high-end, mid-range or low-end systems, or indeed blade farms and virtualised environments.

Connectivity to existing applications must be allowed: the key here is that connectivity has to be across the whole of the business process – not just being able to integrate one enterprise application into other applications that it touches. The latter approach constrains the capability of the organisation internally as well as externally. As the world moves towards more of a service-based view, the need to see existing applications as sets of functions supporting the organisation is expected to become more pervasive, and the need for these services to be able to interoperate through loose bindings, across application and physical boundaries, will drive the need for systems that are completely free of specific applications, and that can reach and manage processes beyond the constraints of the organisation.

The solution must ensure information fidelity: if the information cannot be trusted, then the process itself is suspect, and the organisation may suffer accordingly. Therefore, any chosen solution must ensure information integrity through its support for standards such as the eXtensible Markup Language (XML) and other metadata capabilities, as well as having the capacity to raise exceptions where the fidelity of received information may be suspect.

The solution must be able to present information usefully: as business processes within an organisation go across multiple applications, they go across multiple data stores, some of which may be formalised data (such as held within a standards database), while others may be more ad hoc (such as documents or e-mails). The chosen solution should be able to aggregate the information required across all of these possible solutions and present this back to the reader according to their needs - a sales director will require the information to be presented differently to a sales executive, for example. This can best be done through the utilisation of a full-function, integrated portal solution making the most of the underlying openness and capabilities of the middleware and application server platform.

The solution should enable communication and collaboration: a greater part of the decision making function within an organisation is now based around the capabilities of the people involved to be able to communicate and collaborate around the information feeds involved. The chosen solution should enable this communication and collaboration, through standardised connections to existing tools such as e-mail, instant messaging, white boarding and web conferencing.

The solution must be able to support business continuity requirements: should an unforeseeable event occur that does bring down a major part of a system, it will be necessary for the chosen solution to help you through the crisis. For this, it will be necessary for the solution to be able to failover into a known state – it should be capable of logging the status of any ongoing processes and transactions, and rolling back unrecoverable transactions to a last known good position, so that once the problem has been resolved, it can resume where it left off with the minimum loss of transactions.

The solution must be able to support regulatory requirements: in today’s increasingly regulated world, the capability to monitor a process’ progress along the value chain is needed, both for internal governance and external audit. The capabilities of the chosen solution to facilitate this must be taken into account – it must be able to track the process end-to-end, with firm integration into an organisation’s



policies and roles and responsibilities for its own employees and the individuals and services that are included within the value chain.

The solution must be secure: as part of the creation of a supportive business infrastructure organisations need to ensure that there is a fully secure environment in place, supported through a framework driven by corporate policies and procedures. This again drives the need for a fully open environment with centralised tools for modelling, creating and managing the requisite policies.

Technology Issues. When looking at the main technology issues, standards are as much of an issue as they are from the business angle.

The solution must support a base level of standards: the problem is in choosing which standards to back now – while ensuring that the door is not closed on any emerging future standards. Here, the main direction that Quocirca has identified is towards the utilisation of SOAs. SOAs are based upon the use of Web Services, which are defined through the various Web Services (WS-*) standards. Quocirca believes that any chosen solution must have a base level of Web Service support built around either J2EE and/or Microsoft’s .NET frameworks.

A UDDI or other service registry capability must be in place: although the true adoption of SOA-based infrastructures is still some way off, it is important to ensure that there is a UDDI or other service registry capability in place. This is necessary to manage the growth and usage of services as time goes on – hard linkages between services may lead to under-performing solutions, and lack of the capability to easily re-use services across multiple processes.

The solution must have a public roadmap for the future: the slow emergence of grid computing is dependent on a suitable SOA being in place – and organisations looking towards the use of grid to help optimise technology asset usage and gain commercial advantage must ensure that the solution chosen will enable the creation of the required SOA, the capability to virtualise the environment and the flexibility to move to a gridded environment in the future. In a heterogeneous hardware environment, the solution must be capable of supporting all those platforms that will be involved with the corporate processes. Although some solutions are capable of being run against multiple hardware types, some do not have such capability. Therefore, it is necessary to ensure that the chosen solution has a public road-map for the future showing how the various implementations will be kept in step, and how they will interoperate with each other at the highest levels of functional and informational fidelity.

The solution must be in the leading group of standards adopters: being a constant leader in the standards field can have disadvantages (instability, incomplete standard support and the need to continually patch solutions, for example). However, being a standards follower, forever one or more iterations behind the mainstream, often does not create an environment capable of supporting the organisation. What an organisation needs is to be one of those who are towards the leading group – the organisation may be able to be more responsive to the market, more flexible in its approach and more capable of changing its business processes to gain any advantage in the value chain.

The solution must enable easy performance management and optimisation: when modelling a process, it is often the case that the new process instance in its un-optimised state suffers from various performance bottlenecks. It is imperative that the solution chosen enables these bottlenecks to be identified rapidly and easily, and that these can then be dealt with through the use of suitable tooling and management systems. Avoiding performance bottlenecks requires technical capabilities not currently present in all solutions on the market. Here, Quocirca recommends that buyers look for solutions that support dynamic workload management (the capability to maximise utilisation of available resources through the sharing of these resources across various processes through the use of dynamic provisioning of the resources to support the different needs of different processes), information caching (the capability to localise static information availability and to minimise the need to pull dynamic information over lower-speed wide area linkages) and process reporting tools (enabling issues to be identified before they become problems, thus allowing decisions to be made as to actions which may help prevent the problem from occurring).

The chosen solution should be componentised within itself: it is increasingly difficult within today’s organisations to shut down any part of a system for it to be replaced or upgraded. Should an upgrade of the very underpinnings of the infrastructure be required, a non-componentised system may require that



the whole environment be shut down during the upgrade – which may compromise the capability of the company to carry on business. However, a componentised solution is designed to enable parts of the environment to be upgraded rapidly – and often in parallel with the existing system, helping to ensure that any downtime is minimised. Componentisation also enables companies to decide where a “best of breed’ approach makes sense – should a function be better provided through a different component, then the existing component may be replaced with minimal impact.

The solution must be supported by skilled ISVs: the technology and business worlds will never stand still, and new technologies will continue to be required to help facilitate new business functions and respond to market forces. It is therefore key that the chosen solution has the on-going support of a high number of ISVs – the channel from which it is likely the new technologies will appear. In this, Quocirca does not just mean having ISVs that can state that as their solution has been written in J2EE/.NET, it is therefore capable of running on any solution that is compatible, but that the ISV can demonstrate an understanding of the chosen solution, that they can work with it in depth, providing hooks from their solution through into the value-added functionality of the chosen infrastructure where necessary. Broad-scale support through systems integrators and the availability of skills in the implementation and management of the environment must also be considered.

The solution must be able to be modified with ease: Although the move towards packaged solutions is still strong, the majority of implemented solutions still require a level of modification. Therefore, the ease in which these modifications can be carried out is another key concern. An application-centric solution may provide the capability for your existing application developers to increase the reach of their skills beyond the application itself to directly connected third-party areas, but is unlikely to enable full value-chain capabilities, where a completely open approach is required. Quocirca recommends that the chosen solution have development tools that are well proven, are as open as possible and have a broad level of adoption within the development community at large. Wherever possible, the solution should be capable of being used with your organisation’s existing development tools.

Quocirca recommends that a bus-based solution be utilised as a solution – this helps enable high process throughput, as the bus can be highly optimised for the transactions it is dealing with. It also helps enable existing applications and services to be easily plugged into the bus, and for the connectors and adaptors utilised to be tuned for best performance against the bus.

The solution must be capable of reporting along the full value chain: the capability to report at both a technical and business level against the process must also be considered. Again, this is predicated on the openness of the environment and the reach of the chosen solution.

6 Total Value Proposition

Technology purchases need to be made for solid business reasons

The impact of not carrying out an action must be considered

Qualitative, not quantitative, approaches to RoI and TCO are often required

When making decisions on any change within an organisation, the majority of focus is often placed on measurements such as Return on Investment (RoI) and Total Cost of Ownership (TCO) discussions. For Quocirca, a more rounded view is required, where the overall value that a solution offers to a company is paramount. Within this “Total Value Proposition” (TVP) approach, simple set of criteria is utilised to ascertain what the probable value of a solution will be to a company.

Quocirca recommends that organisations utilise this approach when looking at the case for moving to an application server/middleware platform. The following sections identify the areas that should form the main business considerations to help ensure that the solution chosen will provide the greatest overall value to the organisation.



Value, Risk and Cost The first stage of a TVP evaluation is to look at the direct impact of the proposed solution on the three main variables within a company. These three areas are:

Value:

Does the proposed solution add incremental value to the organisation?

Does it enable an organisation to offer more of the same goods or services more efficiently?

Can an organisation offer different services/products to the customer?

Can an organisation react quickly to its competitors’ actions?

Risk:

The question here is whether the proposed solution help lower risks for the organisation: does the fact that there is a new infrastructure mean that developing new services involves less change across the whole of the IT infrastructure? How easy or difficult will it be to integrate your IT system with different systems if new organisations are acquired or take on new suppliers or sales channels? Will it help reduce the number of IT errors and downtime? If there are problems, can they be isolated and resolved quickly and efficiently?

Cost:

Finally, the question of whether the new system lowers costs for the organisation is vital: can it be changed or update the products and services with less development and testing costs? Will an organisation be able to help lower costs by reducing the number of staff involved in system maintenance? Will costs to the organisation be reduced by better availability of systems, less downtime for non-IT staff? How long will existing applications last with this new architecture?

Game Theory The second stage of a TVP is to ascertain what the cost may be of not implementing a specific solution. Quocirca utilises a simple form of game theory to ascertain an appreciation of the cost of not carrying out a proposed change. This is a process, where an organisation looks at the following four scenarios:

Neither a business nor its competition have the proposed capability: neither gets the benefits of the proposed change, and market position stays the same (all other factors being equal) – but customers and shareholders do not benefit from any changes the proposed solution brings, and overall economic benefits to ourselves and the wider environment are not realised.

An organisation has the proposed capability, its competition does not: a business gains the benefits of the proposed solution, and it helps enable it to move more quickly and efficiently to meet the business objectives, be they improved market share or better profitability. Even assuming its competitor gains the proposed capability, first mover advantage may enable the business to significantly improve its business position.

An organisation does not have the proposed capability, its competition does: an organisation is in a weak position and potentially have to incur costs in other areas in order to compete with its competition. An organisation will either lose market share, or become less profitable, or both.

Both the organisation and its competition have the proposed capability: both benefit from the benefits that the solution brings. At the worst case, the business growth continues, as does that of its competition. At best case, both pick up business from other competitors, and so customers may benefit and returns to shareholders may improve; overall economic welfare may be maximised.

Simple cost of ownership and return on investment For many organisations, the lack of full knowledge of how much an existing process really costs makes RoI and TCO calculations difficult. Indeed, for many companies, baselining costs will require the company to keep utilising the existing solution for a period of up to 3 months while the costs are calculated – thus eating into the windows of opportunity available through the implementation of the proposed new solution. Even for those who do have an idea of existing costs, there may be problems when it comes to comparing like with like: after a change is implemented, the process that is being compared may not be the same as the one



that has been already measured. Also, the availability of hard costs (such as the fully-loaded cost for specific resources) may not be readily available – and it can end up with wildly different findings depending on who has carried out the calculations.

Quocirca’s approach is more qualitative than quantitative. It is recommend that companies take the five to ten highest priority processes that are going to be impacted through the proposed implementation. These processes should be at a high level, covering as broad a spectrum of usage as possible. Through this manner, we should still be able to compare like with like on a before and after basis.

Once the organisation has the process list, it can then make an educated estimate of whether the proposed solution will make each process more or less expensive to carry out. Scoring can be based on a level of 1 meaning that the process will be considerably less expensive, through 3 denoting that the process is likely to carry the same cost, through to 5 denoting that the process will be considerably more expensive.

Once this has been done, it is then simple to add up the scores, and divide by the number of processes involved. A low number will generally denote a rapid RoI/TCO; while a high number will show a low (or possibly no) direct RoI and a possible high TCO. However, this information should be utilised in conjunction with the previous two steps – if the Value, Risk and Cost components show high reasons for change, these may outweigh the risks of having a low RoI/high TCO. If the Game Theory exercise shows that not implementing the proposed change will result in market loss to the competition then the change may be the only way for the company to survive – even if the TCO is high.

7 Conclusions and recommendations

Standards and interoperability make SOAs a true option now

A move to SOA is not a “ rip and replace” action – it can be done gradually, and can include existing investments

An SOA must be inclusive – it must cover the needs of the business, and give capabilities to automate interactions along the value chain

The increased dependency of organisations on the underlying IT and the need to be able to respond more rapidly to changes in the market mean that changes in the way that they implement and manage the underlying IT infrastructure may be needed. No longer can “solutions” be put in place to specific issues – at all times, interoperability and technical flexibility must be borne in mind, so that business issues, predicated on business processes, can be dealt with in the round.

However, the existing investments in technology cannot be written off, and an organisation must look to how these can be included in the new environment.

To this end, companies must prepare for SOAs, putting in place an environment that has the inherent flexibility and standards support to include existing investments, and to embrace emerging solutions.

It is Quocirca’s view that this platform must address the needs of not only the main users within the organisation, but also the needs of the company looking up and down the value chain, thus supporting the business’ processes from end to end.

Quocirca’s view is that attempting to do this through an application-centric approach may lead to an over-dependence on the application vendor, and that the lack of ISV in areas two or more steps removed from the ISV’s core competencies can create the need for hard-coded connectors that may further compromise the flexibility of the company.

Therefore, Quocirca’s main recommendations when looking for a suitable solution are that the following capabilities be demanded from the vendor:

Solid ISV and system integrator support

Full Web Services (WS-*) standards support

A fully SOA, based on integrated yet independent service components

Capability to support loose coupling of services

The provision of a bus architecture including data transposition, translation and transport capabilities



Full tooling, measurement and reporting capabilities

Supported flexible connectors for existing enterprise applications

Broad support for multiple hardware and operating system platforms

High levels of internal and cross-organisation security

Built-in workflows with “stateful” support (the capability to fully understand and track the state of a service and its associated data)

Full support for existing communication and collaboration systems

Support for business continuity through full workload management and virtualisation

The aim is to create a platform that removes the business processes from any dependencies on the technology – and so free up the organisation to concentrate on reacting to changes in the market. There is a need to minimise the amount of maintenance required – and so the number of supported platforms should be minimised as well. Although it may be felt necessary to underpin a core enterprise application with its own application server and middleware platform, Quocirca advises that organisations choose a main infrastructural backbone application server/middleware platform to support the end to end business processes.



Appendix A – Use Case Scenar ios – Facing up to Business challenges In many ways, the challenges facing most organisations are similar – such as the shrinking of windows of opportunity, financial pressures, the need for inclusion of partners in the value chain. However, specific verticals have their own challenges – and a few are addressed here.

Channel Optimisation in Retail

Consumers are demanding new ways of shopping and are eagerly shopping across multiple channels

A seamless cross-channel customer experience is an imperative not a luxury

Success in the multi-channel world requires retailers to break down organizational silos

New challenges require a flexible, multi-channel platform not standalone e-commerce applications and point solutions

Many organisations want to put their customers at the heart of what they do. But as organisations expand, develop their product portfolios and enter new markets, then the relationship with their customers becomes more diverse. Many of the most complex customer and channel relationships are to be found in the retail sector. Some of the issues facing typical large retail organisations will include:

multiple means of customer interaction: in-store, online, from catalogues, by phone - with a mix of these methods potentially in a single transaction - phoning a call centre to add items to an online delivery, for example

retailers are looking to new goods and services to grow revenue: white goods retailers are selling a range of services and products like repair contracts and installation services, while CPG/FMCG retailers are increasingly moving into such areas as cellular phone contracts, and even financial services.

specialist sales and support processes: selling services rather than products means more and different processes and people, and some services – finance and utilities in particular – have very specific regulatory requirements.

specialist channels: many of the services sold by food or other retailers will be operated by specialists in a particular area on behalf of the organisation which owns the brand, and the brand owner will need to be able to track what is being sold and to whom, and to be sure that the service is being sold and supported in such as way that is consistent with the overall brand message and commercial agreements reached.

single view of the customer: with customers shopping across channels, and cross channel shoppers spending more than single channel shoppers, retailers need a consolidated view of their customers to help identify their most valuable ones

customers have single view of the retailer: consistent delivery of service and information across channels is expected and that requires a continuous state of interaction with each customer

internal alignment: retailers must harmonize assets and processes across the value chain to meet customer demands and help optimize their channels

In a multi-product, multi-channel environment, it is important that communications between the customer and the retailer are as easy as possible. From the retailer’s perspective, having a holistic view of the customer across the different channels offers a number of benefits:

customer value may be increased: information on customers’ purchasing patterns can be accumulated, customised offers can be developed and opportunities for cross-selling identified, targeted promotions and point of sale cross sells can be deployed across channels

customer centricity may be improved: the entire organization can make decisions based on accurate and consistent customer information, from merchandising through to the associates in the store, the call centre representatives and the web shopping experience. Channels may be optimized to suit the customer’s needs and the retail assortment, helping to lower costs and increase customer satisfaction



If customer satisfaction is improved, loyalty may be built and repeat purchases may become more assured. This may lead to increased sales and decreased costs as organisations learn more about what their customers want and do buy.

The need here is for a platform that can seamlessly pull together the multi-channel aspects of customer interactions in a flexible, responsive and end to end manner.

Pulling together the customer and vendor chains in Finance

Increasing complexity of channel relationships in the retail sector continues. In finance, complex vendor chains are common, and there has been pressure for many years to speed up transactions, most notably in equities. The growth of online trading has also given a stimulus for faster, automated, transactions. The application of straight-through processing (STP) has developed throughout the sector, seeking to automate the processes between the different entities involved in the sales and settlement chains. Each part of the value chain presents different challenges:

The speed with which a transaction can be carried out is paramount

Governance is key – all transactions must be monitored

Risk management is vital

external vendors: these will include organisations completely outside of the financial sector as well as the traditional independent advisors (individuals or firms). They will need to be kept up to date with the organisation’s products and services, sell in a manner which aligns with the internal processes and regulatory requirements, including risk assessment, and be paid in the appropriate way.

the organisation’s own sales force: again, making sure they align with internal risk processes, are compliant with regulatory requirements and paid appropriately is important. They may also be increasingly mobile and need business and technology support out of the office, at home or at a customer’s premises.

the organisation’s trading desk: here, presentation of reliable, up-to-date data from a range of sources, accurate risk assessment and speed of transactions are key.

compliance management: the need to be able to monitor processes across the value chain, to receive accurate and timely data and produce reports to show compliance are key

back office: automating previously manual processes, such as traders filling out paper tickets which are then passed over to others for processing, may help reduce potentially costly errors and lead to greater efficiency and customer satisfaction.

A typical sale involved in the financial sector will encompass a range of processes which go across the various departments in the organisation. For example, in an insurance sale, lead generation might come from an external sales partner, the lead might be qualified according to internal system of ranking (does this person live in a high crime area?), the lead would then be passed back to the external partner to identify and recommend a solution, then back to us to process the application, to another partner to underwrite the solution, back to the original sales partner to complete the order with the customer, back to us to complete with the underwriter, then into the internal system and the sales partner’s to manage the account.

Automating such processes brings significant benefits: operational efficiencies are increased, costs are reduced, error rates are reduced and customer service is improved.

The need here is for a platform that helps enable secure interactions across the value chain, enabling intermediaries to interact with centralised live data while dealing directly with their customers.



Building dynamic business reports from multiple data sources in the telecoms sector

Organic and acquisitive growth has led to a high degree of heterogeneity

The proliferation of services and channels requires multiple data sources to be aggregated

Better information is key to helping improve marketing and sales

Modern organisations sell an increasing range of products and services to more people and need to manage multiple channels involved in selling to, and supporting, customers. They need close relationships with all their partners in the value chain. However, the large-scale merger and acquisition activity in the market has led to highly heterogeneous environments, with multiple billing engines, multiple different base technologies at both the network and computer level, and multiple CRM systems aimed at providing support to the customer base.

Data from these customers and partners is vital in order to help maximise business effectiveness. More than this, data from many sources needs to be able to be consolidated, validated and used to produce actionable reports which may help improve effectiveness. These sources are both internal and external: a typical mobile operator, for example, will have a range of systems (network, messaging, customer care and billing), different sales channels (direct sales, own or third party retail outlets, internet) and a range of services (plain voice telephony, text or picture messaging, international roaming, data services). All of the data from such sources needs to be gathered together to build up a picture of both customers and performance of different parts of the organisation. Areas where dynamic business reports help add value to the organisation include:

Market segmentation: which are the most valuable customers? What are their purchase patterns? Are there any segments which should be buying a particular product, but do not?

Usage patterns: these can be tracked to help with new product development, special offers and churn management: how are customers using services? What can an organisation do to encourage their customers to make more use of its services?

Personalised offers: mobile customers who travel frequently to France can be given a specific discount on roaming calls there, for example.

Sales channel effectiveness: which channels bring us the most valuable customers? How much does it cost to gain customers from each of the identified channels? Where are the most effective channels?

Churn analysis: which customers are most likely to stop using the service offered? Are there any usage patterns which lead to more churn than others? Are there any sales channels who supply customers who churn more frequently?

The need here is for a platform that helps enable multiple data sources to be virtualised, helping to enable data to be searched and reported rapidly.



About Quocirca Quocirca is a perceptional research and analysis company with a focus on the European market for information technology and communications (ITC). Its analyst team is made up of real-world practitioners with first hand experience of ITC delivery who continuously research and track the industry in the following key areas:

Business Process Evolution and Enablement Enterprise Applications and Integration Communications, Collaboration and Mobility Infrastructure and IT Systems Management Utility Computing and Delivery of IT as a Service IT Delivery Channels and Practices IT Investment Activity, Behaviour and Planning

Quocirca research is always pragmatic, business orientated and conducted in the context of the bigger picture. ITC has the ability to transform businesses and the processes that drive them, but often fails to do so. Quocirca’s mission is to help organisations improvetheir success rate.

Quocirca has a pro-active primary research programme, regularly polling users, purchasers and resellers of ITC products and services on the issues of the day. Over time, Quocirca has built a picture of long term investment trends, providing invaluableinformation for the whole of the ITC community.

Quocirca works with global and local providers of ITC products and services to help them deliver on the promise that ITC holds forbusiness. Quocirca’s clients include Oracle, Microsoft, IBM, Dell and Cisco, along with other large vendors, service providers and more specialist firms. Sponsorship of specific studies by such organisations allows much of Quocirca’s research to be placed into the public domain. Quocirca’s independent culture and the real-world experience of Quocirca’s analysts, however, ensure that the research and analysis is always objective, accurate, actionable and challenging.

Quocirca reports are freely available to everyone and may be requested via www.quocirca.com.

Contact:Quocirca Ltd Mountbatten House Fairacres WindsorBerkshireSL4 4LE United Kingdom Tel +44 1753 754 838

2nd Edition April 2005Enterprise e-Infrastructure Analysis

White Paper

Enterprise Integration ChallengeVendor Middleware-based Integration Solutions Offer

Major Advantages Over Custom In-house Solutions

© Software Strategies 20052

Important Notice: The information available in this publication is given in good faith and is believed to be reliable. Software Strategies expressly excludes anyrepresentation or warranty (express or implied) about the suitability of materials in this publication for your purposes and excludes to the fullest extent possibleany liability in contract, tort or howsoever, for implementation of, or reliance upon, the information contained in this publication. All rights reserved. This publication,or any part of it, may not be reproduced or adapted by any method whatsoever, without prior written Software Strategies consent. Software Strategiesacknowledges all trademarks.

Written by: Ian Bramley

Published: 2nd Edition April 2005

Design & Layout: iok design – e-mail: [email protected]

© 2005 Software Strategies. This publication is property of Software Strategies and cannot be adapted, copied, or reproduced, by any meanswhatsoever, without prior written permission from Software Strategies.

About this White Paper

Business and system integration remains one of the top three CIO priorities for 2005/2006, along with increasing security andensuring regulatory compliance. In fact, all three of these priorities are closely related.

Enterprises are seeking to improve/streamline their core business processes by integrating application silos within theirenterprise and across their extended ecosystems. They also seek to defend their systems better, and ensure compliance with afast-growing regulatory burden.

Enterprise Integration, where individual applications are programmatically linked to exchange information, has been a majoreffort for many years now.

But much more application integration work is still needed in almost every company, even though many have alreadyimplemented scores or hundreds of integration links to date. Application portfolios are large (up to 1000 systems in the largest500 global firms and up 400 in the next top 10,000 enterprises). The number of integration points needed is also very high(averages of 1000 and 500 respectively for these two groups).

Robust, advanced Enterprise Integration middleware platforms that make application integration much faster and cheaper toimplement and support, and provide superior operational attributes, have been available for over ten years. These platforms haveadvanced greatly and proved these benefits at thousands of customer sites. Adoption is near universal (~100%), amongst the largest500 global enterprises, but plummets below 50% amongst the next 10,000 largest firms, and down to 20% amongst the next250,000 medium businesses worldwide. Even amongst adopters, we found the proportions of the integration projects they havedone using Enterprise Integration vendor middleware are surprisingly low (30-45%, 15-25%, and 25-30% on average respectively).

So what have non-adopters used to deliver the application integrations already done?

What are adopters using on the projects where they have not deployed their vendor Enterprise Integration middleware?

Why are the proven benefits of vendor Enterprise Integration middleware not more widely accepted?

Our staggering and somewhat shocking research finding is that custom-built, in-house, hard-coded integration solutions (themajority using free FTP software) are much the most widely-used approach. These often take 2 to 4 times the time and effortto build as Enterprise Integration middleware-supported integration projects, require a similar multiple of ongoing maintenanceand support effort, and are insecure, fragile and vulnerable to several serious risks. Enterprises heavily relying on thisapproach, as it seems most do, have built intrinsically weak links into their application infrastructure and wasted large amountsof precious development and support resources they need not have incurred. It is also hard to see how those using thisapproach can keep up with competitors using vendor Enterprise Integration middleware technology, or avoid becomingincreasingly burdened with unproductive support.

Our research thus shows much of the market has yet to understand why a common vendor Enterprise Integration middlewareintegration platform provides a superior, universal, cost-effective and maintainable means of handling all/most of the manyintegration points they need to build today and tomorrow

In this White Paper, Software Strategies reviews the drivers for Enterprise Integration today, examines the global size and scaleof the challenge and evaluates the main methods that companies have actually used to deliver integration to date. We alsoanalyze the adoption and internal deployment levels of vendor Enterprise Integration middleware platforms by different sizes ofenterprises, and seek to address the questions posed above.

© Software Strategies 2005 3

Figure 1: Prime Enterprise Integration Drivers 2005 9Figure 2: Application Integration Challenges by Size of Business 2005 12Figure 3: Enterprise Integration – Primary Solution Options Used Today 14Figure 4: Number of Application Integration Links Done to Date and Needed by Size of Business Estimates 17Figure 5: Enterprise Integration Effort/Cost by Integration Approach Used 18Figure 6: Relative Development Resource Costs/Efforts by Application Integration Option Used 18Figure 7: Application Integration – Enterprise & SMB – Vendor Enterprise Integration Middleware Adoption 2005 20Figure 8: IT Budget Savings Obtainable by Using Enterprise Integration Middleware Platforms 22Figure 9: Candidate Strategic Enterprise Integration Platform Vendor List 25Figure A1: Soaring Regulation and Compliance Demands – What is Driving Them? 28Figure B1: IBM WebSphere Integration Reference Architecture 2005 30Figure B2: The IBM WebSphere MQ Product Family – Our Overview 31Figure B3: Business Value Enhancements in WebSphere MQ Version 6 32

White PaperEnterprise Integration ChallengeVendor Middleware-based Integration Solutions Offer Major Advantages Over Custom In-house Solutions

CONTENTS

TABLE OF CHARTS

1. Executive Summary 5

2. Introducing Enterprise Integration 6

3. What is Driving Enterprise Integration Demand Growth? 9

4. How Large is the Enterprise Integration Challenge Today? 11

5. What are the Main Enterprise Integration Options Used Today? 14

6. Vendor Enterprise Integration Middleware Platform Deployment 19

7. Selecting the Right Enterprise Integration Middleware Platform/Vendor 24

Appendix A: Expanding Regulatory Regimes and Compliance Demands Drives Application Integration Workloads 28

Appendix B: Example Vendor Enterprise Integration Middleware Platform – IBM WebSphere MQ Version 6 29

Appendix C: Representative WebSphere MQ Customer Experiences 33

Other Related Software Strategies Research 34

Software Strategies 35

About the Author 35

1. Executive SummaryThis new White Paper evaluates and assesses Enterprise Integration and what is driving the widespread increased demands forintegration. It also identifies how companies are actually performing integration today. The Paper shows there is scope forconsiderable improvement through the wider use of vendor Enterprise Integration middleware platform software. This ExecutiveSummary provides an overview of our findings, assessments and recommendations for IT users, which are detailed and developedmore fully in the White Paper itself.

1. Top IT Priorities for 2005-2006: Regulatory compliance, integration and security are rated top IT priorities for 2005-2006 inmost CIO surveys, and are closely linked.

2. Strong Enterprise Integration Demand Growth: Regulatory compliance, business transformation, On Demand business, and otherforces, are driving many new Enterprise Integration projects. Enterprise Integration, the linking of separate enterprise applications toexchange information, has again come to the foreground as enterprises increase IT investments and look to generate top-line growth.

3. Enterprise Application Portfolios Must be Better Connected: Enterprises built and acquired wide application portfolios overmany years on a number of platforms. These portfolios are large (400-1000 systems in top 500 global enterprises) and many newintegration points are still needed between them, and now also to numerous external ecosystem systems. How are companiesactually implementing these important “bridges” between key applications? Are they making the best use of available technologies?

4. Vendor Enterprise Integration Middleware Platforms Well-proven: The better Enterprise Integration middleware platformsmake application integration much faster and cheaper to implement and support, and provide superior operational attributes.Such products have been available for over ten years, have advanced greatly, and proved their benefits at many thousands ofcustomers. We found adoption is near universal at close to 100% amongst the largest 500 global enterprises who have thebiggest integration challenges, and are usually the first to adopt productive IT technologies such as this.

5. But Many Enterprises are Missing Out on Proven Benefits: Despite these widespread successes and long-provenEnterprise Integration middleware benefits, our research showed barely 50% of the next 10,000 largest enterprises, and just20% of the next 250,000 largest medium businesses have adopted vendor Enterprise Integration middleware to date. Thesefirms are missing out completely on a more flexible, faster and cheaper way of delivering the widespread and increasing needs forintegration in their companies. This, of course, means that they are currently using other methods to deliver needed integrationsolutions, and we investigated what these were to find some surprising and even shocking results.

6. Even Adopters Usage Not Universal: The picture is actually somewhat worse than the above suggests. We found that, amongstEnterprise Integration middleware adopters, the proportions of all the integration projects they had done to date using such middlewareremained quite low (30-45% for the 500 largest enterprises, 15-25% amongst the next 10,000 largest enterprises). Clearly the use of othertechniques often predated Enterprise Integration middleware adoption. Again the questions were, what alternative methods had they usedto implement their integration solutions before adopting Enterprise Integration middleware, were they still using these as well and, if so, why?

7. Integration Solution Methods Used Surprising: We found by far the most widely used method of building integration solutions,in all sizes of companies, was custom-built, in-house-developed solutions built with low-level languages, most using basic, free FileTransfer Protocol (FTP) software for data movement. Such basic approaches require much costly development, are fragile andinsecure in operation, and need costly ongoing support, and it is hard to understand why they are so widespread.

8. Custom-build Integration Users Wasting Time, Money: Point 7 above means countless companies are using far slower,more staff-intensive, less-secure and lower-performing approaches to integration, and are also building into their organizationa growing burden of costly future support; surprising when affordable vendor Enterprise Integration middleware alternatives areeasily available. Our advice would be to “cease and desist”.

9. Problem Has Low Visibility: We consider it likely that few CIOs realize just how widespread custom-built integration may havebecome within their organization, or what it is really costing, because this work tends to be low profile, commonly as a part oflarger application projects. Asking some pointed questions to find out the extent, exposure and risk is therefore advised.

10. Vendor Enterprise Integration Middleware Platforms – The Way Ahead: The class of Enterprise Integration middlewareplatforms provides comprehensive and broad-ranging capability to address almost all integration needs with a commonplatform. Earlier, the Enterprise Integration market had seen a profusion of specific point-middleware products for narrow rolesor tasks. Today, we counsel prospective purchasers to look strongly to adopting such an Enterprise Integration middlewareplatform, rather than the several or many point products otherwise needed. Reasons for this advice are contained in this paper.

11. Vendor Enterprise Integration Middleware Benefits Not Understood Widely Enough: It seems clear on our analysis that the 50%of the enterprise market and the 80% of medium businesses who have not yet adopted vendor Enterprise Integration middleware havenot yet fully understood how strong the benefits are, and the quick ROI that is obtainable. We counsel them to investigate and get up-to-speed on this beneficial technology; which has become more affordable and now offers a wider range of entry points.



12. Open Standards Vital to Enterprise Integration: More than almost any other middleware category, open-standards play adisproportionately crucial role in enabling the integration, inter-operation and freedom from proprietary lock-ins that areessential. There are many open standards applicable to Enterprise Integration, including the J2EE™ programming model, theEclipse open AD tools platform, Web Services, TCP/IP networking, Secure Sockets Layer (SSL) security, and many more.Enterprise Integration middleware platforms must fully support all these, and other standards, to achieve their fullest potential,and proprietary middleware approaches should be avoided.

13. Enterprise Integration Market Concentration Eases Selection: A small group of vendors offer more complete, integratedEnterprise Integration middleware platform suites that lead the market by software revenue share. These leaders are gainingground as customers seek quality, security and endurance in a software sector that saw much turmoil and consolidation inrecent years. Many of the early, smaller, point-Enterprise Integration middleware products and vendors have faded from themarket. We list and cameo a selection of industry vendor firms in Section 7.

14. High-level Criteria for Vendor Enterprise Integration Middleware Selection: Although the Enterprise Integration middlewaremarket has consolidated and settled into a more normal profile after the earlier profusion of vendors and offerings that floweredup to the dot.com bust, care and caution are advised in selection. Special characteristics of vendor Enterprise Integrationmiddleware platforms demand particular care in short-listing and selecting a vendor/platform. We explore and examine thesefactors in Section 7 and propose seven high-level criteria that differentiate between the available alternatives. Prospectivecustomers should find these helpful in making the right choice.

15. Vendor Enterprise Integration Middleware Platform Example: In Appendix B we profile and assess a leading example of a topvendor Enterprise Integration middleware platform to illustrate the broad functionality and capabilities such products can nowprovide. Those unfamiliar with this class of platform will find that this provides a useful overview of the sort of capabilities required.

2. Introducing Enterprise Integration

About This White Paper

Specialist e-infrastructure analysts Software Strategies wrote this White Paper, published in April 2005. It examines and assesseshow enterprises have implemented application integration to date. In particular, we were interested in how widely EnterpriseIntegration vendor application integration middleware has been deployed, and what advantages it offers over traditionalalternatives. Based on our proprietary research and 15-years of middleware experience, we aimed to shed more light on whetherthere were areas for improvement in how enterprise IT organizations are tackling their expanding application integrationchallenges. The findings and conclusions are ours alone.

Who Should Read This White Paper?

This White Paper was designed and written primarily for CIOs, CTOs, Heads of Development and other Senior IT Executives inenterprise IT customer organizations concerned with delivering an enhanced enterprise application portfolio to the business. Italso addresses IT Managers in medium-sized businesses, who face similar application integration challenges on a smaller scale.ISVs and SIs, who are often concerned with selecting and supporting application integration middleware for and with theircustomers, will also find this White Paper of value.

Application Integration Growth Fuelled by 1990-2005 Enterprise Application PortfolioExpansion

For the last fifteen years, a rapidly growing effort in enterprise IT organizations has been to develop and support an expanding numberof application integration links. These interconnect diverse, different applications and platforms to enable better support for improvedbusiness processes. Increased application integration demand was triggered by the rapid 1990s proliferation of new distributedcomputing platforms (Novell NetWare, Windows NT, and various RISC UNIX flavors, etc.) alongside the long-established hostmainframes, midrange systems and large PC workstation populations then and now also found in most enterprises. These newdistributed platforms supported new types of applications that became pervasive and important components of today’s enterpriseapplication portfolios. Departmental and workgroup productivity, e-mail and collaboration, EDI, Enterprise Resource Planning (ERP),Customer Relationship Management (CRM), and Supply Chain Management (SCM) were foremost amongst these, and many newapplication integration links between core transaction and business systems and these newer e-business applications were needed.

The radical move to e-business and the Web became the next major driver of integration projects, adding Web sites, Web serving,B2C, B2B and many other new types of Web-based application, most of which also required multiple integration links with otherenterprise applications.

New Drivers Increasing Enterprise Integration Demands TodayToday in 2005, a number of drivers continue to increase Enterprise Integration demands, adding to the challenge faced by busyenterprise IT teams. Our research identified that the main drivers now include:

Regulatory Compliance & Corporate Governance Mandates.

Need to Integrate ERP, CRM & SCM Application Packages With Other Enterprise Systems.

Need to Integrate New E-business, B2B, B2C, B2P Web Applications With Legacy Applications.

Diverse Enterprise-specific Tactical Application Integration Project Needs.

To Support On Demand Business Transformation, Service Orientated Architecture (SOA) and Business Integration Initiatives.

Vertical Industry-specific Application Integration Initiatives (e.g. HIPPA in healthcare).

New Technologies Driving Application Integration Initiatives (e.g. RFID).

We examine and evaluate these drivers more fully in Section 3, but note that regulatory and compliance mandates have todaybecome a high-priority, top C-level Executive focus for boards in most industries and geographies worldwide.

Application Integration Approaches – Early EvolutionApplication integration always involves moving data out from one application, often across platforms, and into another. It may addother intermediate processes (extraction, cleansing, transformation, aggregation, security, and logging, etc.) performed en route.

Around 1990, most application integration links were custom-developed by IT teams, mostly using familiar, low-level 3GL languages,scripting tools, and file and database managers. A few brave users even developed their own integration technologies. Customdevelopment was costly, both in its initial development time and effort and in the ongoing maintenance and support resource consumed.Proprietary system and application architectures, lacking common unifying standards, amplified the effort and cost of building thesecustom integration links. They were typically tightly coupled, hard-coded, and point-to-point. They were inflexible and vulnerable tochanges in any part of the connected infrastructure. Analysts would therefore not expect to find this approach widely used today.

The rise of TCP/IP networking during the 1990s, now the near-universal enterprise network and Internet standard, brought in FileTransfer Protocol (FTP), a simple, standardized method of moving files from one location or platform to another. Enterprises beganusing standard FTP software tools (often free) within their custom application integration solutions, to provide the core data movingfunction, wrapping it with still-considerable custom logic and code to perform the other needed functions, with the same rigiditiesas above, but some savings in effort. Amazingly, our research revealed that this simple, unsophisticated and basic approach toapplication integration remains overwhelmingly the most widely-used solution approach today.

Enterprise Integration MiddlewareWith this near-universal and fast-growing wave of Enterprise Integration, a market for a new class of vendor application integrationmiddleware sprang up at the start of the 1990s. The Enterprise Integration middleware uptake grew strongly over that decade and intothe 21st century. One market research firm (WinterGreen Research: August 2004 EAI Report) for example, recorded $2.5 billion in 2003combined Enterprise Integration middleware software license and direct services revenues, and forecast growth to $5.9 billion by 2009.An explosion of new vendors entered this market (over 200 at its 2000 peak), with diverse integration solutions. These included manyproprietary and point offerings, and a few more open standards-based, universal platforms. In 2005, after much consolidation andturmoil, a well-defined Enterprise Integration middleware market, dominated by a few major players, has finally emerged.

Vendor Enterprise Integration Middleware – What Does it Do, and Why is it Needed?All vendor application integration middleware sought to simplify, speed, and ease application integration by providing standardmiddleware software engines offering common core functions and services required in most integration scenarios. Their useincreased flexibility, and greatly reduced the custom development and maintenance effort, in return for software license fees forthe products. In the best cases, these delivered compelling broad benefits. A wide variety of technologies and approaches wereintroduced, as in any new software markets, some purporting to be general platforms for integration, but most offering point-solutions or other, more specialized approaches. Over the fifteen-year period, the winning technologies and vendors have clearlyemerged and proved their value at thousands of IT-user sites. The earlier profusion of smaller start-up Enterprise Integrationmiddleware vendors has consolidated through mergers, acquisition or failures.

With the already high and growing pressure on enterprise IT teams to “do more with less”, readers would expect mature EnterpriseIntegration middleware (now well-proven to deliver “better, faster, cheaper” solutions) to be universally used on all applicationintegration projects. One would expect this to particularly apply in most enterprise-level IT organizations, as well as in many“medium-sized” business IT groups where IT resources are even more constrained.


Our Research Reveals Shocking Enterprise Integration Practice Truths

For this White Paper, we used a variety of research approaches to identify and broadly analyze how businesses had, in reality,

implemented their application integration solutions to date.

Amazingly, by far the most widely-used application integration method found deployed to date in all sizes of business was

custom-developed, free FTP package-based approaches. These are relatively primitive, costly to develop and code, insecure,

need substantial and costly ongoing maintenance, cannot provide high Quality of Service (QoS) levels, and are particularly

vulnerable to software changes or errors in their environment. Enterprises depending heavily on this approach are burdening

themselves with high development and ongoing support costs, weak security, and high risks. Why is this, when better

alternatives have long been available?

Vendor Enterprise Integration middleware platform-based solutions were the second most widely-used approach and offer a

much higher-quality, lower-cost and faster time-to-value route. However, we found that, whilst almost 100% of the largest

enterprises had now adopted this well-proven approach, barely 50% of the next 10,000 largest enterprises, and less than 20%

of the next 250,000 medium-sized businesses have done so to date. Even those who had adopted and implemented vendor

Enterprise Integration middleware had only used it on a varying but usually minor part of their total integration portfolio, so were

also continuing to support many more primitive and costly in-house built, or point-middleware-based integration solutions. Why

has adoption and penetration not been higher when the benefits are compelling?

The third most widely-used method of integration was entirely custom-built, in-house solutions (not using FTP), that are even

more primitive and costly even than the former, amplifying all the disadvantages above without the modest benefits of FTP.

Incredibly, business change consultants have told us of discovering numerous cases of whole departments of staff being

employed wholly or mainly to provide essentially manual application integration functions and processing. Clearly deployed to

bridge incompatible and non-integrated application systems, these departments obviously incur massive staff costs, slow

business processes whilst also introducing errors and omissions. These should have been fully or largely automated by

software application integration long ago. Why have these companies and their IT teams not spotted and automated such a

ludicrous waste of resources?

These surprising, even shocking findings from our work are more fully presented and discussed in Section 4.

Findings Pose Important Questions for Enterprise IT Management

These findings pose important and challenging questions for CIOs (and other senior IT executives) responsible for enterprise IT

strategy and technology that include:

Why are such primitive and costly Enterprise Integration approaches still so widespread today, fifteen years after the first Enterprise

Integration middleware solutions that now offer a much superior approach, long-proven to work well, became available?

Do the companies so widely using these primitive approaches actually realize how much more these are costing them than the

better vendor middleware-supported solutions, and how much higher the risks are?

Amongst those who have recognized these benefits, and introduced vendor Enterprise Integration middleware, why have they

only deployed it on a moderate proportion of their total application integration project portfolio, when its benefits are universal

and well-established?

We amplify, discuss and seek to answer these questions, and to provide recommendations for improvement in this White Paper.

Our Analysis

Enterprise Integration is a universal need that has expanded greatlyover the last 15 years, as application portfolios have became muchwider. Powerful drivers today are pushing enterprises hard toimplement yet more integration links for compelling reasons,including powerful regulatory compliance demands.

Traditional “hand-tools-based” and “do-it-yourself” in-house solutions for application integration remain widespread, despite boththeir serious disadvantages and costs, and the long availability of well-proven vendor Enterprise Integration middleware platformsand point solutions to do a far better job.


Traditional “hand-tools-based” and “do-it-yourself” in-house solutions for application integration remain

widespread...

The leading vendor Enterprise Integration middleware platforms

have been near-universally adopted by the largest 500

enterprise IT users, but by far lower proportions of other

enterprise IT users and by medium-sized businesses.

In our assessment, many enterprises are therefore wasting

large amounts of scarce development and support resources by

continuing to build and maintain application integration links

with basic techniques. In doing so, they are creating a growing new legacy software burden that will soak up unnecessary support

resources and, with the fragility of many of these solutions, creating higher risks of disruption for their business than they need to.

3. What is Driving Enterprise Integration Demand Growth?

Introduction

In the previous section we introduced and explained Enterprise Integration, and how it became a major effort within almost every

business today, particularly in larger enterprises. We found additional drivers exerting pressure for additional application integration

links to be implemented today. What are these drivers and which are the most important?

Research Reveals Seven Main Enterprise Integration Drivers

Our research has identified seven principal drivers that are today fuelling the rapidly growing demand for Enterprise Integration

projects at enterprise IT organizations throughout the world.


...many enterprises are therefore wasting largeamounts of scarce development and support resourcesby continuing to build and maintain applicationintegration links with basic techniques.

Figure 1: Prime Enterprise Integration Drivers 2005

Prime Enterprise Integration Drivers 2005

EnterpriseApplicationIntegrationDrivers 2005

# 1 RegulatoryCompliance &

Corporate GovernanceMandatories

# 2 ERP, CRM & SCM Application Package

Integration WithOther Enterprise

Systems

# 3 E-businessB2B, B2C B2P Web

Applications Integrationwith LegacyApplications

# 4 Enterprise SpecificTactical Application Integration Project

Needs

# 6 VerticalIndustry-specific

ApplicationIntegration Initiatives

e.g. HIPPA

# 5 On DemandBusiness

Transformation, ServiceOrientated Architecture

(SOA) and BusinessIntegration Initiatives

# 7 New Technologies Driving Application

Integration Initiativese.g. RFID


These are highlighted and ranked in terms of their importance and frequency of occurrence as Enterprise Integration projectdrivers in our Figure 1 chart on page 9. We briefly discuss each of these below.

# 1 Regulatory Compliance & Corporate Governance Mandates: Many analysts now rank the large and growing wave ofregulation and compliance demands being placed on enterprises, in every marketplace and every geography, today asperhaps the strongest current driver of Enterprise Integration projects. Many of these initiatives place stringent demands forassured integrity, security, risk reduction, traceability and other attributes on the regulated organization that have now becomea principal concern of boardrooms everywhere. Almost all of these regimes place stringent new demands on the enterprise ITsystems that support the core business, and usually involve new application integration links. Efforts to improve corporategovernance lie behind many of these regimes. We amplify and discuss this driver in Appendix A on page 28.

# 2 ERP, CRM & SCM Application Package Integration With Other Enterprise Systems: Several $100Bs were spentpurchasing, implementing and deploying a new generation of packaged and standardized integrated enterprise applications inmany enterprises over the last ten years. ERP, CRM, SCM and PLM are the four most widely-deployed categories of standardenterprise applications. Their implementation proved to be a massive and time-consuming effort, not least because of the largenumber of application integration points needed to connect these originally somewhat monolithic and proprietary applications tothe other existing and new applications. Openness and integration options provided in enterprise application packages haveimproved considerably today, and most Enterprise Integration middleware offers adapters and connectors to the majorpackages to simplify integration. New integration link projects of this type continue to be a major driver. (Ranked # 2.)

# 3 E-business, B2B, B2C, B2P Web Application Integration with “ Legacy” Applications: The third and continuing wavethat is driving the need for many new application integration links has been e-business itself. Pulling together new Webapplications to support B2B, B2C and B2P online applications has required, and continues to require, a profusion of applicationintegration links and services to interconnect newly-written functionality, legacy applications and enterprise packageapplications, such as those above.

# 4 Enterprise Specific/Tactical Application Integration Projects: There are a wide diversity of company, industry, orgeographically-specific application integration links that are also needed that combine to form this large driver category, andwhich fall outside the other driver categories here – the national standard interfaces that integrate bank systems to the nationalclearing system in each market would be a typical example.

# 5 On Demand Business Transformation, Service Orientated Architecture (SOA) and Business Integration Initiatives:Many leading enterprises are moving on to the next wave of e-business, which many are calling On Demand. Here, businessesare seeking to become better-integrated and more responsive, to streamline their core business processes and to respond fasterto fast-changing demands. Business integration, process integration, and people integration within the enterprise are needed, andapplication integration is fundamental to all these.

# 6 Vertical Industry-specific Application Integration Initiatives: In some vertical industries, networks, exchanges, markets,and/or data interchange standards are already important elements of that industry’s ecosystem. These all require applicationintegration with enterprise applications for members of that industry. Early examples included the SWIFT network and financialmessage exchange standards for inter-bank transactions, the SITA network and its protocols in the airline industry, and manyothers. Recently emerging are fundamental new models and standards, such as HIPPA in the US healthcare industry. Thisseeks to electronically integrate and standardize the whole healthcare provider, healthcare insurer, and healthcare managementnexus of that industry around a common framework, to achieve large cost savings of benefit to all participants.

# 7 New Technologies Driving Application Integration Initiatives: Other important drivers are some newly-emergenttechnologies that require extensive application integration with existing systems. Two examples illustrate this group nicely.Pervasive or mobile computing, connecting mobile devices to corporate systems, has emerged in recent years as a newproductivity and communication support for increasingly mobile workforces using mobile devices such as cell-phones, pager,notebook PCs, and handheld computers, etc. All pervasive and mobile computing deployments require new applicationintegration. Another just now gathering momentum is RFID (Radio Frequency Identity Detection), which promises to allowdramatically better tracking of supply chain and inventory/goods throughout their manufacturing, transportation, distribution, sale,and even use phases. RFID will generate a new flood of data and require extensive application integration with existing systems.

Not every enterprise will be emphasizing all seven types of driver on their business roadmap at any one time, but many will befocusing on two, three, of four of these. All require extended application integration capability.

Our Analysis

The challenge of Enterprise Integration is already substantial, but the seven drivers above are increasing this challengesubstantially. At a time when IT investment is again moving forward, a high proportion of critical business initiatives will fall intoone or more of these categories, and will demand additional application integration.

Those enterprise wishing to cope better and faster with this wave ofapplication integration and avoid adding a further future legacy supportburden should ensure that they are using the much more productiveEnterprise Integration middleware integration approach on all or mostof their new integration projects. If they have not yet adopted EnterpriseIntegration middleware, now would be a good time to do so.

Enterprise portfolios of older, custom-programmed application integration links cannot easily be wished away overnight, but shouldbe systematically replaced rather than patched when substantial upgrades are required to them or their linked applications forbusiness reasons. Over a period, consistent application of this policy would steadily reduce the legacy maintenance burden thislink portfolio represents today, and sharply cut business risks.

4. How Large is the Enterprise Integration Challenge Today?

Sizing the Enterprise Integration ChallengeSo how widespread are the needs for application integration? What is the scale of the task and challenge to integration applicationsacross business enterprises of various sizes? How do we measure the application integration task as a whole?

Three important measures that indicate the span and scale of the application integration task as a whole for an enterprise orbusiness (some already done, some still to be done) are:

The size of the existing enterprise/business application portfolio: Clearly, application integration involves linking togetherapplications, so the measure of how many applications the enterprise is using today is a good starting point. Although thereare some difficulties in defining an application, and whether all the existing applications are still of value, etc., most IT groupsrecognize and use this term. Most maintain enterprise application architecture charts that allow relatively simple determinationof the measure. The Year 2000 cleansing investments thankfully forced a considerable clear-out of obsolete applications andallowed refreshes of many of those remaining, the first compelling “clean house” in IT’s history. Cost-cutting and modernizationduring the economic downturn since then has further trimmed back the number of older, superseded applications, so theportfolios are in considerably better shape today than in 1999. New applications are, of course, continuing to be added steadily.

Number of Potential Integration Points: The most direct measure of the application integration scale and challenge then becomeshow many “integration points” do there need to be (in business logic terms)? These include both those between all the applicationswithin the internal enterprise application portfolio and those between the enterprise’s applications and those of its externalecosystem. We call this the Number of Potential Integration Points (NPIPs). In principle, software application integration links arethus needed for every required Integration Point. Clearly, many of these are implemented and running today, but many others arestill to be developed. NPIP clearly increases both with the number of applications in the firm’s application portfolio (InternalIntegration Points) and the extent and complexity of the external ecosystem the enterprise participates in (External IntegrationPoints). In most cases, far less than “any-to-any internal” and external application-to-application integration points would ever berequired, so NPIP is far lower than the number of applications. NPIPs, however, clearly increase much faster than linearly with thenumber of applications involved. Some of these integration points are commonplace and are nearly always implemented today –for example, sales and purchase ledger financial applications to general ledger. Implemented levels are much lower for newermainstream types of integration (for example, CRM to customer account applications) and fall to just a few percent in the case ofthe newest technologies driving integration, such as RFID and mobile/pervasive computing. Most fundamentally, when using theright enterprise integration middleware technology-based approach, there is no need for point-to-point direct connections betweenevery pair of applications requiring integration, as there is with custom-built links. Essentially, a single generic connector to eachapplication services all links to/from that application. The concept is analogous to the “bus” concept in computer hardware. Eachapplication (device) just connects to the integration middleware “bus”, and this bus enables any-to-any application connection. Thisdramatically reduces the number of individual links that are needed, compared to custom-built, point-to-point integration. The term“Enterprise Service Bus” (ESB) is now used to describe this key middleware integration function: we discuss the ESB architecturalpattern in Appendix B. We exclude from these numbers the packaged integration interfaces that are provided (for example, betweenthe modules of an integrated application suite) and that require little or no specific implementation work.

Number of Different IT Platforms: The wider the diversity and number of different IT platforms supporting the applicationportfolio (internal and external), the more complex, difficult and costly the implementation of application integration becomes.It is clearly easier, faster and cheaper to integrate two applications sharing the same platform than over different technologies.We have often found larger enterprises still using over 20 different platforms.

There are wide variations in these factors between different types of industry, depending on the IT histories, platform preferencesand the typical application portfolio structures that have evolved in each industry. For example, larger banks have continued theirtraditional approach of in-house application development for core systems, and their heavy use of centralized mainframe platformsin place for decades, but have added numerous other types of application and platform around these central systems.


...should ensure that they are using the much moreproductive Enterprise Integration middleware integrationapproach on all or most of their new integration projects.

In Figure 2 above, from many research sources, we have synthesized and broadly characterized the four main classes/sizes oforganization that use most of the world’s IT. The four classes are the global 500 largest enterprises; the next 10,000 largestenterprises; the next largest 250,000 substantial medium businesses, and the next largest 5M small businesses worldwide. Forthe latter we have restricted this group to those with at least 10 employees, the lower threshold for IT beyond PCs, and thusexcluding the many more millions of smaller firms.

We show broad measures of average business sizes, and the average scale of their typical IT environments, in terms of the sizeof their typical application portfolios, the number of different IT platforms they are using, and the number of IT staff for each class.So, for example, the 500 largest global enterprises, giants with revenues over $50B and usually with more than 100,0000employees, commonly have 10,000 plus IT staff and an application portfolio ranging from 400-1,000 enterprise applications. Thenext 10,000 largest enterprises typically have $1-$50B in revenues and 5,000-100,000 employees, with applications portfolios of,on average, 100-400 applications. Our “smaller businesses” class, at the other end of the scale, have revenues of up to $10M, upto 100 employees, and typically have 5-20 applications. Many IT market research studies have confirmed these broad IT marketdemographics. The information we present on the size of enterprise application portfolios and NPIP derive from reviews of typicalenterprise application portfolio maps for a selection of enterprises in each size category across industries and geographiesencountered in our analysis work, and from published work by others.

Several conclusions can be highlighted from this indicative picture:

Application Integration – Universal Need: The first and clear observation is that application integration is a universal needin every size and type of business from the largest global businesses downwards. Dependence on IT applications, and theirdiversity, has spread this need even to quite modest sizes of smaller business.

The Larger The Enterprise, The Greater the Application Integration Challenge: Our research clearly indicates that thelarger the business, the larger the application integration challenge. For example, our best estimate of NPIP for the top global500 was that on average 500-1000 significant integration points were potentially needed; for the next 10,000 largest enterprise,the NPIP average needed was 100-500, and even for the smaller businesses above, it was 10-25.

Number of IT Platforms Also Drives Enterprise Integration Cost: Using many different IT platforms adds considerably tothe cost and effort of application integration links that need to span IT platforms. Interestingly, the largest 500 global enterpriseson average have less diversity of platform (5-15), than the next 10,000 enterprises, because they have retained a morecentralized IT governance and exert stricter controls on diversity. The next 10,000 group have, on average, 8-20 platforms inuse, a result of more devolved IT governance to Line Of Business (LOB) units, and less standardization from the center. Ourclass of “medium businesses” were much less diverse, averaging 3-5 different IT platforms in use.

Smallest Businesses: The many millions of the smallest businesses (below our 10-employee threshold) typically use PCdesktop platforms (possibly networked) and integrated business application suites for their commercial applications. Thestandard external interfaces provided in these suites, plus the use of standard tools such as MS Office, plus external Webbased services (such as e-banking) suffice to meet most integration needs of this large group. They are therefore not asubstantial current market for integration middleware.


Figure 2: Application Integration Challenges by Size of Business 2005

Application Integration Challenges by Size of Business 2005

NPIP= Number of Potential Integration Points/Links

500 Largest GlobalEnterprises

Enterprise IntegrationChallenges:

400-1000 applicationsin the enterprise

5-15 types of IT platformin use

10,000 IT staff+Centralized IT strategy

10,000 Other LargeEnterprises


100-400 applicationsin the enterprise

8-20 IT platforms in use1000-5000 IT staff

Often decentralized IT

250,000 “ Medium”Businesses


25-100 applications in the business

3-5 IT platforms in use10-50 IT staff

Usually centralized IT

5M Smaller Businesses


5-20 applications in the business

1-2 IT platforms in use1-10 IT staff“ Enterprise” IT User Organisations

NPIP=100-500

NPIP= 500-1000

NPIP=5-15

NPIP= 25-100

“ SMB” IT User Organisations>$50B revenue>100,000 employees100-5000 locations

$1-50B revenue1,000-100,000employees20-1500 locations

$10M-$1B revenue<1000 employees5-100 locations

<$10M revenue20-100 employees1-20 locations

Complex Application Infrastructures – An ExampleThe complexity and scale of the application and platform landscape in larger enterprises reached high levels, largely as a result ofthe spread of the distributed computing platforms and the associated new types of applications they support, which we discussedearlier. An actual customer example encountered by this analyst sharply illustrates the scale of the typical application integrationchallenge faced by the larger enterprise.

The company was the recently-privatized national telecommunications carrier of a medium-sized European country, a substantialIT user for 30-plus years. Since privatization, the new business had come under considerable shareholder and market pressure tosharply cut costs, bring up new e-business solutions to improve customer service, and become more responsive, flexible andcompetitive in its now more dynamic and open market. Without its previous near-monopoly, telecommunication services priceswere falling fast. With over 2,000 staff, its IT operation (upon which the business was totally dependent) was substantial. This ITgroup had reviewed, mapped and inventoried the company’s enterprise applications portfolio, and found that it was operating over800 distinct applications systems, comprising over 50,000 programs, and deployed across over 20 different types of ITplatforms, sited in multiple locations across the country. The applications portfolio represented many thousands of person-yearsof development work. Most were silo/product-focused, not customer-facing, extremely complex, costly to support and maintain andrun, and left the organization with little capacity for new initiatives. Worse still, on each core business process, many differentapplication systems were involved. For example, the vital business private line provisioning process required the use of fifteendifferent applications that were poorly integrated. Therefore, many of the company’s core business processes were slow and costlyto operate, and extremely prone to human error. Basic customer data was scattered over as many as 20 different databases, builtearlier for different specific needs, often inconsistent and contradictory, which resulted in much manual reconciliation and furthererrors. After privatization, in the more fiercely competitive and open telecommunications market, this could not continue.

The seemingly obvious approach, rewriting a clean, all-new modern suite of non-overlapping applications from scratch to fully meetthe new needs, was inconceivable for a multi-$B business of this scale. It would have taken 7-10 years, many hundreds of millionsof dollars in cost, and needed tens of thousands of developer person-years, none of which were affordable. No comprehensive,standard, off-the-shelf, integrated application packages exist for this industry that could be bought and more quickly implementedto meet its overall needs, so that route was also a “non-starter”.

This company’s chosen approach was to extend and integrate the better existing application components that it had, using vendorEnterprise Integration middleware to support the new e-business solution needs quickly. It intended to rationalize and steadily de-duplicateand modernize the application portfolio by software componentization and reuse. It also sought to cut the diversity of platforms and locationsas quickly as possible, to retire the most obsolete applications whilst building new functionality only where needed for the core, streamlinedbusiness processes of greatest impact to the businesses bottom line. A large number of new integration connections were needed tosupport these changes, and many of the older existing ones already in place, were known to need replacement and modernization as well.Application integration was therefore a strategic necessity and high focus area for the IT group in this telecommunication carrier, as it setout to transform and modernize both its core business and its over-complex and aged enterprise application portfolio.

Many large enterprises reveal similar patterns, so this is far from an extreme example. This example highlights the scale of therenovation; modernization and integration challenges faced by most large and very-large enterprise IT users and the scale of theirEnterprise Integration challenge.

Our AnalysisApplication integration requirements have grown steadily since the early 1990s. In many larger enterprises, one or two hundredintegration links have often already been implemented, sometimes more. Supporting all of these links and their software, scripting,operating processes, etc., has become a considerable effort that consumes skilled developer and support resources which arebetter used on new developments. The level of support, maintenance and modification involved is often high, because suchintegration solutions are sensitive to changes or failures in the two applications at either end. Any changes to the platforms or theiroperating systems, or in the networking or middleware transport technology used to effect the link, new releases, changes inprotocols, hardware or software failures, etc., can “break” such links. These combine to create a substantial support workload onthe cumulative integration portfolio being supported.

On top of these large existing integration portfolio support efforts, many additional new integration links are still urgently needed, fuelledby regulatory compliance, On Demand business transformation, new technologies, and the other drivers shown in Figure 1, which wediscussed in Section 3. To productively tackle and implement this considerable portfolio of new integration needs, we recommendenterprises look hard at the methods, techniques, and the technologies they use for application integration. Unless they do this, theyare certain to create a further legacy burden, create inflexible and unresponsive applications environments, and condemn theirbusinesses to the penalties of insecure, fragile and far from seamless interoperation links between their changing and developingenterprise application portfolios. These are serious risks and burdens no modern business should lightly assume at a time when all arebeing asked to move faster, be more flexible, increase IT responsiveness and connect up better with their ecosystems.

As the specific example above illustrates, for almost every medium and larger enterprise, “clean sweep” complete rewriting and/orreplacement of their tangled existing applications portfolios, however theoretically appealing and desirable this may often seem tobe, is completely infeasible and uneconomic for most enterprises. This means that enterprise integration, blending many parts ofthe existing application portfolio with new components, and incrementally improving the existing applications, is really the onlyfeasible, affordable and realistic way forward for most organizations.


5. What are the Main Enterprise Integration Options Used Today?

IntroductionWe saw the scale and breadth of the today’s Enterprise Integration challenge sharply portrayed in the previous section. This highlights theimportance, investment effort, time and cost that larger enterprises in particular are facing to prioritize, develop, implement and support allthe new integration links that are now required, in addition to continuing to support all those that they have already implemented.

So how and with what technologies are companies delivering and operating application integration today? What are they using tobuild and deploy and manage all the growing number of application integration links ever more of which will be required in the moreconnected On Demand business world?

For those all who could not escape the loud software industry marketing from the many and diverse application integrationmiddleware vendors who began offering a bewildering assortment of middleware products from the early 1990s, readers could beforgiven for assuming that vendor-middleware solutions were absolutely dominant. Most analyst studies of the EnterpriseIntegration market list the main vendors, review their products, technologies and market shares, but do not cover what mostenterprises are actually doing today. Surprisingly, the reality is rather different.

So How Are Enterprises Actually Performing Application Integration Today?We decided to look more deeply at this topic, and discovered some surprising, worrying, and frankly astonishing results. Ourresearch was based upon market reviews, other published analyst studies, discussions with scores of enterprise customers,feedback from software vendors, and the particularly valuable feedback from many systems consultants conducting systemsintegration projects at enterprise customers (who are well-placed to give objective assessments). We have synthesized andsummarized this work to show the real picture of how Enterprise Integration has been performed to date.

Our findings showed that many enterprises are heavily reliant upon custom-built, in-house developed and crafted links, most using the standard,but basic, FTP technology, creating a new legacy software nightmare with ever-growing maintenance burdens, and suffering low QoS.

We identified the five broad approaches most widely used in the enterprise IT segment to perform and deliver the applicationintegrations that have been implemented to date, and these are shown in declining frequency of use order in Figure 3 below,labeled as Options # A to # E.


Figure 3: Enterprise Integration – Primary Solution Options Used Today

Enterprise Integration Primary Solution Options Used Today

Custom-Built, “ Free FTP” -basedIn-house Integration Solution

All in-house developed, supportedCustom 3GL programming, scriptingBased on “ Free FTP” file transfer SWData file movement model

Custom-Built, “ Ground up” ,In-house Integration Solution

All in-house developed, supportedCustom 3GL programming, scriptingCustom transport, integration SWVarious integration models

“ Human Middleware” TeamIntegration Solutions

Non-IT based application integrationTeam of staff perform integration manuallye.g: Manual data re-entry cross systemsData summarization, cleaning,transforming, moving done by people

Vendor Open Enterprise Integration MiddlewarePlatform-based Integration Solutions

Based on vendor open Enterprise Integrationmiddleware platformMOM and message/event broker technologyLowest integration development and support effort/costHighest QoS & securityAssured delivery, full logging, auditing, recovery

Vendor Enterprise Integration “ Enhanced FTP-based”Middleware Point Integration Solutions

Vendor enhanced FTP-based point middlewareCore FTP technology as for AVarious added-value services and product focusesSome reduction in custom development, supportversus option # A

Option # A

Option # C

Option # E

Option # B

Option # D

We explain, characterize and discuss the merits and demerits of each of these Option approaches below:

Option # A – Custom-Built, “ Free FTP” -based, In-house Integration Solutions: Much the most widely and universally usedapproach to application integration, found in use on many different integration projects in almost every enterprise ITorganization, was what we term “custom-built, free FTP-based, in-house integration solutions”.

We noted previously that FTP is the standard file transfer capability for TCP/IP networks, FTP programs are often included withoperating systems or available free from other sources. Every application integration project requires movement from out of oneapplication and into another. The typical solution of this type wraps a basic FTP operation (provided by the FTP package) in custom3GL coded integration logic, which may perform transformation, aggregation, cleansing, validation, etc., on the file contents and beof substantial complexity. In addition, a scripting layer is usually added, to manage transfer operations and provide some controlservices. These solutions can therefore be quite complex, low-level development jobs, requiring considerable development effort.The standard FTP packages used may cost little or nothing, but offer few value-added services, so this is a basic technology.Obviously, maintaining and supporting many such modules rapidly becomes burdensome as the number of them in use climbs,eating up significant skilled resources to keeping them running. Changes in any part of the environment (that often occur) impactthe code. Such changes, that occur regularly in every IT shop, include new releases or updates of the linked applicationsthemselves, changes in the compiler/programming language environments in which the applications are written, changes or newreleases in the operating systems and utilities of the platforms running the linked applications, and changes in the networkingenvironment over which the custom-built integration runs. In practice, the frequency of such changes disrupting existing custom-built integration links is high, likely to occur several times per year for each custom-built link. The amount of rework and re-testingrequired for each custom-built integration depends on the specific environmental change, but will often be considerable, and caneven be as much again as for its original creation. This makes for a high burden of maintenance and support that recurs repeatedlythroughout the life of each such integration. In many cases, failure and disruption of the custom-built integration link will be the firstsignal that changes in the environment have triggered the need for rework, resulting in poor overall service reliability and availability.These are serious, costly and intrinsic problems of this approach. We admit to being somewhat surprised and shocked that thisrather crude and basic approach is, in fact, still in such widespread use today.

This wide usage probably arose because IT developers, like any craftsmen asked to tackle a new household job, will usuallypick up and use the basic hand tools in their immediately-available toolkit (3GL, scripting, FTP packages). They use these,even when high-powered, much faster and more productive power tools which could safely do the job better and faster exist,but are not immediately to hand.

IT management should be greatly concerned at the mounting costs and effort this basic integration approach creates.

Option # B – Vendor Open Enterprise Integration Middleware Platform-based Integration Solutions: Vendor openEnterprise Integration middleware platforms started to emerge around 1990, and have matured and flourished widely eversince. These platforms provide a more robust, universal, standards-based way to integrate diverse applications and platforms.There are several layers of function that provide additional incremental value-add services, but the core technology used isMessage-Oriented Middleware (MOM). These allow loosely-coupled application integration by exchange of messages, andmessage or event brokering, and provide significant additional value-add services. Using such a middleware platform allowsmuch-reduced custom development because the platform services do more of the job. Because the middleware is vendormaintained to support advances in operating systems, databases, networks and standards, much less integration maintenanceand support is required by the customer’s team. Once a customer has acquired the relatively simple skills needed to use suchmiddleware, each successive project can be more quickly delivered, and overall support burdens are reduced. The number ofdiscreet integration links needed can also be greatly reduced by using the advanced models such middleware supports (e.g.publish-and-subscribe rather than point-to-point). The QoS of these integration solutions in production is also much higher,because of the value-added services (including assured delivery, enhanced security, logging, and workload distribution, etc.)result in more dependable integration operations in production.

The market leader in this category, by a wide margin, is IBM’s WebSphere MQ family, which provides the foundation layer forthe giant’s much broader WebSphere Business Integration suite. To more fully illustrate what a leading example of this softwarecategory offers, we provide our overview and assessment of WebSphere MQ and WBI in Appendix B on page 29.

This class of integration technology and approach is now deployed in almost 100% of the 500 largest enterprise IT users, butin barely 50% of the next 10,000 larger enterprises. Even amongst those who have adopted it, most are still using it on amodest proportion of their completed integrations, many of which pre-dated its introduction.

Option # C – Custom-built, “ Ground-up” , In-house Integration Solutions: Similar to Option A, except without the use ofFTP packages. In this approach, the “heavy lifting” of the integration is developed and supported using custom 3GLprogramming, scripting and standard interfacing facilities. The latter may include application exits and interfaces, operatingsystems services, utilities, or DB/TP system options, and techniques such as sockets programming, or the use of RPC calls.Some of these may themselves be relatively stable and established interfaces, but the overall custom-built integration solutionsuffers all the time, cost, risk, maintenance burdens and other disadvantages of Option # A without even the modest benefitsuse of an FTP engine allows.


This type of integration is also widely deployed, often predating the use of the middleware technologies cited in Options Babove and D below. Many of these have been left to running on the old IT principal of “if it ain’t broke, don’t fix it”. Reworkingold but running integration modules is clearly neither popular nor exciting. Most IT teams would far rather do more interestingnew development work, and most LOB groups are reluctant to spend money fixing “plumbing” that apparently still works.However, both are condemned by this Option to repeatedly face the need to rework and fix these links that (as we discussedabove under Option # A) are continually “broken” by normal environment changes that affect their smooth working. Given thehigh and continuing costs and effort needed to fix these custom-built links repeatedly, the business case for replacing themwith a more robust, lower-effort approach (e.g. Option # B) is actually extremely strong. We recommend enterprises plan asystematic program of replacement of such custom integration links, to drive out these wasteful and costly support efforts, andto greatly improve overall reliability and availability.

Other analysts and ourselves would firmly argue that many of these integration solutions represent a serious and costly weaklink in the applications infrastructure, and are certain to hinder the types of transformation, flexibility and QoS likely to berequired in future.

Option # D – Vendor Enterprise Integration “ Enhanced FTP-based” Middleware Point Integration Solutions: This is thesecond most widely vendor middleware-based integration solution approach in use today. A number of independent softwarevendors have developed what we term “enhanced or value-added”, but FTP-technology-based, point middleware integrationproducts. These have originated in a variety of market segments, each offering base FTP file transfer integration with differingbundles of value-added services appropriate to their market focus. Examples include products from Sterling Commerce thatgrew out of its EDI market focus, and from CommerceQuest from its B2B integration focus. For integration projects within theirtarget focus, products such as these can represent sound point solutions. They typically provide useful value-added servicesthat reduce custom development and supplement base FTP omissions, and may offer relevant standards support or interfaceswithin their sector. The better products therefore offer worthwhile benefits over the Option # A route if the requirement fallswithin their focus. However, they remain a tactical, point solution to rather specific needs rather than a broad platform, and theirsmaller vendors pose other business risks in some cases.

Option # E – “ Human Middleware” Team Integration Solutions: Amazing but true, business change consultants have oftenreported to us the discovery of whole staff departments performing what can only be described as “human middleware” roles.These groups are operating multiple IT applications, often extracting information from one and re-entering it in others, manuallymanipulating information, or providing human links in fractured business processes to bridge gaps between IT systems. Oftenlocated within LOB organizations or loosely linked to the IT group, these departments appear to have grown up as a tacticalfix to bridge important gaps in the integration of applications within these enterprises. It goes almost without saying that thesedepartments are costly, unreliable, constraining, and usually unnecessary functions, but were deemed important enough todemand such a costly manual solution. Discovering one or several such groups within your organization identifies a compellingneed and case for early application integration IT solutions that will usually show high ROI.

Application IntegrationSo with this surprising distribution of Enterprise Integrationsolution approaches in use today, what are the business impactsfor enterprises? How many integration solutions are companiescurrently supporting, and how many more are needed?

The first important point to note is that enterprises are alreadyusing considerable numbers of application integration pointsand links, and are adding many new ones to those already in

use each year under the drivers discussed previously. Our profiles, shown on in Figure 2 on page 12, found broad averages of thetotal NPIP required between applications to be:

For the largest 500 global enterprises, on average 400-1,000 integration points. Applications portfolios average 400-1000distinct systems.

For the next 10,000 global or national larger enterprise, on average 100-500 integration points. Applications portfoliosaverage 100-400 distinct systems.

For the next 250,000 medium-sized businesses, on average 25-100 integration points. Applications portfolios average 25-100 distinct systems.

For the next 5M smaller businesses worldwide, on average 5-15 integration points. Applications portfolios average 5-20distinct systems.

These results were obtained by reviewing a selection of actual enterprise application portfolios that we have seen for typical businessesin each category, and determining the number of applications in the portfolio and the number of implemented plus needed integrationlinks involved. There are wide variations in these numbers for all sizes of company depending on their industry, the complexity of theirbusiness, the evolution of their application portfolio, and on how far forward they have moved towards an On Demand business postureby rationalization and modernization. They do, however, provide a useful overall problem-sizing guide.


The first important point to note is that enterprises arealready using considerable numbers of application

integration points and links, and are adding many newones to those already in use each year...

So What is the Scale of the Application Integration Challenge?From several sources, we have estimated that the proportion of the integration links needed already implemented averages 65%of the potential links required for the largest enterprises, around 55% for the next 10,000 largest, around 45% for the next 250,000medium businesses, and some 25% for the 5M next smaller firms.

As can be seen in Figure 4, global 500 largest enterprises, for example, are on average already supporting several hundredexisting application integrations (260-650), and need to implement a few hundred (140-350) more, and so on.


Figure 4: Number of Application Integration Links Done to Date and Needed by Size of Business Estimates

Measure For the largest500 globalenterprises

For the next 10,000global or nationallarger enterprise

For the next250,000 medium-sized businesses

For the next 5Msmaller businesses

worldwide

Average Number of PotentialIntegration Points (NPIP) Needed:

400-1000 100-500 25-100 5-15

Average % of Integration PointsAlready Implemented:

65% 55% 45% 25%

Average Number of ExistingSoftware Integrations BeingSupported and Maintained:

260-650 55-275 11-45 1-4

Average Number of AdditionalIntegration Points Required to beDeveloped:

140-350 45-225 14-55 4-11

Average Number of AdditionalIntegration Points Developed PerYear (4-year horizon):

35-87 11-56 3-13 1-3

Source: © 2005 Software Strategies Estimates

These are large numbers and clearly indicate that:

The burden of continuing support, maintenance and updating on the existing portfolio of application integration links, thelevel of which depending on how they were implemented, is already considerable and is increasing steadily as additional newneeded links are implemented.

The development and implementation costs and efforts of implementing the tens or scores of additional needed links peryear (probably over a three- to five-year time-span) is a considerable annual development effort, the level of which dependson the solution approach used.

Restructuring and modernizing application portfolios, adding completely new applications, changes to the enterprise ITinfrastructure, etc., that typically occur on a regular basis in most enterprises, will clearly continue to generate additionalapplication integration link needs, or demand the rebuilding of existing ones. In addition, many of the oldest original integrationsolutions implemented earliest almost certainly need replacing by more modern and secure solutions. It therefore seems certainthat a continuing flow of integration development will be needed for the foreseeable future. Indeed, today’s emphasis on businesstransformation and modernizing core business processes is accelerating these demands.

Relative Costs/Efforts of These Application Integration OfferingsHow different are the costs and efforts between the different application integration approaches is use today? What impact dothese differences have on an enterprise’s overall development effort and costs for their existing and annual new applicationintegration link development effort?

The impact is broadly illustrated by Figure 5 on page 18, which shows the relative total costs/efforts of implementing andsupporting an increasing number of Enterprise Integration links. Clearly, Option # C (all custom in-house developed) is much themost resource- and thus cost-intensive. The most widely used Option # A is slightly better than Option # C because the use of freeFTP software packages for the transport requires less custom coding. Option # D (vendor enhanced/value-added FTP) isconsiderably better than either Options # C or # A, because the value-added software services provided in such point-middlewarefurther reduces custom development time and cost over these Options. Their limitation is that these somewhat targetedmiddleware products are not generally applicable, and can normally only be used within their design focus scope.

Vendor Enterprise Integration middleware platform-based solutions, Option # B, require much the lowest cost/effort for both initialdevelopment and deployment, and are virtually universally applicable to almost all integration project needs.

Information from enterprise developers experienced in both routes indicates that, with Option # C as the baseline, Option # A

(custom-built + free FTP) is typically 10-15% lower in effort/cost and elapsed time to value. These developers also report that

Option # B (vendor Enterprise Integration middleware platform-based) is 65-75% lower in effort/cost and elapsed time than Option

# C. Option # D (vendor-enhanced FTP) falls between these, averaging 40-45% lower effort/cost, but this gain varies widely

between specific products, depending on the strength of the value-added software services they offer.


Figure 5: Enterprise Integration Effort/Cost by Integration Approach Used

Enterprise Integration Effort/Cost by Integration Approach Used N

um

ber

of A

pp

licat

ion

Inte

gra

tio

n P

oin

tsIm

ple

men

ted

in E

nte

rpri

se

Application Integration Development, Support & Maintenance Effort/Cost

100

90

80

70

60

50

40

30

20

10

Figure 6: Relative Development Resource Costs/Efforts by Application Integration Option Used

Application Integration Approaches – Relative Development Resource Effort/Cost

Option # C Baseline Option # A Option # D Option # B

Option # C Baseline 100 Baseline 85-90 45-55 25-35

Application Integration Approaches – Multiple of Lowest Development Resource Effort/Cost

Option # B Baseline3-4

Times Higher2.4-3.6

Times Higher1.3-2.2

Times Higher1.0 Baseline

© 2005 Software Strategies

We summarize these average differences in the development resource effort/costs of implementing application integration using

the four IT-based Options considered in Figure 6. The first data row sets the least productive approach of Option # C as the

baseline of 100, and shows that of the other three Options in comparison.

Another view in the second data row takes the most productive Option # B as the baseline of 1.0, and shows how many times

more resource effort/cost the other three Options on average incur.

#B

. Usi

ngEn

terp

rise

App

licat

ion

Mid

dlew

are

# D. Using “ Value Added FTP” Solutio

ns + CustomDevelopment

# A. Using basic/free FTP Technology + Custom Development

# C. Using All Custom Development

Our AnalysisWe regard it as both surprising and somewhat shocking to find the most widely-used method of implementing applicationintegration today is the relatively basic Option # A approach of custom in-house development using a free FTP package for filetransport. These customers are, we estimate, using 2 to 4 more resources as much on integration development/support as theyneed to do, compared to adopting and using a vendor Enterprise Integration middleware platform. The significant number still usingfully custom-built, in-house solutions not even based on FTPwas also surprising. Even allowing for the software cost ofEnterprise Integration middleware, these are large differences.

A proportion of the integration portfolio is likely to have been builtsome or many years ago. Where these are not causing immediateproblems, “leave well alone” probably applies. That businessconsultants have found numerous “human middleware applicationintegration departments” almost beggars belief.

The vendor-enhanced FTP middleware-based solutions (Option # D) are mostly rather specific in their focus and scope: where therequirement matches the focus, they provide useful advantage, but cannot be universally applied. This also means that anenterprise following this route may need to acquire, learn and support several such point products, bringing further disadvantagein adding complexity, needing different skills, and license costs, etc.

The scale of application integration challenge varies with the size of the enterprise, but even medium-sized businesses havesignificant numbers of links (and need many more) and larger enterprises need hundreds. Figure 4 on page 17 gave our estimatesof these numbers. Multiplying these link estimates by any reasonable average project effort/cost estimates and average integrationmaintenance/support effort estimates clearly indicates a major IT burden.

If the advantages, both effort/cost and in terms of function and operation, of vendor Enterprise Integration middleware solutionsare so superior to the alternatives, why are they not universally used today? Do senior IT management realize the amounts ofdevelopment and maintenance effort being wasted within their organizations by the widespread use of the custom-built, in-houseapproach? The fragility and vulnerability of these links also poses significant risks to the organization using them, and we mustassume that these risks are not properly recognized. Using these approaches also creates a high dependence on the staff thatunderstand and manufactured these links; who may well now have moved on or out, leaving a “black hole” in support capability.

We delve more deeply into these issues in Section 6.

6. Vendor Enterprise Integration Middleware Platform Deployment

IntroductionAnswers to some of the questions posed by our findings can be revealed by examining how the use of the most productive andadvanced method of application integration provided by the use of vendor Enterprise Integration middleware has spread andproliferated across the market since its introduction. The depth of penetration of this technology into the customer since firstadoption is a good proxy for how valuable customers have found its benefits.

Vendor Enterprise Integration Middleware Adoption and DeploymentIn Figure 7 (on page 20) we summarize our broad estimates (derived from a number of analyst studies, vendor opinions, and other sources)of the percentage of IT user customers in each of our size groups that have adopted and installed vendor Enterprise Integration middlewareby mid-2005. We also show the percentage penetration their usage of this technology has reached out of their total integration portfolios.

We discuss and comment on each group’s figures, and our interpretation of what they mean, below.

Largest 500 Enterprises: Adoption of vendor Enterprise Integration middleware amongst this group of companies is high, withalmost 100% using the technology today. Many of these were relatively early adopters, with first introduction as far back as 1995or before. However, even in these large enterprises, many using vendor Enterprise Integration middleware for quite a number ofyears, the penetration of the use of this technology across their whole integration portfolio remains moderate at 30-45%:

N This group of global giants typically have more centralized IT organizations, with more common standards, platforms, andpolicies than the Next Largest 10,000 Global Enterprises group.

N They also typically plan and invest in strategic enterprise IT infrastructure as a foundation for their operations at anarchitectural level, and are often prepared to adopt newer technologies and make strategic investments early foradvantage.


We regard it as both surprising and somewhatshocking to find the most widely-used method ofimplementing application integration today is therelatively basic Option # A approach of custom in-house development...

N Where they select and deploy a foundation technology (like vendor Enterprise Integration middleware) that they find productive, they arethe most likely to make it an internal standard, and drive its use more systematically across new projects than less-centralized IT shops.

N This group are currently also the earliest market adopter community, advancing quickest in the new strategic software approachesof composite applications linked by Web Services standards under a Service-Oriented Architecture (SOA) approach, whichrequires a vendor Enterprise Integration middleware integration transport underpinning.


Figure 7: Application Integration – Enterprise & SMB – Vendor Enterprise Integration Middleware Adoption 2005

Application Integration – Enterprise & SMB Vendor Middleware Adoption 2005

Ven

do

r E

nte

rpri

se In

teg

rati

on

M

idd

lew

are

Ad

op

tio

n %

Size of Enterprise/Business

500 Largest GlobalEnterprises

10,000 Other LargeEnterprises

250,000 MediumBusinesses

5M SmallerBusinesses

= % of firms now using

vendor AI middleware And of these:

= % of integrations done to date

using AI vendor middleware

Next Largest 10,000 Global Enterprises: We found these results quite surprising, but the truth appears to be that less that50% of this large and important group of substantial enterprises have adopted vendor Enterprise Integration middlewareplatforms, even though the technology has been available and well-proven for over ten years now. The depth of penetrationof the technology is also significantly lower than in the group above, at an estimated 15-25%. This almost certainly reflectstheir more recent adoption, and their lower enforcement of common standard approaches to integration projects:

N This group typically has more diverse, less centralized IT governance than the global giants above, with the influence oftheir LOBs much stronger. This has led to these firms operating a wider diversity of IT platforms arising from this less-centralized control where LOBs made platform decisions in isolation.

N This group has also been less inclined (or able) to set central architectural IT standards, slower to widely adopt newfoundation technologies, and more inclined to make decisions on a project-by-project basis. The latter approach alwaysmakes it harder to justify adopting a new software platform technology for the first time, because the learning curve costsfor the whole organization must be justified by a single project.

N Whilst their typical application portfolios are somewhat smaller than the giants (100-400 systems), these are stillsubstantial, and their application integration needs are equally substantial (NPIP), so the modest adoption of vendorEnterprise Integration middleware, offering proven benefits, is puzzling.

N This group, driven by their project-by-project specific approach have, however, been the main adopters of point vendormiddleware products that seemed to fit specific project needs, but some, as a result, now find themselves with asubstantial and costly portfolio of different point middleware tools with no common synergy.

~100%

30-45%45-50%

15-25%

25%-30%

20%

30%-40%

10%

N The decentralized approach almost certainly means that decisions as to how to implement application integration are leftto the individual project technical leaders, with senior IT management exercising limited control and probably beingunaware of the routes chosen, or their longer-term implications.

N For the reasons above, we suspect many CIOs of these enterprises are unaware of how dependent they are on fragile andcostly, custom-built application integration solutions or of the jumble of point middleware solutions they have acquiredproject-by-project. This means they do not fully appreciate the excess costs and efforts, as well as the risks, theirorganizations are incurring by not using an enterprise Enterprise Integration middleware platform.

Next 250,000 Medium Businesses: About 20% of this category has now adopted vendor Enterprise Integration middleware,typically more recently than the larger enterprises. This is partly because their application portfolios and integration needs,whilst still significant, are themselves somewhat smaller. Another influence was that in the mid- to late-1990s, vendor EnterpriseIntegration middleware was mostly promoted and sold as an “enterprise-infrastructure platform” at relatively “big-ticket” costs,which many of these businesses could not afford at that time. By this decade, most vendor Enterprise Integration middlewarehad been unbundled and entry prices and options had fallen substantially (now starts a c $5,000 per platform), bringing theirbenefits well within reach of this group and allowing more incremental purchase and deployment:

N Application portfolios, and thus integration needs, are more modest in this group, although of equal relative importance totheir businesses as in larger firms.

N IT platform diversity is significantly lower than in the previous group, and more of these medium businesses retained acentralized IT governance, because they could not afford or justify the extreme diversity many larger firms allowed.

N Their smaller size and budgets prevented this group from purchasing such a diversity of point middleware solutions as theirlarger enterprise brethren, as most of these products were priced and packaged for the latter.

N With their smaller development resources, closer CIO or IT management oversight of projects, and their higher need to beproductive with limited resources, we expect this group to adopt vendor Enterprise Integration middleware much more widely overthe next decade. However, a lot of market education on the feasibility and benefit is still needed to promote and encourage this.

Next 5M Smaller Businesses: We estimate around 10% of this group have adopted vendor Enterprise Integration middleware,which has more recently come within their financial reach. This group has much smaller application portfolios, relies heavily onpackaged applications, and is most likely to use the integration options provided by their application packages and/or theirhardware/OS platform. Windows/Intel platforms predominate in this space by a wide majority; so that where vendor EnterpriseIntegration middleware has been used in these firms it is most frequently the standard Microsoft offerings that have been adopted.

Deployment Experience Indicates Faster ProliferationIt is significant that almost all the most sophisticated and largest global enterprises are already using vendor Enterprise Integrationmiddleware, and are increasing their already substantial usage more widely. They are well aware of the effort, cost and QoSbenefits of the technology, have become comfortable and skilled in its use, and are deploying it ever more frequently as newintegration projects arise. This speaks well for the benefits delivered, and now well understood by this group.

One phenomenon we have often observed in enterprises that adopt Enterprise Integration vendor middleware and are successfulwith their early projects is interesting. The team concerned often develops this specialized skill into a wider integration solutionservice or centre of expertise, which quickly attracts a queue of other internal integration projects. The higher productivity from thesoftware, combined with the growing experience and expertise of these teams enables them to deliver more rapid and more robustintegration solutions, and a respected new job discipline emerges.

For example, with IBM’s WebSphere MQ (the market leader vendor Enterprise Integration middleware foundation platform), the MQ teamoften expands its portfolio of projects rapidly in this way, as early successes make the powerful benefits clear within the organization.

This in turn leads to accelerating proliferation of the technology across the enterprise. We have always found that the few classesof software that proliferate and spread rapidly within an enterprise in this “viral” manner always offer unambiguous and powerfulbenefits that are easily and clearly seen when experienced in-house. This is clearly the case with the better vendor EnterpriseIntegration middleware platforms.

Major IT Budget Savings Available From Enterprise Integration MiddlewareGartner Group have estimated that an average of 35% of enterprise IT budgets today are spent on maintaining and supporting thecurrent portfolio of application integration links, the large majority of which remain custom-built links of Option # A or Option # Ctype. This is a dramatic and strikingly high figure. It is widely known that maintaining and supporting existing applications andinfrastructure in most enterprise IT shops consumes between 65-80% of total IT budget resources. Gartner’s figure thus impliesthat application integration maintenance and support is therefore accounting for between 54% and 44% of this high “status quo”support cost that is often preventing enterprise IT groups move forward fast enough with new business initiatives.


This means large IT budget savings can be achieved in most enterprises by switching their application integration method to the muchmore productive and lower maintenance cost Enterprise Integration middleware platform approach, the relative advantages of whichwere quantified in Section 5 above. Figure 8 below uses our earlier data and this Gartner estimate to show the typical average savingsthat full use of enterprise integration middleware platforms would provide to our three larger size groups of enterprise.


Factor Size of Enterprise

Largest 500 Enterprises

Next 10000 LargestEnterprises

Next 250,000 MediumEnterprises

Average BusinessRevenue $

$50B $5B $100M

Average IT Budget$B/M – % of Business Revenue

$2.25B4.5%

$150M3.0%

$3M3.0%

Gartner est. ofintegration supportcosts @ 35% of IT Budget

$787.5M per year $52.5M per year $1.05M per year

% of all existingintegration links notsupported withEnterprise IntegrationMiddleware(From Figure 7)

100% of firms useEnterprise Integrationmiddleware.

Average 37.5% of existingintegrations done TD useEnterprise Integrationmiddleware.

= 62.5% of all existingintegration links do not useEnterprise Integrationmiddleware across these firms.

50% of firms use EnterpriseIntegration middleware.

Average 20% of existingintegrations done TD byEnterprise Integration usersuse Enterprise Integrationmiddleware.

= 90% of all existing integrationlinks do not use EnterpriseIntegration middleware acrossthese firms.

20% of firms use EnterpriseIntegration middleware.

Average 35% of existingintegrations done TD byEnterprise Integration usersuse Enterprise Integrationmiddleware.

= 93% of all existing integrationlinks do not use EnterpriseIntegration middleware acrossthese firms.

Average IT Savings PerYear If All ExistingIntegration Links UsedEI Middleware.

2.5 times moreproductive/40% of supportcost (From Figure Y)

62.5% of links TD could betransformed

$295.3M per year each firm

13% of IT Budget saving

90% of links TD could betransformed.

$18.9M per year each firm

12.6% of IT Budget saving

93% of links TD could betransformed.

$390K per year each firm

13% of IT Budget saving

% of new IntegrationLinks Needed

35% more integration linksstill needed

45% more new integrationlinks still needed

55% move new integrationlinks still needed

Figure 8: IT Budget Savings Obtainable by Using Enterprise Integration Middleware Platforms

The table shows our best estimates of the ongoing annual support and maintenance resource savings that the average firm in

each category would realize, if all their existing application integration links were today supported by Enterprise Integration

middleware platforms, rather than the actual majority of custom-built links and minority Enterprise Integration middleware solution

mix used today. The figures are:

Largest 500 Enterprises: Savings of $295.3M per year per firm.

Next 10,000 Largest Enterprises: Savings of $18.9M per year per firm.

Next 250,000 Medium Firms: Savings of $390K per year per firm.

These savings, just on better supporting the existing application integration links portfolio, amount to an average 13% of the IT

budgets of each size of firm, a large and important saving.

Readers should also consider that many new and additional integration links still require to be built (35%, 45% and 55% more

respectively for the three size groups, we found in Figure 4). This means large further savings (an average of 60% of both the

initial development effort and the ongoing long-term support costs we found in Figure 6) can be delivered by using Enterprise

Integration middleware versus custom-built integration approaches on all or more of these.

Whilst no organization can instantly convert their large numbers of existing custom-built integration links to Enterprise Integrationmiddleware platforms overnight, our analysis shows rich long-term savings and extremely high ROIs are readily obtainable. Anaggressive program of replacement of custom integration links, combined with a policy of building all new links on EnterpriseIntegration middleware platforms, is the strategy we recommend. Consistently applied over time, the cumulative savings andreductions in on-going support and maintenance costs, as well as for new link implementation, that such a policy brings will havemajor benefits in freeing up IT budget resources from this major source of un-needed cost.

Our Analysis – Barriers to Vendor Enterprise Integration Middleware Adoption andDeploymentTo analysts such as ourselves, used to explaining middleware for over 15 years, it seems amazing that custom-built, in-housesolutions (using FTP or 100% custom) approaches to integration remain considerably the most widespread in use today.

This is even though they clearly incur higher development and support costs and effort, provide less robust and secure operationalperformance, and suffer high fragility to changes or errors in their environments. How can this be explained? Why does this remainthe case? Where does responsibility lie?

We suspect that most CIOs are probably not aware in detail of the scale of their organization’s current use of, and dependenceon, such primitive and costly links. If they were fully aware, it seems unlikely most would wish to continue this route, and manywould plan to slowly replace such weak links over time, to increase enterprise application portfolio resilience and cut costs. Itmay also be other development priorities always pre-empt improvements in elements of their portfolio that are at least working,even where less than ideal. Hidden “plumbing” tasks like these are not high profile.

Application integration efforts are often hidden within the application development or maintenance effort for the overall application,and may therefore not be visible above the project level. In this case, the full cost and effort of the integration components for allthe projects in the enterprise will also not be clearly visible, and yet may be consuming a substantial share of scarce resources.Indeed, Gartner Group has put the average cost of application integration support and maintenance at 35% of enterprise IT budgets,a staggeringly high figure that is less surprising when the scale of this activity (that we quantified in earlier Sections) is appreciated.

Where technical solution authority is devolved to the project technical lead, and no corporate standard guidance is given, it is notsurprising that many should turn, by instinct, to familiar and freely-available “hand tools”. Since they may not be responsible for theoverall lifecycle cost implications of their solution choice, they are unable to make the ROI case for the “power tool” vendorEnterprise Integration middleware-based solution. The latter will save both on the initial build cost and return many-fold more overits lifetime in lower support, but does require a software buy that may be outside the authority of such staff. We strongly recommendthat project leads for all current application integration efforts should meet or communicate regularly, to share experience and bestpractice, and combine to support the case for a common Enterprise Integration middleware platform where not yet adopted, or formore universal deployment where already installed.

In earlier years, the license cost of Enterprise Integration middleware software was certainly seen as a barrier to adoption bymany customers. This was partly because of the “big-ticket” enterprise platform bundling and high price tags prevailing at thattime, perhaps appropriate for the largest enterprises but certainly a deterrent to smaller enterprises and businesses. However,with today’s granular, incremental product packaging and lower unit price tags in this more mature market, entry price can nolonger be a real barrier, unless old false price perceptionslinger. In this regard, Microsoft has driven some pricecommoditization in this space through its high-volume,lower-cost or OS-inclusive middleware offerings, and thishas also had an influence on the market. However, as ahigh proportion of all application integration projects involvemultiple unlike hardware platforms, Microsoft’s Windows-centric solutions have had limited impact.

We also conclude that significant numbers of CIOs, CTOs,development leaders and project leaders in these yet-to-adopt enterprises must remain unaware of the compelling and substantial benefits of deploying vendor Enterprise Integrationmiddleware. This is somewhat of a paradox, because Enterprise Integration middleware was a heavily marketed categorythroughout the mid- to late-1990s, as the explosion of up to 200 vendors in the space fought to establish the market and theirpositions. This cacophony bought some hype fatigue to many IT professionals at that time. The shakeout of vendors and thebusiness downturn from 2000-2003 drastically reduced overall middleware vendor marketing. It now seems considerably moremarket education is needed outside the top 500 global enterprises to overcome this inertia, and lack of knowledge.

In our assessment, most remaining enterprise customers, and a much higher proportion of medium business should now re-evaluate the approaches they are still using for application integration, and adopt Enterprise Integration middleware platformsfor projects going forward, as well as for rewrites of older links falling due for replacement. Those who have already adopted thetechnology are advised to apply it on a higher proportion of their future projects.


We also conclude that significant numbers of CIOs,CTOs, development leaders and project leaders inthese yet-to-adopt enterprises must remain unaware ofthe compelling and substantial benefits of deployingvendor Enterprise Integration middleware.

7. Selecting the Right Enterprise Integration Middleware Platform/Vendor

Our High-level Criteria for Enterprise Integration Platform/Vendor SelectionMany software vendor/product selection guides begin with detailed product descriptions and extensive feature-function comparisons,and this remains an important aspect of any selection. The Enterprise Integration market is fast evolving and embraces a complex webof hardware platforms, operating systems, software platforms, open industry standards, and tooling requirements. Because of thesespecific Enterprise Integration characteristics, we consider that a handful of higher-level selection criteria are especially important in thissector to guide vendor candidate short-listing. Application integration solutions implemented in the enterprise with the chosen EnterpriseIntegration middleware platform will form an important part of that customer’s enterprise application environment for many years aftertheir implementation, and the business should never have to face disruptive product/vendor changes that cause rework.

Our seven, high-level, primary criteria are:

1. Product Line Track Record, Market Share, Customer Base and Reputation.

2. Vendor Financial Strength and Staying Power; Vital for Enterprise Integration Platform Customers.

3. Deep and Ongoing Vendor Support for Open Industry Standards.

4. Comprehensive Product Support for All Main Platforms, Programming Models, Integration Methods, Network andSecurity Models.

5. Closely Integrated Companion Infrastructure Platforms Available From the Same Source.

6. Modular Packaging, Incrementally Deployable, Affordable Entry Pricing But Highly Scalable.

7. Vendor Capacity to Maintain the Extensive Cross-testing and Continuous R&D Especially Needed in EnterpriseIntegration Middleware.

Why These Criteria?We explain and comment briefly why we regard these criteria as so important below:

1. Product Line Track Record, Market Share, Customer Base and Reputation: Market success, endurance, market share andcustomer base size are the acid tests of the long-term merits of an Enterprise Integration middleware platform, and high ratingsin these areas indicate a low-risk, well-proven and attractive product/vendor combination.

2. Vendor Financial Strength and Staying Power; Vital for Enterprise Integration Platform Customers: EnterpriseIntegration middleware platforms will underpin their customer’s enterprise application portfolios, integration efforts andbusiness process management developments for the next decade and more. They must therefore select an enterprise ITinfrastructure software platform whose vendor has the financial muscle to endure and support the platform long-term, to keepbringing out the technology and innovation needed, and to support a broad, multi-component product set globally. Such a viewhas long been taken when picking other foundation software vendors in categories such as database systems, applicationservers and enterprise applications, where similar considerations apply.

3. Deep and Ongoing Product/Vendor Support for Open Industry Standards: Application integration depends critically upon,and is greatly enabled by, open industry standards that facilitate interoperation and interconnection between diverse softwareassets. Therefore, it is imperative that the chosen Enterprise Integration platform supports all the key standards that interplayin Enterprise Integration, and will continue to do so as they evolve. These include networking and communications standards(TCP/IP and others), industry-standard programming models, notably J2EE™ and .NET, security (e.g. SSL), Web Services,and development tool standards (i.e. the Eclipse Platform). For their products to remain at the leading edge in open standardsmandates that the vendor is also an active leader in the standards creation and development process.

4. Comprehensive Product Support for All Main Platforms, Programming, Network and Security Models: Everyprospective Enterprise Integration customer will have a different IT infrastructure and enterprise application portfolio mix. Whenbringing in an Enterprise Integration middleware platform, it makes sense to ensure the chosen platform supports all theplatforms and types of integration “touch points” within the environment, with servers, links and robust adapters andconnectors. This is essential to minimize the need for custom development, or to add point-middleware products.

5. Closely Integrated Companion Infrastructure Platforms Available From the Same Source: Enterprise Integration is anextremely important IT infrastructure foundation technology, but not the only one required for next-generation e-business. ASSPplatforms, business integration software platforms, and systems management platforms, in particular, need to be closely coupledand tightly pre-integrated with the Enterprise Integration platform, and with each other, to provide the complete “stack” neededwithout forcing the customer to integrate the software platforms themselves. These are real advantages of selecting an EnterpriseIntegration platform whose vendor also offers and integrates these other software platforms with their Enterprise Integration offering.

6. Modular Packaging, Incrementally Deployable, Affordable Entry Pricing but Highly Scalable: In the mid-1990s, some EnterpriseIntegration middleware platforms were offered under rather monolithic, “complete package” and “big-ticket” commercial terms. Today,enterprises rightly demand more granular, incremental and affordable product packaging and licensing that allows them to build up theirEnterprise Integration infrastructure in smaller steps that align better with business benefits derived from implemented projects for fastpay-off. Entry-level versions are also desirable, for smaller businesses and proof-of-concept-type projects.


7. Vendor Capacity to Maintain the Extensive Cross-testing and Continuous R&D Especially Needed in Enterprise IntegrationMiddleware: We estimate that the testing and validation of Enterprise Integration middleware platforms absorbs 50% or more ofvendor total R&D resources, over two-and-a-half-times the software industry average of around 20%. Enterprise Integrationplatforms must provide long-term, current release support for: multiple hardware platforms and operating systems, multiple softwareplatforms and ASSPs; J2EE™ and .NET platform and Web Services levels and generations; communications protocols like TCP/IP,security standards like SSL; and popular enterprise applications. The resulting combinatorial explosion of Enterprise Integrationconfigurations, which must all be developed in parallel and be fully tested before packaging, is enormous, and demands dedicatedlaboratory resources continuously devoted to testing the advances in the Enterprise Integration platform.

Focusing on these overriding criteria will ensure that a sound shortlist can be constructed and the strongest solution selected aftera detailed technical review.

“ Enterprise Integration” Products/Vendor Candidates for Consideration

So, which possible Enterprise Integration products from which vendors should enterprises seeking to acquire the right Enterprise Integrationmiddleware platform consider for their shortlist? Our high-level criteria recommended above, and the existing IT and applicationinfrastructure will narrow the range considerably. A helpful starting point is to consider six important industry companies with strong (orsome) Enterprise Integration offerings, five of them industry majors, and one a leading pure-play Enterprise Integration vendor. Figure 9provides our cameo overviews of these six vendors from an Enterprise Integration perspective.


Candidate Strategic Enterprise Integration Platform Vendor List

VendorEnterprise IntegrationPlatform/Product

Our Cameo Enterprise Integration Overview

TIBCO Software Largest and longest established pure-play Enterprise Integration/EBI software vendor, offering extensiveEnterprise Integration middleware software platform with more recent EBI overlays. Open standards supportweak (not on Eclipse Platform, no Sun J2EE™-Certified products). Strongest base in financial services industry.

SAP AGNetWeaver

German ISV is market leader in enterprise application software with mySAP.com enterprise resource planningsuite, and NetWeaver Enterprise Integration infrastructure and integration software underpinnings. Availableon major hardware platforms, and on the IBM and Microsoft software stacks. With thousands of enterprisecustomers, “SAP-centric” organizations are widespread in manufacturing and distribution. EnterpriseIntegration offerings designed for those viewing SAP as their “centre-of-the-IT-universe”. Vendor and productssound and secure, and open standards commitment good. Now likes Linux too.

Sun MicrosystemsEnterprise Java™ System

Market third-ranking server vendor also offers Enterprise Java™ System middleware stack, used primarily on itsproprietary Solaris RISC UNIX server systems. Limited Enterprise Integration capabilities, not a main segmentplayer. Of interest mainly to Sun server-centric users. Excellent J2EE™ support as inventor/initiator, and goodgeneral open standards posture. Recent Linux adopter, but remains committed to its Solaris operating system.

Oracle CorporationUnbranded

Major # 2 database and enterprise application software vendor, now increasingly pushing its Oracledatabase-centered middleware stack, including emergent Enterprise Integration and BPM capabilities.Important force in overall IT markets, but minor player in Enterprise Integration sector to date. OracleApplications, plus recent PeopleSoft acquisition, makes stronger # 2 in enterprise applications. May becomemore important player in Enterprise Integration mid-term. Appeal to heavily “Oracle-centric” accounts. Openstandards commitments good. Likes Linux.

MicrosoftWindows 2003 ServerSystem & Services (Inc. MSMQ)

Major industry force. Offers sound Enterprise Integration portfolio within Windows 2003 Server Platform, targetedto help “Windows-centre-of-the-universe” customers integrate Windows applications to those on other platformsover .NET Web Services programming model. Market Enterprise Integration/EBI leader within the SMB segment,where Windows is the ubiquitous platform. Software runs only on Intel processor-based, distributed hardware, butcan communicate with (although not run on), UNIX, mainframe and some other platforms. Good Web Servicesstandard support, but otherwise somewhat proprietary. Dislikes Linux very much.

IBM CorporationWebSphere MQ

Industry market leader in servers, IT services, and enterprise middleware software (including database,application servers, Enterprise Integration and EBI sectors). WebSphere MQ Enterprise Integration platformlong-established leader with 10,000 customers, runs on over 35 platforms, and supports newest standardsand technologies. Deep open standards support, including J2EE™, Eclipse, Web Services connectivity andothers. WebSphere MQ tightly integrated with whole WebSphere Software Platform (ASSP and EBIplatforms). Strongest zSeries mainframe Enterprise Integration support. Likes Linux very much.

Listed in reverse alphabetical order, excludes other smaller Enterprise Integration vendors.

Figure 9: Candidate Strategic Enterprise Integration Platform Vendor List

Enterprise Integration Middleware Platform Example

To illustrate the capabilities that enterprise customers can expect to find in modern Enterprise Integration middleware platforms, wehave included in this White Paper our overview of one example. This shows what such a platform offers to provide a better approachto application integration than the (still-widespread) use of custom-built, in-house solutions. We chose the market leader in this sector– IBM’s WebSphere MQ – as a useful benchmark for readers. This overview may be found in Appendix B on page 29.

Our AnalysisThis industry has a long history of meeting new business application needs when they first emerged with entirely custom-builtsoftware applications written in the standard low-level languages and tools available at the time. If this class of application waswidespread and important enough to merit the effort, the industry has, on a number of occasions, created new middleware softwareengine technologies to help.

These each abstracted common programming tasks that originally had to be written by the developer, with the middleware enginenow providing these as services. When this occurred, the custom-programming task was simplified and reduced, the middlewareengine offered additional value-added functionality, and a more robust solution was delivered. If well conceived and implemented,these middleware engines would become widely adopted and become a standard part of the development and runtimeinfrastructure. Where business-critical applications depended on having a new middleware engine, and no commercial offeringswere readily available, some pioneering enterprise users even wrote their own middleware engines, mostly to withdraw to theircore business some years later when a robust commercial offering could be used. Notable examples include:

Transaction Processing Monitors: When the concept of OLTP was conceived, application developers building an OLTPbusiness application would have to program all the additional transaction handling logic within their application, using low-levellanguage and OS services. This common requirement spawned the TP monitor, a middleware engine that provided all thetransaction management infrastructure services needed to run an OLTP application, making it far easier to develop suchapplications, and run them more efficiently. CICS, IMS DC and Tuxedo are examples,

Database Management Systems (DBMS): Every business application program needs to be able to read and write informationto and from storage. In earlier decades, developers managed information storage and retrieval from their Assembler or 3GLprograms using the basic file systems, or access methods such as VSAM, supported on their hardware platform, which

required considerable code in the application. Databasemanagers were invented to provide a higher level ofabstraction, and more advanced high-level constructs for datamanagement that provided a higher level of informationmanagement functionality to the program. IMS, IDMS andADABAS were early examples, and today DB2, Oracle andSQL Server are the leading relational generation databasemanagers.

Few organizations would attempt to deploy significant transaction applications without using a TP monitor or a complex datamanagement application without using a DBMS. It is universally accepted that these engines greatly simplify applicationdevelopment, and provide much superior run-time execution for these tasks.

These are exact parallels with the situation with Enterprise Integration. Robust Enterprise Integration middleware has beenavailable for at least 10 years, and reached full maturity some while ago. It greatly reduces the time, effort, and cost of developingapplication integration software, and provided a richer, more secure, and better-featured run-time environment.

Therefore, why in 2005 did we find that the most widely-used approach across the market is still custom-built, in-house applicationintegration (with or without using FTP), with all the obvious disadvantages of that route?

The answer lies in the mysteries of the adoption pattern of such middleware technologies. Initially, the usually flaky new middleware“Release 1.0” is first tried by pioneering, large and rich early adopters. When refined enough for the benefits to outweigh the downsideand the usually high early prices, the middleware proliferates amongst other equally rich and sophisticated, but more cautious, adopters.Today, for example, we found 100% Enterprise Integration middleware platform adoption amongst the 500 largest global enterprises.

Over time, software prices usually fall as sales volumes rise, skills and knowledge become more widespread and accessible, and successstories become widely known. This encourages the next tier of enterprises to move through the adoption curve a few years behind thelarger group. Our finding that 50% of the next 10,000 largest enterprise users have adopted Enterprise Integration middleware platformsto date shows this segment midway through the cycle. The cycle often continues down market until the technology finally appears as PCsoftware costing $10s and affordable by single-person businesses, where this makes sense (e.g. personal database).

Risk-averse businesses also often wait until the confusion of a growth software market has settled and the number of vendors hasconsolidated to one or a few clear leaders that they can feel confident in safely choosing a partner without high vendor risk. The EnterpriseIntegration market saw a profusion of vendors emerge in the 1990s, but has now heavily consolidated and is well past this point today.


Few organizations would attempt to deploy significanttransaction applications without using a TP monitor or

a complex data management application without usinga DBMS.


In fact, the Enterprise Integration technology is also available at price points, and in appropriately-packaged, low-complexity offerings, to certainlybe affordable and manageable by every “medium” business in our category, and even by a large number of the smaller businesses group.

The main remaining barriers to adoption appear now to be lackof knowledge of the benefits, lack of experience with thetechnology, scarcity of skills, and perhaps higher IT priorities.

In the light of our findings in this White Paper, we thereforerecommend enterprise IT organizations should:

Survey and quantify their current application integrationportfolio, and the effort and resource that is actually going into its annual maintenance and support. It will be commonly foundthat this adds up to a far heavier burden than is usually assumed, and creates a call for action.

Where enterprise integration middleware has already been adopted and proven, steps should be taken to rapidly spread theskills gained, and to ensure this approach is used on many more new integration projects. An active program of rapidreplacement of older, in-place custom integration solutions is also recommended, to start cutting back on the high recurrentcosts and effort of supporting these.

Those enterprises yet to adopt enterprise integration middleware at all are now urged to do so for their next high-profileapplication integration projects, and to follow the path above when early successes have been delivered.

Enterprise application integration vendors, consultants and IT analysts can provide guidance, education and training, andaccess to references, which can accelerate the learning process.

If using external systems integrators, be clear that their business interest is in selling as many billable days as possible foreach of your integration project, and in creating a longer-term dependency on their future services for support. These interestsare diametrically opposite to yours. These firms are therefore less likely to propose the more productive and economicalenterprise integration middleware-based solutions. We recommend you make the use of your chosen standard middleware acondition of all such contracts.

In fact, the Enterprise Integration technology is alsoavailable at price points, and in appropriately-packaged,low-complexity offerings, to certainly be affordable andmanageable by every “medium” business in our category...


Appendix A: Expanding Regulatory Regimes and Compliance DemandsDrives Application Integration Workloads

Regulatory Compliance Demands Soar – Impact ITFast-increasing panoply of regulatory compliance demands, from many sources, are imposing stringent new controls and demandson enterprises in most industries and geographies. Meeting these tough new regulatory compliance mandate demands almostinvariably requires complex changes and new integration levels amongst the enterprise’s application portfolio and the ITinfrastructures that support the business. This regulatory torrent emanates from global institutions, the supra- national bodies (e.g.European Union), national governments, various standards bodies, and vertical industry regulators.

Some are well known, such as the Basel II Convention (which sets new international standards for banking operational, credit andmarket risk management) and which thus drives new IT requirements, including information availability, delivery and monitoring.This is due to be applied to banking/financial institutions worldwide from late 2006. Another is the Sarbanes-Oxley legislation in theUSA concerning the integrity of reported company financial results. There are many others applying to specific vertical industries,nations, business or professional functions (accounting, for example), and specific market places, etc.

Why This Regulatory Flood?A number of major triggers seem to have occurred in recent years, each of which has driven calls for increased regulation, andmany of these are now coming into effect. Our picture of these main regulatory regime triggers is shown in Figure A1.

Business Scandals & Frauds.Enron, Tyco, BCCI, Parmalat, EU, etc.

Director & Board Roles, Responsibilities,Independence, etc.

Business Security & Continuity Of Vital Services

Competition & Open Markets RelatedIssues. e.g Anti-cartel

Crime Detection, Prevention Issues.Anti money laundering, fraud detection

Consumer Protection Related Issues

Privacy & Data Protection Related Issues

Health & SafetyRelated Issues

Auditors & Auditing IssuesArthur Andersen, EU etc.

Social & Environmental

Figure A1: Soaring Regulation and Compliance Demands – What is Driving Them?

Soaring Regulation and Compliance Demands What’s Driving Them?

Triggers for Increasing Regulation/Compliance

Business Scandals & Frauds.Enron, Tyco, BCCI, Parmalat, EU, etc.

Director & Board Roles, Responsibilities,Independence, etc.

Business Security & Continuity of Vital Services

Competition & Open Markets RelatedIssues. e.g. Anti-cartel

Crime Detection, Prevention Issues.Anti-money-laundering, fraud detection

Consumer Protection Related Issues

Privacy & Data Protection Related Issues

Health & SafetyRelated Issues

Auditors & Auditing IssuesArthur Andersen, EU, etc.

Social & EnvironmentalResponsibilities, etc.

The many big business scandals and frauds are a major force, linked to the growing calls for better corporate governance andbetter corporate executive and board behavior. The need to ensure the integrity of company financial results by properlyaccounting for business and risk to appropriate standards is another. Market competition rules and constraints apply in manysectors to prevent monopolistic behavior and market abuse. Many key industry and public sectors can now be best described as“regulatory hotspots” where, for a variety of motives, regulation and control levels are especially high.

Many of these newer regulatory regimes impose direct and personal liability on the board of directors and senior executives, withserious sanctions for non-compliance that have got their full attention. This has pushed regulatory compliance right to the top of2005 board agendas for many firms, a priority they almost invariably reflect through to their IT teams.


IT Heavily Impacted – Demands Application Integration

These regulatory regulations each add new, and often stringent, requirements and demands upon the IT organizations of

enterprises: for example, the types of demand they are making on IT include:

Demands that enterprises can show and report complete pictures of customer histories. (Many cannot easily do.)

Anti-money-laundering regulations that demand more stringent identification and documentation of customers and the tracking

of all contacts.

Financial reporting and accounting systems that can assure full enterprise compliance with accounting and results integrity

standards.

Data retention regulations that extend the need to retain data and records, often for many years, with a retrieve-on-demand

requirement, or a full ILM implementation, needed.

More demanding regulatory reporting that requires extensive integration to assemble and combine the required information.

Extended audit trail and logging requirement, to provide extended traceability of transactions, goods, and products, etc.

Business service continuity requirements, which impose new IT resiliency and continuity levels demanding more extensive

Disaster Recovery (DR) and Business Continuance (BC) investments.

It is clearly apparent that many of these aspects of regulation-

driven IT change require or depend upon more advanced

application and systems integration, and often also on better

management and control facilities for the main business

processes that the systems are supporting.

In 2005, regulatory compliance has therefore become the most

powerful driver of new application integration needs, as well as a top priority for corporate and IT management alike. Whilst the IT

industry has responded with many new point solutions, products and regulatory compliance-related services, there are few “quick

fix”, “plug-in-a-box” solutions that can “magic away” the problem.

Appendix B: Example Vendor Enterprise Integration MiddlewarePlatform – IBM WebSphere MQ Version 6

Positioning/Introduction

Business and application integration is a central enabler of the new On Demand world. In this environment, integrating and

connecting applications securely, reliably and manageably over network connections is a universal requirement. This and other

drivers (Figure 1 and Section 3 discussed these more fully) have created widespread and expanding requirements in all larger

enterprises for many new and enhanced integration links

between applications in the enterprise application portfolio.

Vendor Enterprise Integration middleware platforms that

provide secure, reliable, easy and fast-to-implement, robust,

efficient services that enable enterprises to create, deploy,

operate and manage these integration links have therefore

become a hugely important category of middleware software in

the market. What is required of these platforms is open -

standards-based, multi-platform-based capabilities that simplify

development and provide loosely-coupled integration between

applications using messages to transfer data and actions/events between the different applications involved. The prime technology

that accomplishes this goal is MOM. In this category, IBM’s WebSphere MQ has, for over ten years, been the unambiguous world

market-leading software. It is also the foundation of IBM’s complete WebSphere Business Integration middleware suite. This family

builds out an extensive set of additional business integration capabilities and layers upon the WebSphere MQ transport foundation.

The reference architecture of WebSphere Business Integration is shown in Figure B1 (on page 30).

In 2005, regulatory compliance has therefore becomethe most powerful driver of new application integrationneeds, as well as a top priority for corporate and ITmanagement alike.

Vendor Enterprise Integration middleware platforms thatprovide secure, reliable, easy and fast-to-implement,robust, efficient services that enable enterprises tocreate, deploy, operate and manage these integrationlinks have therefore become a hugely importantcategory of middleware software in the market.


Figure B1: IBM WebSphere Integration Reference Architecture 2005

IBM WebSphere Integration Reference Architecture

Infrastructure Management Services

WBI Monitor

WebSphere BI Modeler WebSphere Studio

Business Performance Management Services

Development Services

IBM WebSphereSoftware Offerings

WBI AdaptersHATS

WebSphere II Classic

WebSphereApplication Server

Business ApplicationServices

Application &Information Assets

Connectivity ServicesWebSphere MQ Web Services Gateway WBI Event/Message Broker

WebSphere BI Server

WebSphere BI ServerFoundation

WebSphere Information Integrator

Process Services Information ServicesInteraction Services

WebSphere Portal Server

WebSphere BIConnect

PartnerServices

Enterprise Integration Platform – WebSphere MQ Foundation CapabilitiesWebSphere MQ ensures the reliable delivery of messages, including XML documents and SOAP messages, connects applications andWeb Services, spans important programming environments such as J2EE™ and Microsoft .NET, and bridges over 40 different IT platforms.

The WebSphere MQ messaging products enable application integration by helping business applications to exchange informationacross different platforms by sending and receiving data as messages. They take care of network interfaces, assure ‘once andonce only’ delivery of messages, deal with communications protocols, dynamically distribute workload across available resources,handle recovery after system problems, and help make programs portable.

Integrated support for the latest Java™ Messaging Service interface standard, JMS V1.1 – including publish-and-subscribe messaging– makes WebSphere MQ the JMS provider of choice for multi-platform environments. (withWebSphereApplicationServertheJMSproviderofchoice forJ2EE™ environments.)WebSphere MQ also provides comprehensive security options using SSL, the Internetstandard for secure communication. The standardized interfaces of WebSphere MQ also simplify the development of Application

Programming Interface (API) exits to allow monitoring andimplementation of local customer standards. The middleware alsoautomatically and dynamically distributes workloads acrossavailable server resources, and ensures that all data is deliveredfree from errors and safe from unauthorized access.

With these advanced MQ services, new application integrationneeds are much quicker and cheaper to implement, and tosupport and maintain over their lifecycle. In production they run

more reliably, efficiently and securely than any custom-built, in-house application integration solutions. This frees up enterprisedevelopment programming resources to better deploy their skills to handle essential business requirements, instead of wrestlingwith underlying network complexities.

A selection of enterprise customer and business partner cameos, outlining their experience with WebSphere MQ, are presentedin Appendix C, to illustrate the benefits found.

WebSphere MQ Product FamilyThe WebSphere MQ line now includes an extended range of versions that target specific needs. We give our overview andassessment of these offerings in Figure B2.

With these advanced MQ services, new applicationintegration needs are much quicker and cheaper to

implement, and to support and maintain over theirlifecycle.


The IBM WebSphere MQ Product Family – Our Overview

Product Version Our Overview Our Analysis

IBM WebSphere® MQExpress

WebSphere® MQ Express is a newer member ofthe family that delivers application-to-applicationconnectivity, providing both a simple solution tomid-market connectivity needs and a foundation onwhich to build and develop integration solutions.

Specifically designed, optimized, packaged and pricedfor SMBs and entry enterprise integration needs,WebSphere MQ Express minimizes the time it takes toget started by being quick and easy to install, simple touse, and fully provided with context-sensitive tutorials tohelp new users learn quickly. Provides a low-cost entry-point to the MQ family for smaller businesses.

IBM WebSphere® MQ Core flagship enterprise product of the familydelivering all the enterprise-class MQ capabilitiesdescribed above and available for all major ITplatforms. WebSphere MQ Version 6, available Q22005, is the latest and most advanced version.

Now with all ease-of-use features of MQ Express.

WebSphere MQ forz/OS®

Optimized and extended version of WebSphere MQtightly integrated with the unique capabilities ofzSeries mainframes under the flagship z/OSoperating system. Fully exploits the high integrity,reliability, availability, and serviceability techniquesof OS/390 and z/OS. WebSphere MQ for z/OSVersion 6, available Q2 2005, is the latest and mostadvanced version.

As a standalone OS/390 and z/OS™ subsystem,WebSphere MQ for z/OS provides additional systemservices that offer simple ways of passing messagesbetween programs in different OS/390 or z/OS addressspaces. This allows easy communication betweenprograms that operate under CICS/ESA®, IMS/ESA,MVS Batch, TSO, and many other platforms.

IBM WebSphere® MQExtended SecurityEdition

WebSphere® MQ Extended Security Editionexpands the security services available inWebSphere MQ and simplifies the process ofsecuring business end-to-end. This newer solutionconsolidates IBM WebSphere MQ and IBM Tivoli®

Access Manager for Business Integration (TAMBI)into a single, value-added package.

WebSphere MQ Extended Security Edition delivers allof familiar and trusted messaging infrastructure featurescustomers know from WebSphere MQ. It extends theseto enable users to implement an end-to-end,application-level data protection model and providesenterprise-wide, remote management of securitypolicies on queues. These advanced features enablecustomers to secure current production environmentswithout changing or modifying any existing WebSphereMQ applications.

WebSphere® MQEveryplace

WebSphere® MQ Everyplace connects mobile andwireless applications with the enterprise usingsecure and dependable application messaging,thereby extending application and businessintegration to mobile devices.The product enables secure, robust and dependableaccess to business-critical applications – anytime,anyplace, anywhere – over fragile networks across abroad range of platforms and devices.

WebSphere® MQ Everyplace offers:End-to-end connectivity for mobile applications.Broad mobile device support.Robust mobile integration.Extensive customization options.

The product therefore provides a sound foundation forthe expanding new class of pervasive and mobileapplications that integrate mobile workers withenterprise applications and new solutions.

IBM WebSphere®

Business IntegrationMessage Broker

WebSphere® Business Integration Message Broker(formerly known as WebSphere MQ IntegratorBroker) transforms and enriches in-flightinformation to provide a level of intermediationbetween applications that use different messagestructures and formats. IBM WebSphere BusinessIntegration Message Broker now also includes thefunctionality of IBM WebSphere BusinessIntegration Event Broker.

WebSphere® Business Integration Message Brokeradds significant value to an MQ environment bysupporting:

Enriched real-time information distribution frommultiple, disparate sources through a network ofaccess points or a centralized broker offers apowerful new way to unify organizations.Close integration with databases to performmessage logging, data merge, and databaseupdate functions.Simplifies integration of existing applications withWeb Services, by transforming and routing SOAPmessages and logging Web Services transactions.

Figure B2: The IBM WebSphere MQ Product Family – Our Overview


Enhanced Business Value in WebSphere MQ Version 6WebSphere MQ Version 6, generally available in Q2 2005, is the newest version and extends the integration platform with theadvances shown in Figure B3. These enable customers to better leverage existing investments through integration, to maximizeavailability and visibility of the MQ integration infrastructure, and to offer more responsive and efficient configuration andmanagement of this infrastructure. WebSphere MQ Version 6 provides a robust, scalable and secure integration backbone formaking wider use of application software assets and data in new e-business applications and connecting these to othercomponents in these solutions. New Eclipse open development standards-based configuration tooling makes the setup of MQeasier and faster on all platforms. Enhancements in WebSphere MQ problem determination and reporting aid and assist in theefficient management of integration services, and to more rapid issue resolution.

Figure B3: Business Value Enhancements in WebSphere MQ Version 6

WebSphere MQ Version 6

Get more from existing investments: Provides reliable integration from keyplatform resources to other applications. (e.g. CICS, IMS and DB2 on z/OS)

Easier to Configure: With new Eclipse-based configuration tools that canconnect to, and configure MQ, on all platforms including z/OS

Improved Availability: For z/OS with shared queues, support for messagesup to 100MB, and improved z/OS system configuration capabilities

Improved Problem Determination and Alerting: With extended statusinformation and support for common request

“With WebSphere MQ, we estimate it’s as much as 80 percent faster to bringnew customers online. Plus, in the WebSphere MQ environment we can makechanges quickly, without having to support such a diverse skills set. Weexpect we'll reduce our development and maintenance time 30 percent.”

Tom Kindred, Vice President, Information Technology. CUETS, Canada

Companion Products:WebSphere BusinessIntegration Message Broker

CICS BEP

WebSphere BusinessIntegration ServerFoundation

WebSphere MQ Workflow

WebSphere BusinessIntegration Monitor

WebSphere BusinessIntegration Modeler

Tivoli Access Manager forBusiness Integration

Available Q2 2005

Key features in this new Version include:

Improved Usability: Enhancements to methods in which WebSphere MQ can be configured, operated and managed,focusing on simplicity and ease-of-use.

Enhanced Management Capabilities: Improving visibility of information flowing across On Demand business by logging andoutputting additional operational data and statistics, used by WebSphere MQ tooling or other system managementapplications, to help deliver on SLA commitments.

Better Performance: Further improving on the already enterprise level of performance and scalability that WebSphere MQprovides today, and delivering higher availability and greater throughput.

Extended Connectivity: Adding new ways in which applications can be connected together making use of the strengths ofWebSphere MQ across networks.

Open Standards Support: Forefront support of key open industry standards, for example the JMS v1.1interface standard,including publish-and-subscribe messaging – making it the leading JMS provider.

Speeding Time-to-value: Enabling faster and easier deployment of new application integration links and connections, withless development efforts through standardization and tooling.

Strong Security: WebSphere MQ offers comprehensive security options using SSL; the Internet standard for secure communication.

Foundation for the Enterprise Service BusAn “Enterprise Service Bus” (ESB) is an architectural pattern that offers a flexible and consistent approach to integration. The ESBpattern is founded on and unifies message-oriented, event-driven and service-oriented approaches; the three main models ofintegration technology today. An ESB underpins a SOA and an On Demand Business™. Support for open-industry connectivitystandards (including XML, JMS, SOAP, Web Services, and more) is central to the ESB pattern. IBM has been a leading contributor tothe development of all the main open industry standards for connectivity. This ESB concept sits at the heart of the firm’s middlewarestrategy, and today all WebSphere® family products can already plug straight into an ESB pattern.


The WebSphere MQ family provides the foundation for a customer’s ESB. The ESB pattern can be implemented incrementally as newintegration needs require enhancements to the connectivity infrastructure, helping to reduce up-front investments and cut maintenanceeffort. The ESB pattern and WebSphere MQ therefore helps to optimize the delivery of information and services that improve cycle-time, reduce costs, and improve IT flexibility. It also provides transparent interoperability between the various different platforms,programming models and software architectures used in larger enterprises today. By easily enabling reuse of software assets in newways, an ESB also helps to protect and enhance the large existing investments in applications, services and skills.

Our Analysis WebSphere MQ has been the clear market-leading Enterprise Integration platform for the last ten years, and with its extendedproduct family today, now provides application integration solution enablement for businesses of all sizes. It provides the messageand event broking services, secure message transmission,QoS, and application integration management services that arerequired of an ESB, with publish-and-subscribe, assuredmessage delivery, sophisticated event handling, and broking totrigger business activities in defined circumstances as basevalue-added services. Version 6 substantially extends and strengthens this key engine that is central to application integration andindustry-wide migration to SOA-based, composite applications that reuse existing software assets combined with new componentswritten in modern languages like Java connected through Web Services standards.

Appendix C: Representative WebSphere MQ Customer Experiences

Real-world customer and partner deployment experience and results with enterprise integration middleware is perhaps the mostcompelling evidence of the benefits of this powerful technology. We include below a small selection of brief cameos of the use andbenefits found with WebSphere MQ at several leading enterprises and smaller solution providers.

WebSphere MQ has been the clear market-leadingEnterprise Integration platform for the last ten years...

Danone – Leading French/International Food Company – Enterprise Service BusIBM Business Consulting Services helped Danone design and implement an Enterprise Integration solution based onWebSphere MQ Integrator Version 2.1 (WMQI). WMQI acts as the central Enterprise Integration hub in charge of all

communication between THEMIS, hosted by IBM in Montpellier, and Danone France’s internal legacy systems. The WMQIhub connects to THEMIS through an MQ Link for R/3 connector. Danone France’s legacy systems are distributed

throughout Danone’s organization, including its headquarters in Levallois Perret, six remote plants and nine remote logisticplatforms. The WMQI hub connects to the customer’s legacy systems through WebSphere MQ Version 5.2.1 using an

asynchronous transport and file adapter. These interfaces have to be asynchronous and near real-time because availabilityis critical to Danone’s business operations, where even a 15-minute interruption could stop production lines. The EnterpriseIntegration hub is hosted on a high-availability cluster server. Additionally, a specific GUI application has been developed foractivity tracking, including auditing processed messages, recovering errors and updating routing rules. The WMQ products

provide Danone with a versatile “Enterprise Service Bus” architectural pattern for current and future integration needs.

Fortis Bank – Leading Belgian Banking Group – Application IntegrationFortis had previously used File Transfer Protocol (FTP) to exchange business data between its branches, which was

cumbersome and inefficient. This dynamic banking group needed a solution that could grow with their organization. Theyselected and deployed WebSphere MQ and WebSphere MQ Integrator to enable automated integration between their

various systems and applications, both internal and external. In particular, the solution eased integration between the banksWindows PC clients and their central z/OS mainframe systems. Fortis found the primary benefit to be greatly reduced

development time for application integration, but also valued the smoother, more resilient operational performanceachieved. All of Fortis Bank’s branches – and a total of about 6,000 employees – now rely on WebSphere MQ for

communication with the central mainframe system.

Raiffeisen Group – German Savings Banks IT Service Provider – Application Integration“Our integration solution, built on IBM middleware, has centralized securities trading and substantially improved the

integration of the distributed systems in the branches. IBM is a leader in integration, and it guarantees long-term support. Inthe world of finance, the WebSphere MQ messaging platform is the standard for integration solutions.”

Martin Frick, Head of Project and IT Architecture, Raiffeisen Group


Blue World – Secure e-Business Solutions Provider

“Our File Transfers used to take place in batches. Most of this information needs to be transformed and distributed to otherapplications and be available in near real-time. WebSphere MQ sits between our different operating platforms and enables

us to integrate applications, with WebSphere Business Integration Message Broker performing the necessary datatransformations.”

Michael Roy, President, Blue World Information Technology Inc.

About Blue World: Blue World Information Technology Inc. has been in business in the secure e-business arena for overten years, serving customers across North America from offices in Seattle, San Francisco, Los Angeles and Vancouver,Canada. The firm focuses exclusively on building secure e-business solutions based on IBM middleware and toolsets,

which support every major computing platform. Visit www.blue-world.net

Ultramatics – Enterprise Application Integrator

“We build mission-critical solutions for our customers that require robust and proven technologies as their foundation.WebSphere MQ is a solid and proven platform for building such highly reliable solutions. WebSphere MQ is a corecomponent of our integration solutions and provides reliable, scalable and heterogeneous messaging functionality.”

Saru Seshadri, President, Ultramatics, Inc.

About Ultramatics: Ultramatics has experience integrating complex large-scale applications and ensuring success. Theorganization has expertise in building robust solutions using WBI, WebSphere Commerce, WebSphere Portal, WebSphere

Application Server and other IBM products. Ultramatics is a “One Stop Shop” for IBM customers as an IBM SoftwareReseller, IBM Regional Systems Integrator and IBM Premier Level Business Partner who can bundle software and services

to serve clients better. Visit www.ultramatics.com

Digital A.V. – Integration Solution Provider

“WebSphere MQ enables us to link together systems, applications and services. It is an integral part of our overallintegration strategy within our company.”

Scott Sudman, Chief Technology Officer, Digital A.V., Inc.

About Digital A.V.: Since 1983 Digital AV has conceptualized designs and provided professional services for InformationInfrastructures. Their focus on this crucial element is so unique they named it “Infostructure”. The goal of the firm’s work has

and always will be business process improvement. Their designs stress information integration of document and datamodels, communication, collaboration and coordination, and usability, while maintaining open standards for Internet

distribution and hardware independence. Visit www.digitalav.com

Other Related Software Strategies Research1 “ IBM WebSphere Business Integration Leads the Way with Fullest J2EE™ and Eclipse Support – Business Integration

Software Swings to Open Standards” Software Strategies White Paper, 2nd Edition, September 2004, 24 p.p., 16 charts andtables. (Comparative evaluation of WebSphere Business Integration Suite & open standards.)

2. “ Enterprise Transformation, Modernization & Integration Top Priority Today – Resurgent zSeries Mainframe StakesPowerful Claim for Expanded Role” Software Strategies White Paper, September 2004, 56 p.p., 20 charts and tables.(Enterprise transformation, modernization and integration with resurgent zSeries. Software stack-centered, in-depthassessment of the mainframe as an enterprise platform as at Fall 2004.)

3. “ zSeries Mainframe Resurgence Beyond Question – Software/Costs See Major Advances: IBM Tools Break USV Grip”Software Strategies White Paper, January 2004, 50 p.p., 18 charts and tables. (zSeries resurgence and software stack assessment.)

4. “ e-business on demand™ IBM’s New “ Grand Challenge” – Re-invention to Lead On Demand Business Era” SoftwareStrategies Report, October 2003, 110 p.p., 68 charts and tables. (Strategy review.)

Software StrategiesSoftware Strategies is a specialist analyst firm focused on e-Infrastructure platform strategies and issues. Since 1997 we havepublished reports, white papers and newsletters, hosted and spoken at numerous successful industry events, and have workedclosely with industry leaders, including: IBM; Microsoft; Intel; ICL; Unisys; Computer Associates; BMC; Stratus Computers; MisysPlc; Notability Solutions; and many others.

Specialist expertise on mainframes, servers, storage, processors, Microsoft technology, Intel environments and enterprisemiddleware has been a common thread. Many thousands of enterprise IT users have benefited from our authoritative events,presentations, conferences, newsletters, white papers, and reports.

About the AuthorThis White Paper was researched and written by Ian Bramley, Managing Director of SoftwareStrategies, and was published in April 2005. The views expressed are those of Software Strategies,and are based on our proprietary research. Bramley founded Software Strategies in 1997, is anexperienced enterprise infrastructure analyst, a keynote speaker at many industry events, and haspublished many reports and papers. Before this, he served as Director of Enterprise Platforms atButler Group and was Founder/Chairman of the Enterprise NT Management Forum from 1998 to end-2000. Previously, he held a variety of executive positions with international software vendors over a25-year industry career.


Ian BramleyManaging Director – Software Strategies

[email protected]

West Linden, Wrensfield, Boxmoor, Hemel Hempstead, Herts, HP1 1RN, United Kingdom Tel: +44 (0)1442 232 505 Fax: +44 (0)1442 255 342 www.software-strategies.net

Software Strategies:

ReportModernizingApplicationIntegrationwith Service OrientedArchitecture

Abstract: Whilst investment in Application Integrationinitiatives over the last decade has undoubtedlyimproved the sharing and synchronization of information across the diverse resources of the typicalorganization, this report considers how the use of Service Oriented Architecture (SOA) enables a more agile integration approach that is more responsive to new business requirements.

Contents Page

Drivers for Change 1

The Role of SOA and Web Services 5

Infrastructure for Application Integration with SOA 8

Roadmap Planning 17

Summary 22

Independent Insight for Software Oriented Practice

Modernizing Application Integration with Service Oriented Architecture

IntroductionApplication Integration is not new. The last decade in particular has seen enormous investment in Application Integration initiatives and in the messaging infrastructure to support it. Whilst this hasundoubtedly improved the sharing and synchronization of information across the diverse resources of the typical organization, the continued pressure to optimize business processes together with the needs of the business to become more responsive to change requires a fresh look at application integration.

In this report we consider

Drivers for Change: The business and IT drivers that are driving a need to modernizeapplication integration.

The Role of SOA and Web Services: The ways in which Service Oriented Architecture (SOA)and Web Services provide a new approach for application integration.

Infrastructure for Application Integration with SOA: Takes a closer look at the infrastructurecapabilities required for taking a Service Oriented approach to integration, including the Enterprise Service Bus (ESB), and considers the role of IBM products.

Roadmap Planning: Finally, the report considers how organizations might plan the introductionof SOA based application integration, and considers the ROI.

Drivers for Change Organizations will already have many technologies available to them for Application Integration. Besidessimple file transfer approaches, there are more sophisticated solutions such as distributed computingusing remote procedure calls (RPCs) or object request brokers (ORBs). There is message-orientedmiddleware (MOM), sometimes used together with Enterprise Application Integration (EAI) products, or there are EDI and B2B Gateways used for external connectivity. However, CBDI Forum believes there are number of closely related business requirements that follow which are driving a need to re-evaluatehow these Application Integration approaches are used.

Information Visibility and Accuracy

Improving the visibility and accuracy of information is key to the organization from a number of perspectives

improving customer satisfaction – for example ensuring information on the availability of stock is accurate so that customers have confidence in placing orders that will be fulfilled in time

improving employee decision making – such as monitoring stock levels, transaction rates andbuying trends to ensure stock is replenished in time

optimizing the supply chain – ensuring that the production and distribution of goods is matched to demand

Real Time Behavior

To enable the visibility of accurate information often requires more real time behaviour in systems.Organizations may strive to become a Real Time Enterprise (RTE) where events are responded to as they happen. Acting in real time often requires the adoption of a Straight Through Processing (STP) approach to remove time wasting delays in the process. There is also little doubt that optimizing the

© CBDI Forum Limited 2005 1


enterprise's use of resources through Just In Time (JIT) approaches are beneficial to the bottom line, and JIT principle can be applied to information resources too.

Many current integration and connectivity scenarios today rely on batch processes and file transfers that inhibit real time behavior.

Process Optimization

In turn, the RTE also requires Business Process Optimization (BPO) on a broad scale. There is little point for example in implementing JIT Manufacturing if the sales order and inventory management processesare not also optimized to support the whole end-to-end process.

Moreover, few businesses are an island and they work with many partners up and down the supply chain.So BPO more often equates to Supply Chain Optimization (SCO). Ensuring real time behavior does not stop at the organizational boundary.

Increasing Demand for External Connectivity

This highlights an increasing demand for external connectivity across supply chains and ecosystemswhereby suppliers and customers can also be integrated into a seamless end-to-end business process.In parallel, the organization must consider how the real time business process will be executed by an increasingly mobile workforce, or parts of the process that are outsourced to a business partner.

Today, organizations may use different integration solutions for internal and external connectivity with a break in the flow of information. However, these are increasingly inseparable, and the need to exchangeinformation with external participants is itself driving the need for improved internal connectivity as the information may be currently dispersed across several independent silo applications.

Diversity

As well as the growing number of participants, IT is also presented with an ever expanding range of resource types in terms of devices, platforms, packaged applications and technologies that must be connected. As new types emerge, they rarely negate the need to continue addressing those already in use. It is not just diversity but also the sheer volume of terms of the number of instances that must be addressed. For example large global businesses may have literally tens of thousands of businesspartners. Integration solutions used today may be specific to narrow ranges of resource types.

Agility

Though many of the previous initiatives are focused on improving efficiency which remains a keyobjective in order to continue to manage costs, the focus of business objectives is also showing evidenceof change. Following a period of sustained cost cutting, many organizations are now looking for growth. Increased agility to drive and respond to change is seen as important in achieving this.

Agility presents one of the key drivers for modernizing integration. It is not just connectivity that is required, but the flexibility to change connections with the same efficiency and timeliness as the enterprise is now demanding in the execution of its business processes. Not only do Service Requestsneed to be routed dynamically to the appropriate resource, but the rules that govern the routing need also to be capable of being dynamically updated in response to real time changes in business conditions orservice level delivery.

However, changes to current integration solutions by developers often take an order of magnitude longerthan that required by the business process.



Governance

Increased governance and compliance is also high on the business agenda. Not only should enterprisesensure that any integration activity complies with organizational policies, they must also ensure that the execution of the composite application that results from the integration also complies with policies and regulatory requirements. Because of the real time behavior described above, aspects of this must be built into the process itself to ensure that policies are enforced at the time of execution, not after the event when it may be too late.

Organizations Large and Small

Smaller organizations do not escape these issues. Whilst it might be easier for them to exert more control over internal diversity the issues of external connectivity are largely the same. Even the smallest of organizations will find themselves having to respond to Web Services because the larger participants in their ecosystems will drive their adoption. For example, dominant retailers might force small suppliers to use Web Services to improve the flow of information so they in turn can improve the quality of informationthey provide to their own customers.

However, smaller organizations may also be under even greater cost pressure as they cannot benefit from the economies of scale, and application integration activities may appear proportionately more expensive.

A key reason for the use of Web Services given to CBDI by a number of global organizations is the ability to quickly connect large numbers of small business partners into their ecosystem to improve theresponsiveness of the supply chain, but in such a way that application integration cost is not a barrier to those partners.

Beyond Applications

Applications are not the only things that require integration. Nor is every process step going to be automated. Furthermore, there is a significant amount of information held by organizations in files that are not accessed through applications with a clean API. It might for example be held off-line, or in files maintained by end-users who cut and paste or simply re-key data into unstructured documents, yet at thesame time may be key to their daily activities and decision making, and hence the smooth running of the business.

To become a truly real time enterprise organizations need to take a more holistic view of integration that also includes human activities such as self-service, collaboration and decision making, and how theseare factored into the end-to-end business process in such a way that these manual steps in the processare also designed to achieve the same overall real time behavior. This requires for example event and notification Services that trigger these activities at the appropriate point in the process.

Evolving Integration Of course there is no shortage of integration and connectivity solutions available today as listed earlier.Many organizations will already have several. The challenge for IT is that these solutions do not alwayswork well together.



For example each integration solution might:

Use different technology, transports, and integration products.

Be proprietary or have limited platform coverage.

Require technical skills specific to the product or technology.

Create technology dependencies at either endpoint of the integration.

Moreover, current integration solutions often each span only a single part of the overall scenario. Forexample, the EAI solution used to integrate a set of internal resources, may be inappropriate for sharinginformation with external resources. As such, delivering seamless end-to-end connectivity and businessprocess automation can be complex as it requires the use of multiple integration technologies.

It is also evident that even with the Enterprise Integration Middleware available today, many organizations continue instead to use custom built integration solutions that are inflexible and cost more to implement, and are typically unsuitable for the requirements outlined earlier. A study by Software Strategies1 also estimates that up to 35% of the integration links in Fortune 500 companies are still to be addressed, rising to a massive 75% in small businesses.

Tight Coupling

Today’s integration approaches may result in tight coupling, where dependencies are created when twoor more resources are linked together by requiring either a common platform, middleware or integrationproduct. Integration solutions will also often be application specific, even down to the release level. Tight coupling is also created through the use of inflexible message formats that cannot be changed without impacting the resources that exchange the message. These factors constrain agility as the

virtualization of resources can be difficult to achieve because the resource cannot be relocatedwithout rebuilding all of its hard-wired dependencies

Ability to change resources, or use an alternative provider is reduced because of the tight coupling to the current resource and/or its technology platform.

Direct Business Impact

The bottom line is that inadequate integration prevents the organization from achieving optimizedbusiness processes and can have a direct business impact.

Consider that if a customer wants to know from a retailer the availability of a product, who in minimizingtheir own inventory has it shipped to order by an outsourced logistics company, and in turn may it also be built to order by the manufacturer, then there needs to be a very clear flow of information across that supply chain if the customer is going to be given an accurate and timely response at the point of contact.Too many of us will have experienced the annoyance of placing orders via ecommerce systems that promise “next day delivery”, only to subsequently receive an email days later apologizing for the productnot being in stock.

1 Enterprise Integration Challenge. Software Strategies, April 2005



The Role of SOA and Web Services CBDI believes that the solution to these challenges lies in the adoption of both Service OrientedArchitecture (SOA) and the use of Web Service as the basis for integration activities.

Web Services are a set of protocols that offer several advantages for use in integration scenarios;

They are based on platform independent open standards that benefit from universal support by all major vendors.

They leverage ubiquitous Internet technologies as well as other transports, and are valid for bothinternal and external usage, for the delivery of new systems and the reuse of existing assets.

Have a low entry and implementation cost plus a small technology footprint, making them attractive to all sizes of organizations, and applicable to low cost devices used in pervasive andmobile scenarios

The extensible set of protocols offers solutions for federated security, transactions, reliablemessaging and the provisioning of resource, that do not impose technology or productdependencies on endpoints – other than compliance with the protocols.

Service Oriented Architecture

Service Oriented Architecture (SOA) is an architectural style that provides a framework though which organizations describe services and their behavior, the endpoints at which they are provided, and the policies that govern their use. It is important to recognize that SOA can be applied equally when modelingthe business, designing the software to support the business, or describing the run-time deployment of the services and associated resources. As such, one of the key opportunities for SOA is to improve business and IT alignment and enhance governance across the full lifecycle.

SOA can also be seen as set of principles and practices by which organizations manage the delivery of the optimum set of Web Services from which flexible composite solutions can be assembled to best meetthe needs of the business.

Together, Web Services and SOA provide more flexible coupling of resources that in turn enablesbusiness and IT agility, and reduce the impact of change.

CBDI Forum separates the two as there is no prerequisite to use Web Services protocols to implementSOA. Other technologies (preferably also based on open standards) are also appropriate within some contexts yet still deliver similar benefits providing key principles of SOA are upheld. Conversely, neither does the use of Web Services demand the more formal architectural style of SOA – they could be used simply to get the benefits of loose platform coupling. However, the benefits can be maximized when both are used together.

SOA Provides Common Integration Framework

Most importantly in the context of the earlier discussion is that Web Services and SOA can provide a common framework for all integration and connectivity scenarios. Web Service protocols are alreadyused today to provide solutions in areas which might traditionally be thought of as EAI, B2B, DistributedComputing, Mobile Computing, and so on. Consequently, delivering a truly integrated end-to-end solutionbecomes much more straightforward.



Changing Integration LayersToday integration is performed at various layers within the IT architecture. At the technology layer integration is focused on how the operational platforms are connected and the transport technology used, for example how will a message sent from an application running on Microsoft .NET be received by J2EE? The application layer contains the applications and components deployed to the technology layer. Here integration might for example consider how information is moved from SAP ERP to Siebel CRM. This has been the main focus of much EAI activity.

The challenge at these layers is that integration efforts are often focused on connecting the specificinstances the organization is currently using, such as connecting J2EE to .NET, or SAP to Siebel. If these change then the integration must change too. Assets integrated in this way are considered tightly coupledbecause they are bound not only by the endpoints, but also by the integration approach.

The Service Layer abstracts services away from these underlying layers. Instead of considering how the process connects to SAP and Siebel, the focus shifts to connecting Orders and Customers – regardlessof the underlying applications and technology in use.

Finally, in the Business Process Layer composite application solutions are then constructed byrequesting the Services, not by directly coupling to the underlying applications and technology.

This is highlighted further when the requirement for business process optimization that spans multipleparticipants is considered. Integration is difficult to achieve using traditional approaches at the technologyand application layers because this requires common technology, or integration products are shared by all participants.

More importantly, change will happen independently within each participant. No participant will want to be constrained when making changes to their own implementations by the technology used by its partners,or the technology used for integration.

This might not have troubled larger organizations who may have justified investment in EDI for example.However, for the same reasons given earlier EDI itself must now change to provide aspects of real time behavior and to reduce the cost of implementation so that smaller organizations can also participate in anautomated supply chain process.

Separating the Service Provider and Consumer

The principal of loose coupling is that dependences between the Service Consumer or Requestor and the Service Provider are minimised to enable agility. The key benefit of loose coupling is agility. Tight coupling constrains the ability to adapt to changing business and technology requirements.

The Service Layer helps to isolate change in the providing or requesting applications. For example, the frequency of change in the business process, or the device and technology diversity used in therequesting application might be more frequent than that in the core back end systems that are used by the Service Provider.

From a technology perspective, Web Services can be a key enabler for loose coupling application links as this removes platform and middleware dependencies. The only dependency is that each endpointunderstands Web Services and can dispatch the requests to the appropriate resource. Though it shouldbe understood that Web Service protocols are not the only technology that could be used for integrationwhere the participants at each endpoint are in agreement.



The Service Layer therefore becomes the new Integration Layer. However, the design of BusinessServices must also be carefully considered. Just rendering an existing API as a Web Service is rarelyenough as

It often contains implementation specific detail or behaviour, so tight coupling still remains

Is likely to be at a granularity that is different to that required by the business process, forcing theService Consumer to make multiple requests to different Services to execute a single businessactivity

A key action therefore is aggregating and abstracting meaningful Business Services that are independentof the underlying resources, and ideally can be reused in many different business processes. To avoid re-engineering existing resources and to maintain flexibility, Business Service enablement is a new useful role for the integration layer.

IBM SOA Guidance

The application of SOA and Web Services is broader than just Application Integration. They are not just applied at the solution assembly stage of a project. The concept of SOA should be applied right acrossthe lifecycle from business planning to IT execution, in terms of identifying and managing Services as business, design and deployable assets.

Applying SOA across the lifecycle requires a consistent approach to ensure the right assets are deliveredto support the business, and where relevant they are applicable across the enterprise.

The development of SOA best practices is just emerging and CBDI Forum believes that IBM are in a strong position with the recent introduction of a number of capabilities they have refined in the field through real customer engagements. Included in this,

IBM is delivering a comprehensive approach to SOA called Service Oriented Modeling and Architecture (SOMA)

IBM Global Services also offer a number of SOA Services2 that assist organizations at each stage of the Service lifecycle.

There isn’t scope in this report to look in detail at all aspects of SOA best practice. The following box highlights some examples of guidance from IBM.

2 http://www-1.ibm.com/services/us/index.wss/it/igs/a1002583



Examples of IBM SOA Best Practice Guidance

Establish a champion or executive sponsor forSOA projects.

Divide the business into business components(cohesive activities which collaborate with other business components).

Develop a SOA strategy which defines the business context, pain point, referencearchitecture and a living roadmap for adoptionfor a lines of business and/or enterprise.

Assign service domain owners (functional,technology, application).

Implement governance mechanisms to ensure that corporate SOA/ESB strategy getsimplemented, delivered or acquired.

Extend systems development methodology to address creation of business services with corresponding design attributes for services.

Encapsulate key existing/legacy functionality, as appropriate, Take advantage of Middlewarecapabilities.

Compose atomic services into coarse-grainedbusiness services.

Build for consumability via an ESB approach; refactor services so that they are as broadlyapplicable, reusable and practical.

Use top down and bottom up analysis to createbusiness services which removes redundancyand creates opportunities for services. Themiddleware construct decision can play a major role.

Infrastructure for Application Integration with SOA With any change in approach, the first questions many organizations will ask is what impact this has on their existing infrastructure. Is it capable of supporting the new requirements or does it need to be extended or even replaced? With regard to SOA and Web Services, organizations need to consider such issues as,

What elements of their existing infrastructure need upgrading to provide explicit specific supportfor Web Service protocols

Is support for XML enough or does it need specific support for Web Service protocols

Can the same infrastructure support both internal and external Web Services

Will the infrastructure be able to support more advanced Web Service protocols that are emerging such as those for transaction, reliable messaging and business process execution

Looking at the requirements outlined earlier, it also becomes apparent that organizations will often need to address these issues on an enterprise-wide basis. For example

Coarser grained Business Services will need to be aggregated from resources that might currently be in disparate project silos

To improve governance organizations need to ensure consistency of approach, management,and security of SOA across the enterprise

Extract aspects of Service Infrastructure and Service Management from individual projects andapplications so they do not reinvent the wheel in each project, but more importantly so that they do not implement them within their application solution itself such that it constrains future agility

The Enterprise Service Bus The infrastructure layer to facilitate SOA has become commonly referred to as the Enterprise Service Bus (ESB). Today, there is no precise definition of ESB that is agreed by the industry and is most often attached as a label by vendors to a middleware product that provides varying levels of support for WebService protocols plus associated integration and connectivity technologies, for which they claim an SOA



bias. Nor is there any consensus on the functional scope of ESB, and as such the capabilities included byvendors in their ESB product set can vary widely.

CBDI prefers to consider ESB firstly as an architecture of infrastructure Services as shown in Figure 1. Once organizations have established the architecture for the ESB, then they can consider the productsand technologies that provide the capabilities required. The ESB doesn't need to be a single productthough there are other merits in dealing with a single vendor. More likely it is an architecture of Service-aware application integration, messaging and message broking, platform technologies, Service management and security products that are carefully chosen to work together.

In a federated environment you would expect each participant to have their own ESB managing incoming and outgoing Service Requests, and acting as the key infrastructure element between them and the application resources.

CBDI believes there are number of desirable characteristics that should be important when consideringESB products. The ESB should:

Not force product dependencies on any Service Endpoints.

Be the basis of an extensible framework into which other infrastructure capabilities can be plugged.

Provide support for the full range of emerging Web Service Protocols, not just SOAP and WSDL.

Be Policy and Meta-data driven. To enable easy configuration without programming, and ensurecompliance with corporate policies.

Co-exist with the existing Middleware and Application Integration infrastructure

Middleware and/or Platform Resources

Enterprise Service Bus

ManagementServices

TransportServices

SecurityServices

OrchestrationServices

TransformationServices

EAI Server,XML

Transformer,

MOM,and otherTransports

Service andSystems

Management

JCA, etc SOAP, JMS, etcSecurityServer

OrchestrationServer

WSDM

Business ServicesProvided

Orchestration Mediation ConnectivityEnablement Management

Business ServicesRequested Application Resources

ERP CRM Etc

Middleware and/or Platform Resources


ManagementServices

TransportServices

SecurityServices

OrchestrationServices

TransformationServices

EAI Server,XML

Transformer,

MOM,and otherTransports

Service andSystems

Management

JCA, etc SOAP, JMS, etcSecurityServer

OrchestrationServer

WSDM

Business ServicesProvided

Orchestration Mediation ConnectivityEnablement Management

Business ServicesRequested Application Resources

ERP CRM Etc

Figure 1 - The Enterprise Service Bus



Anatomy of an Enterprise Service Bus What the above suggests is that there isn’t a minimum or maximum set of capabilities that scope the ESB. As stated, it should be seen as an architectural pattern, into which any number of Infrastructurecapabilities could be plugged. Having said that, it is worth examining the main functionality that might be expected to form an ESB and also comment on the relationship of the ESB to other middleware as illustrated in Figure 1.

Many of the following functions will sound familiar. After all, similar capabilities are built into EAI, MOM and other existing application integration and middleware solutions. The key difference is that now the functions must be “service aware”. For example,

Service Mediation

o Deal with abstract endpoints, rather than fixed binding to absolute addresses. Thisenables dynamic routing and broking

o Within the constraints of security policies, be able to examine Service Messages to make content based decisions for routing, transformation, etc.

o Enable aggregation and composition of new Business Services from other Services.Including the augmentation and enrichment of message contents by reference to other Services.

Service and Process Orchestration

o Orchestration of multiple Business Services

o Management of events that trigger Service activities

Service Creation and Enablement

o Creation of new Business Services from existing resources and their APIs.

Service Security

o Federated authentication of Service Providers and Requestors.

o Encryption of Service Messages

Table 1 lists the common functions of an ESB together with relevant protocol standards. It also shows relationships to existing application integration products and technologies that might be expected to play a role in implementing these functions.

Many organizations will of course need to integrate non service-based resources as many existingsystems and files will not support Web Services or will have APIs that are inappropriate to be consideredservice-based. Even where the Application Server or container in which they are hosted supports WebServices, the resources will often not have been updates to use these and the maintenance effort and testing to do this may not be easily justified.

Therefore, the ESB architecture should include the ability to access these resources, and where appropriate could be used as the Service Creation and Enablement layer so that the resources can be included in an SOA without incurring the development cost of upgrading the resource itself. The Service Enablement functions included in Table 1 could be used to wrap the existing resources with Web Serviceprotocols, but equally to transform them to other technologies such as MOM or an ORB that could be used in a Service Oriented manner. As such existing EAI products that include the adaptors for countlessexisting applications and file formats can still play a useful role within the ESB.



Functional Area Functions Relevant Protocols andStandards

Relationships

Service Mediation Broking

Routing

Transformation

Aggregation andComposition

WS-Addressing

XSLT

MOM

EAI

Service and ProcessOrchestration

Process Execution

Event Management

BPEL

WS-Coordination

Workflow

Service Enablement Wrapping

Protocol conversion

Transformation

Access non servicebased resources

BPEL

WSDL

EAI

Application Server

Development Tools

Service Connectivity Transport

Assured Delivery

Protocol Conversion

SOAP

JMS

WS-ReliableMessaging

WS-Coordination

MOM

Distributed ComputingTechnology (e.g. ORB)

Table 1 – Common Enterprise Service Bus Functions and Infrastructure Relationships

IBM ESB Capabilities

To support these requirements, IBM provides a comprehensive suite of products as listed in Table 2. To ensure cohesion, there is a single Eclipse-based console with common tooling for management and configuration across the ESB.

Functional Area IBM Products

Service Mediation WebSphere Business Integration Event/Message Broker

WebSphere MQ

Service and ProcessOrchestration

WebSphere Event/Message Broker

BPEL support

o WebSphere Business Integration Modeler

o WebSphere MQ Workflow

Service Enablement WebSphere Business Integration Adaptors

WebSphere Application Server

Service Connectivity WebSphere MQ

Table 2 - IBM Products for ESB



HR Legacy

Finance

ERP CRM . . .

WebSphere BusinessIntegration Adapters


Interfaces: JMS, SOAP, MQI, mMS, JAX RPC, RMI

WebSphere Application WebSphere MQServer V6

WebSphereEvent / Message

Broker


Broker

Web ServicesGatewayWAS ND


HR Legacy

Finance

ERP CRM . . .






Broker


Broker



HR Legacy

Finance

ERP CRM . . .






Broker


Broker



Figure 2 - IBM Products for ESB (source IBM)

As illustrated in Figure 2, the recently announced Version 6 of WebSphere MQ provides the foundation of the ESB.

WebSphere Business Integration Event/Message Broker provides message transformation and databaseintegration, content and topic-based routing capabilities, plus message filtering and messagewarehousing. It also provides event Services including publish and subscribe, with support for numeroustransport protocols.

The Web Services Gateway, available as an integrated component within WAS ND (WebSphereApplication Server Network Deployment), provides a single point of control for access, validation and filtering of web services requests, helping to ensure the security of external Web Services.

Service Management Some ESB products include elements of Service Management. Though this might be thought of as a separate infrastructure domain, the drivers outlined earlier require Service Integration and ServiceManagement to work closely together to deliver a more dynamic environment where decisions such as Service Routing can be made in real time based on Service Management feedback.

In the Service Management domain we can consider the following service aware activities listed in Table 3 that are related to application integration.

Service Management - Enabling Service Mediation decisions to be made on the basis of Serviceavailability and performance

o Manage Services and Service Messages as resources in their own right, not just the other resources which form part of their implementation (and which might be sharedacross many services)

o Management of Service Level Agreements, and monitoring compliance

o Provisioning of Services and associated resources



Business Performance Management - Enabling Service Mediation decisions to be made on thebasis of the performance of business activities

o Business Services at the right level of granularity and abstraction can enable monitoringof business level activities.

Participation Management - Enabling Service Mediation decisions to be made on the basis of the type of participant and their access levels.

o Managing access to Services, which may extend down to the operation, or messagecontent level

o Managing Service Level Agreements at a per Service/Participant level

o Managing commercial aspects of Service usage where appropriate, such as metered(per request) billing, or mediation based on commercial contracts

Service Security – Ensuring federated security across a end-to-end integration scenario

o Closely related to Participation Management are the security functions to identify and authenticate participants.

Functional Area Functions Relevant Protocols and Standards

Relationships

Service Management Service Monitoring

Service LevelAgreementCompliance

Provisioning ServiceResources

WSDM

WS-Policy

WS-RF

SystemsManagement

Web ServiceManagement

Business PerformanceManagement

Business ActivityMonitoring (BAM)

Business Intelligence

ParticipationManagement

SLA Management

Usage Contracts

Commercial

Service Security Authentication

Encryption

WS-Policy

WS-Security

Directory

Security/Identity

Table 3 - Service Management Functions and Integration

IBM Service Management Capabilities

IBM products that support service management in the context of Application Integration are shown in Table 4.



Functional Area IBM Products

Service Management IBM Tivoli Monitoring for Transaction Performance 5.3

Tivoli Monitoring for Web Services

WebSphere 6.0

Business PerformanceManagement

Websphere Business Integration Modeler/Monitor

ParticipationManagement

Web Services Gateway provides filtering and security

WebSphere Business Integration Connect

Tivoli Federated Identity Manager

Service Security WebSphere 6.0

Tivoli Access Manager for e-Business 5.1

Tivoli Federated Identity Manager

Table 4 - IBM Products for Application Integration Service Management

Business Integration Reference Model

IT Service Management


Access Services

Connectivity Services (ESB)

Business Innovation & Optimization Services

Interaction ServicesBrings together people,Brings together people,

functions, and functions, and information intoinformation into

a single integrateda single integratedexperienceexperience

Process ServicesDistributeDistribute

execution of businessexecution of businessprocesses anywhereprocesses anywhere

in the networkin the network

Information ServicesMake data implementationsMake data implementations

and legacy applicationsand legacy applicationsinto more flexibleinto more flexible

participants in businessparticipants in businessprocessesprocesses

Partner ServicesConnect trading &Connect trading & business partnersbusiness partnerselectronically in electronically in

endend--toto--end processesend processes

Business AppServices

Support modern,Support modern,standardsstandards--basedbasedintegration bothintegration both

internally & externallyinternally & externally

Develop new businessDevelop new businesslogic with fewerlogic with fewer

dependencies on thedependencies on theunderlying platformunderlying platform

IT Service Management


Access Services

Connectivity Services (ESB)

Business Innovation & Optimization Services

Interaction ServicesBrings together people,Brings together people,

functions, and functions, and information intoinformation into

a single integrateda single integratedexperienceexperience

Process ServicesDistributeDistribute

execution of businessexecution of businessprocesses anywhereprocesses anywhere

in the networkin the network

Information ServicesMake data implementationsMake data implementations

and legacy applicationsand legacy applicationsinto more flexibleinto more flexible

participants in businessparticipants in businessprocessesprocesses

Partner ServicesConnect trading &Connect trading & business partnersbusiness partnerselectronically in electronically in

endend--toto--end processesend processes

Business AppServices

Support modern,Support modern,standardsstandards--basedbasedintegration bothintegration both

internally & externallyinternally & externally

Develop new businessDevelop new businesslogic with fewerlogic with fewer

dependencies on thedependencies on theunderlying platformunderlying platform

Figure 3 - IBM Business Integration Reference Model (source IBM)

These IBM capabilities sit within a broader Business Integration Reference Model illustrated in Figure 3. This model addresses many of the requirements outlined in the first section of this report recognizing the



need to include people, partners and processes as well as application resources in the broader scope of integration.

It is beyond the scope of this paper to detail each service domain shown. However this model illustrates a key role of the ESB – to move information to where it is needed, when it is needed.

Service Oriented Infrastructure The previous sections outline the infrastructure for application integration that needs to be made “ServiceAware”. That is, it must support the delivery and the runtime execution of Business Services that are partof an SOA and facilitate the message passing within the business solutions that are integrated or assembled from the Services within that architecture.

This is not the same as the application integration infrastructure itself being Service Oriented – i.e. the middleware itself exposes a set of Infrastructure Services, which exhibit the same principles such asloose coupling as are demanded of the Business Services they support. As shown in Figure 1, the middleware and infrastructure resources ideally expose their own set of Services that form the ESB.

The importance of this is two-fold. Firstly, it means that the infrastructure itself can be virtualized andfederated in the same way as application resources can via SOA. Secondly it provides an important mechanism by which existing infrastructure resources can be reused in an ESB – again in the same waythat existing application resources can be reused in an SOA.

Table 1 and Table 3 highlight the relevance of existing application integration capabilities. Many organizations will have significant investment in relevant products and the solutions they have built with them. Ideally, they are not usually looking to replace this infrastructure, at least in the short term. More likely they are looking for ways in which they can extend it to support new requirements. Key to this will be vendors adding Service interfaces to their existing infrastructure products where relevant so that they can not only be configured through a standard UI and tool framework such as Eclipse, but alsoprogrammatically configured through Web Service interfaces.

Today, application integration infrastructure products such as IBM WebSphere support Java basedinterfaces such as Java Messaging Service (JMS) and Java Connector Architecture (JCA) that enable WebSphere products to be configured and extended in a standard way. Increasingly in future CBDI Forum also expects to see standardized Web Service protocol based Infrastructure Services emerging, such as WSDM (Distributed Management) that provides a mechanism by which federated Systems Management tools and platforms can share information and expose management functions – the key benefit being that Web Services do not impose a Java or other dependency on the infrastructureendpoints.

Service Governance Governance can be seen from many perspectives. SOA both requires governance, and can help deliver improved governance. Table 5 illustrates some SOA governance requirements and correspondingimprovements



Governance Requirements Governance Improvements

Governance of the Service development process is required to ensure that the right Services are delivered to support the business, and the deployed Service is a correct implementation of requirements

Well designed meaningful Business Servicesenables monitoring of business level activity

Governance of Service execution is required to ensure that policies are effective

Flexible policy compliance can be built into Service execution to ensure changes in compliance are implemented immediately

Table 5 - SOA Governance Requirements and Improvements

Figure 4 illustrates how the proper application of SOA can enable full lifecycle governance. The ESB can play a central role in this by

Managing flexible policy deployment

Run-time Service Monitoring to check policy compliance, and provide audit trails

System and Service monitoring

Facilitating feedback loops to systems management for resource optimization

Facilitating feedback loops to the business for process optimization

Service Lifecycle M

etaData

BusinessModel

SoftwareModel

ServiceModel

ServiceProvisioning

ServiceManagement

EnterpriseService Bus

BusinessServices

SoftwareServices

Run-TimeServices

BusinessActivityMonitoring

Run-TimeServiceMonitoring

Operating

PlatformSystemMonitoring Autonomic

Optimization

BusinessServiceOptimization Model Based

Transformation

PolicyDriven

Service Lifecycle M

etaData

BusinessModel

SoftwareModel

ServiceModel

ServiceProvisioning

ServiceManagement


BusinessServices

SoftwareServices

Run-TimeServices

BusinessActivityMonitoring

Run-TimeServiceMonitoring

Operating

PlatformSystemMonitoring Autonomic

Optimization

BusinessServiceOptimization Model Based

Transformation

PolicyDriven

Figure 4 - Improving Service Governance



Roadmap Planning Acquiring or upgrading the full range of infrastructure capabilities required for SOA is not something that organizations need to address via a “big bang” approach. Instead organizations should:

Grow the capability in line with their actual need and the SOA scenarios in use. E.g. they have no need to worry about managing external participants if the Services are only used internally

Implement capabilities in line with their level of maturity, as indicated in Figure 5

Expect to reuse existing infrastructure capability where applicable

To facilitate this CBDI Forum recommend the use of a roadmap planning approach, which is a useful device to coordinate many activities that are often widely dispersed in terms of time, geography and accountability. CBDI Forum suggests a roadmap framework such as that illustrated in Figure 5 which canbe used to plan the introduction and rollout of SOA and Web Services. The y axis provides a structure for thinking about timing and interdependency which are simply clustering mechanisms, which specificallyremove any organizational relevance. We refer to these as streams.

The x axis then represents stages of maturity:

Early learning is undertaken in a deliberately uncoordinated manner, with the minimum of formality.

The integration phase then requires certain matters to be managed in order to achieve sensiblelevels of consistency, which will hopefully reduce overall cost to the organization as well as establish common foundations for matters such as classification, core infrastructure services etc.

The reengineering phase is then focused on creating enterprise level services and platforms

Maturity is all about convergence of the IT Services and the business products and processes.

Early Learning Integration Reengineering Maturity

Plan &Manage

Infrastructure

Architecture

Process

Projects

Development and coordination of common policies and practices

Cluster of topics and deliverables to establish new infrastructure for SOA

Establishing enterprise architecture and frameworks

Establishing the Service Oriented delivery process for the Service Lifecycle

Recommended project profiles and patterns

Early Learning Integration Reengineering Maturity

Plan &Manage

Infrastructure

Architecture

Process

Projects

Development and coordination of common policies and practices

Cluster of topics and deliverables to establish new infrastructure for SOA

Establishing enterprise architecture and frameworks

Establishing the Service Oriented delivery process for the Service Lifecycle

Recommended project profiles and patterns

Figure 5 - CBDI Forum Roadmap Planning Framework

For each stream, organizations then consider what state the organization should be in according to industry benchmarks and its own goals, and then plot the activities required to move from one level of maturity to the next.

We highlight a broad view of Roadmap planning in this paper because modernizing the integration infrastructure to support SOA is not going to be something that happens in isolation. Rather it is one



stream in a parallel set of activities designed to move the whole organization forward into SOA and enabling a more responsive business and IT environment.

Core to the success of introducing a significant new approach such as SOA is dealing with the potentialorganizational impact. For example managing responsibility for the delivery of new Business Servicesthat might cut across existing projects that are currently responsible for silo application resources.

IBM Business Integration Adoption Model To assist organizations in planning their SOA roadmap, IBM have recently introduced a BusinessIntegration Adoption model. Table 6, illustrates the business and IT drivers for each of the adoption levels in the model. The value in this model is that it enables organizations to frame their new and existingprojects within the context of their business integration and SOA vision.

Adoption Level Business Domain IT Domain

Connect: Assure reliable andflexible information flow betweendiverse applications & systems

Guarantee transactions

Integrate partners

Streamline processes

Verifiable, reliableinformation exchange

Secure application access

Reduced integration costs

Integrate: An integration framework that supports interoperability among heterogeneous environment – removing barriers to building an integrated architecture powered by web services and non-web servicesapplications and integrationapproaches

Rapid offeringintroduction (e.g., onlineretail lending)

Expedited paymentsexception resolution

Web access to coresystems

Technology standards as abusiness enabler

Reduced IT complexity & headcount

Reusable IT systems &data

Automate: The orchestration of business and IT processes to align IT with the business goals to growrevenue while containing costs.

Regulatory change

Post-merger integrationof firms

Automation of loan origination process

Reduce processinefficiencies

Scale to meet increaseddemand

Optimize: A holistic approach to transform and manage a businessby aligning strategic and operationalobjectives with business activitiesand supporting IT services

Differentiated service

Managed risk & liquidity

Automated, informedprocesses

Asset control & alignment

Greater performancevisibility

Optimized resources

Table 6 - Levels of Adoption - IBM Business Integration Adoption Model

So that organizations can take stock of where they are in terms of adoption and the types of activity they might consider in order to achieve their vision, IBM has also introduced a SOA Self Assessment Service3.This is an online diagnostic, co-developed with IBM Global Services SOA Center of Excellence in which organizations answer questions about practices in key SOA categories of process, architecture,application, and infrastructure.

3 http://www.ibm.com/websphere/soa_assessment



From this, the assessment service generates a custom report that is mapped to the Business Integration Model and illustrates to organizations:

Their level of SOA sophistication described in clear, straight-forward terms

The benefits and advantages that are already attainable with their existing integration infrastructure and current SOA readiness

Some of the benefits they can expect in the future as they evolve their integration capabilities andservice-orientation

Recommendations for achieving greater business flexibility through improved SOA readiness

Application Integration Infrastructure Roadmap Against the backdrop of adoption levels, organizations need to make the choices as outlined in Table 6 for the modernization of each component of the Application Integration infrastructure.

Table 7 - Application Integration Infrastructure Roadmap Actions

A basic high level roadmap for the project tasked with modernizing the Application Integration infrastructure project would be

Action Requirement Example

Retain Can continue to play role in SOA as is MOM

Upgrade Must be upgraded by vendor to make Service aware

Message Broker

Extend Modules or components that compliment or plug in to existing capability to add SOA capability

Service Management extensionsto Systems Management

Replace Infrastructure cannot be made Service aware Products no longer supported by vendors

Acquire New functionality that does not existing incurrent infrastructure

BPEL Orchestration Engine

Retire Redundant infrastructure no longer required Products superseded by new SOA infrastructure

Identify infrastructure roadmap actions as outlined in Table 7 to provide support for

o Web Services – identify the steps to upgrade to support both basic and emergingadvanced protocols.

o SOA – in terms of how the infrastructure helps in better abstracting the business serviceaway from the back end resources. For example, can the infrastructure products such asthe ESB provide mediation capabilities that removing the need for low-level developmentwork, and improve loose coupling?

o Service Management – assess whether upgrades to existing Systems Management tools are appropriate, or do new Service Management products need to be acquired.



Consider the upgrade approach. For example, is the infrastructure upgraded in stages in linewith roadmap planning? Is it upgraded in step with emerging needs and the evolution of Web Service protocols? This should be balanced against the potential benefits of investing in aninfrastructure component that perhaps meets current and emerging needs in one investment.

Assess the organization impacts, for example understanding the different responsibilities of the individual projects vs. central IT. Clarify which of them are responsible for putting which pieces of the Application Integration infrastructure in place

Build the ROI case and acquire funding for infrastructure upgrades where required

Establish applicable enterprise wide policies for Services, such as SLA and security.

Service Based Application Integration ROISome of the general measures by which the ROI on modernizing application integration can be ascertained are listed in Table 7. Some of these will be straightforward to derive from IT costs andsavings such as the cost of software upgrades or reduction in developer effort. Others might require morecomplex measurement of business performance. Some business benefits may be hard to generalize in the overall ROI as they are situation specific, however they will still factor in building the ROI case for the individual solution projects and justification for using a Service Oriented integration approach.

The study by Software Strategies referenced earlier concluded that around 13% of the IT budget could be saved each year through the use of Enterprise Integration Middleware such as IBM WebSpherecompared to alternative approaches that rely mainly on custom built solutions that are developed andmaintained in-house.

CBDI Forum believes that this saving could be further improved though the adoption of an SOA approachfor the reasons outlined in Table 8 and elsewhere in this paper, whilst at the same time enabling a more agile integration environment that delivers further savings over time by removing the need to constantlyre-build integrations because of business and IT change.

IBM customers already provide evidence that these benefits can be achieved. For example

Xerox required an ESB to provide agile integration in line with industry standards. They are usingWebSphere MQ, WBI Message Broker and WebSphere Application Server to process over 2 million messages a month linking 50 applications and have achieved greater than 99.9% availability. They have seen a reduction in TCO due to the reuse of standardized interfaces,loose coupling of resources, and the ability to reuse existing resources. This has delivered a reduction in the time to implement changes by 75%.

Travelex, one of the biggest names in the global foreign exchange market has seen an 85percent reduction in the time required for customer processing of foreign exchange transactionsby implementing a Straight Through Processing approach using WebSphere BusinessIntegration to connect their front and back end systems. Furthermore, the consolidation of application infrastructure is expected to reduce application support costs by 20%4.

4 http://www-306.ibm.com/software/success/cssdb.nsf/CS/JSTS-64MQR2?OpenDocument&Site=wssoftware



Business Value

Reduction to business process execution time and introduction of real-time behavior.

Ease of integration makes it attractive to new partners and customers.

Availability of Web Services enables new channels and business models

IT Value

Reduced TCO

Lower development through consistent programming model exposed by infrastructure services.

Lower developer training costs with a single consistent approach for all integration scenarios.

Reuse of ESB and infrastructure across the enterprise, rather than re-invention in each project.

A fully service aware ESB can also facilitate resource virtualization to reduce the cost of IT operations.

Reduction in Time to Solution

Common framework, based on open standards means connections can be quickly established.

Reduction in Time to Change

Policy driven approaches enable rules to be quickly effective across all relevant integrations withouthaving to adjust each one individually

Provide certain levels of autonomic behavior to enable systems to respond automatically to changes.

Improved Governance

The use of an ESB to ensure consistency of service provision and service management across the enterprise.

Active WSM and SLA monitoring will reduces cost of problem resolution, and avoid penalty payments for non-compliance with SLA.

Business Activity Monitoring can be used to improve business awareness of the state processes andactivities – so they can avoid business process problems – not just system problems.

Policy driven approach enables corporate policies to be quickly effect

IT Cost

Development

Understanding domain wide requirements, and designing Business Services that could be reusedacross the domain will initially cost more than Business Services that are based solely on the needs of the specific project. This can be clawed back through reuse.

Infrastructure

Upgrades may be required to the existing application integration infrastructure to support SOA

There may be acquisition and implementation costs for new components

There will be rollout and training in SOA approach

Table 8 - The Value and Costs of Service Oriented Application Integration



Asset Modernization Organizations typically have a high expectation that they will reuse existing application assets in new SOA scenarios. One of the basic principles of SOA is that loose coupling should enable existing implementations to continue operating behind a new Service façade, and a key role of the ESB is Service enablement as listed earlier.

Using IBM WebSphere as the basis for an ESB therefore enables it to play a dual role in providingService Mediation together with Service Enablement thanks to a rich palette of adaptors for bothpackaged applications and multiple technologies that provide access to existing resources.

However, organizations must also consider that existing applications as they are implemented today may not always be ideal for the new agile, on demand scenarios they intend to deliver. For example the process embedded in the application might run contra to the behavior of the new scenario, or the internaldependencies within the application and with other applications might create unwelcome Servicedependencies that negate some benefits of loose coupling.

The modernization of existing assets is beyond the scope of this report. However, we suggest that organizations initiate a modernization roadmap for these assets in parallel to their infrastructure roadmapoutlined above. In many cases new interfaces will be sufficient, but in others some reengineering may be required.

SummaryIt is difficult to see how the behavior outlined at the beginning of this report can be delivered withoutmodernizing application integration. SOA provides the approach, and Web Services the means by whichthis can be achieved.

However, keeping pace with changing requirements is never easy. The current transition to SOA and the use of Web Services places added pressure on maintaining the infrastructure because it presents a shift in approach, not just new technology. It is much easier to add Web Service capability to the infrastructurewhen it is supported by a vendor such as IBM who is leading the development and standardization of Web Service protocols and is able to provide implementations at the earliest opportunity.

IBM’s ESB provides a blend of innovative technology and products whilst at the same time continuing to provide support for existing customers and giving them a clear path towards enabling a more responsiveorganization with SOA. This approach minimizes investment by facilitating the reuse of both existing application assets and the integration infrastructure already in place. For example: An applicationimplemented using J2EE components may be plugged into the ESB using advanced Web Serviceprotocols such as WS-ReliableMessaging or through a Java Message Service (JMS) interface using a MessageDrivenBean. Similarly a Microsoft .NET application can participate in the SOA by using the same Web Service protocols, or both could leverage IBM WebSphere MQ as a common MOM transport layer in the ESB if that was already in place. Meanwhile, in another part of an organization, applications that perform nightly batch processing based on the bulk dump, load, and transfer of data may now connect to the ESB using an FTP or file based interface, and take advantage of the ESB’s mediation capabilities to break up the bulk data into its individual parts for consumption and use by other endpointson the ESB. This can be accomplished by using open standards based middleware and services.



Delivering the behavior outlined in this report requires an enterprise-wide response to integration if the requirements are to be met. End-to-end business process optimization is difficult to achieve whilst silo projects continue to use incompatible technologies and approaches. At the same time, SOA and Web Services provides a mechanism by which individual projects can still focus on their specific requirementsand leverage whatever technology they feel is appropriate to their solution as long as they commit to using the ESB as the common integration backplane. As such CBDI Forum emphasis the need for roadmap planning to move the whole organization forward in a consistent manner.

Author: Lawrence Wilkes, CBDI Forum - [email protected]

This report was commissioned by IBM Inc.

Links

IBM WebSphere Business Integration:

http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=products/businessint

IBM SOA and Web Services

http://www-306.ibm.com/software/solutions/webservices/

IBM SOA Self Assessment

http://www.ibm.com/websphere/soa_assessment

CBDI Web Services and SOA Roadmap:

http://roadmap.cbdiforum.com


Independent Insight for Software Oriented Practice

CBDI Raison d’etre

We aim to provide unique insight on component and service orientedtechnologies and processes for the software industry and its customers. Toprovide high quality analysis and other information resources on best practice in business software creation, reuse and management. Tomaintain the highest level of independence.

Modus OperandiThe CBDi Forum has a number of channels:

Subscription services – provision of continuous commentary andinformation.

Workshops and seminars – providing indepth briefing andguidance on advanced architectures, processes and practices.

Consulting – including related product management andmarketing advice, application audit and guidance, technical and business evaluation for investment

How we compare with others

We are not a mass market, media oriented organization. All materialpublished by the forum is unique. The majority of material is published byour own analysts, or commissioned from others, and under strict editorialcontrol to ensure accuracy. We rigorously exclude spurious marketing.

We provide depth insight which covers a narrow topic footprint in a deeperway than the other analysts, and in particular cover not just the technology,but also the architectures, usage, practices and processes.

Also we are unusual as analysts; we do not simply echo what the vendorssay, we are a think tank, identifying new ideas, opportunities and providingstimulus for thinking. We are thought leaders providing ideas generationand a rich source of conceptual thinking based on practical, real worldfeedback.

Who Reads the CBDI Journal

Technical leaders including Technical and Application Architects, BusinessAnalysts, Consultants, CTO’s, Designers, Product Strategists, Senior Developers, Project Managers, CIO’s etc. Subscription is split roughly 40%USA and 50% Europe.

Contact Us

For further information on any of our services contact us at: [email protected] or +353 28 38073 (international)

IMPORTANT NOTICE: The information available in CBDI publications andservices, irrespective of delivery channel or media is given in good faith and is believed to be reliable. CBDI Forum Limited expressly excludes anyrepresentation or warranty (express or implied) about the suitability ofmaterials for any particular purpose and excludes to the fullest extentpossible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognised and acknowledged

Subscribe to the CBDI Forum

The CBDI Journal is published

monthly. In addition to the

Journal, subscription includes

electronic access to current and

all back numbers that now

represent a significant resource

library. There are individual and

corporate subscription schemes.

Corporate subscription includes

access to Powerpoint libraries

and our workshop materials.

For more details and to

subscribe see:

www.cbdiforum.com

W ebSphere

Total Cost of Ownership W orkshop

Introduction

Since 1999 IBM has conducted m ore than 300

detailed W ebSphere Total Cost of Ownership

(TCO) Assessm ents using a com prehensive

m ethodology and financialm odel that com pares

alternative im plem entation scenarios over a 5-

year period.

W e offer this TCO assessm ent workshop to

custom ers who are actively considering a

business integration or business process

m anagem ent software investm ent.

W orkshop Activities

The workshop runs three to five days at your

location working with your IT and business

process subject m atter experts to com plete our

TCO assessm ent m odel.

During the workshop we:

Review your existing IT architecture and

integration infrastructure

Identify the required services for application

integration and business process

m anagem ent

Group and rank services by com plexity to

estim ate design, build and unit test costs

Identify reusable com ponents and services

Estim ate fixed and variable costs and key

cost drivers

Evaluate and com pare alternatives that drive

cash flows

Develop a high-level solution architecture

Deliver a five-year cash flow m odel and

TCO business case

Benefits

IBM ’s TCO Assessm ent captures detailed costs

in a flexible and proven m odel that allows you to

effectively evaluate m ultiple alternatives thereby

enabling you to have m ore confidence in both

planning and decision m aking.

Key benefits of the workshop include:

Developm ent of a business case for

integration and process im provem ent

tuned to your business priorities to support

project funding and budgeting

An im proved understanding of various

reusable com ponents and their im pact on

short- and long-term costs

Com panion W orkshops

Process Im provem ent W orkshop— uses

W ebSphere Business Integration M odeler

to m odel and com pare existing and

im proved business processes

Integration Architecture W orkshop—

refines the solution architecture and

identifies required software

Integration Center of Excellence

W orkshop— show you how to drive results

through effective governance and

perform ance m easures

Contacts

Contact your local IBM representative or e-

m ail: IBM Value@ us.ibm .com

IBM Leads the Industry

IBM ’s Total Cost of Ownership (TCO)

assessm ents have consistently dem onstrated

that the W ebSphere portfolio delivers the

lowest TCO in the industry. This is a direct

result of advanced tooling and a services-

oriented architecture designed to facilitate

reuse. Com ponent reuse across the industry

leading standards-based W ebSphere/Rational

portfolio not only effectively reduces

developm ent and deploym ent cycle tim es but

also reduces the costs associated with

m aintaining the environm ent over tim e.

W e invite and encourage you to take

advantage of this unique opportunity and

schedule a Total Cost of Ownership (TCO)

Assessm ent W orkshop.

BUSINESS INSIGHTS September 2006

Contacts:

Clive LongbottomQuocirca Ltd Tel +44 118 948 [email protected]

Elaine AxbyQuocirca Ltd Tel +44 20 8874 [email protected]

Connectivity and SOA Embracing Old Assets, Furthering the New

Executive SummaryService Oriented Architectures (SOAs) will provide greater flexibility for

those utilising them, but will also bring greater issues for data and functionalconnectivity. This paper contrasts and compares the capabilities of a point-

to-point and an enterprise service bus approach.

Main Findings Current trends in technology are leading to applicationdecompositionAs adoption of Web Services increases, traditional applications (e.g. ERP, CRM) are being seen as too siloed in their approach to the businessneeds.The move to SOA will drive connectivity needsThe move to a more services-led approach will drive the need for theadaptors at an exponential rate. With services providing discrete functions,a single process may well involve the need for hundreds of these tointeroperate and exchange data to facilitate the process needs.Organisations need to look at outwards connectivity“Value chains”, where processes include suppliers and customers, canprovide distinct market differentiation where process connectivity is usedsuccessfully.“Point-to-point” solutions will rapidly become unusable“Point-to-point” connectivity solutions require adaptors at the rate of thenumber of data stores/end points squared plus 1 (n²+1), whereas a bus-based approach only requires one adaptor per data store/end points (n). This means that managing a point-to-point architecture will rapidly becomeinfeasible.Contextuality of data connectivity is keyTo maintain business and technical flexibility, data mapping and transformations need to be carried out by adaptors associated with thedata store/end point, and abstraction needs to be provided by a busarchitecture.Bus architectures cut down on the need for management andmaintenanceThe intelligent abstraction of connectivity means that fewer adaptors needto be managed and maintained, enabling organisations to invest more ITbudget in facilitating the business, rather than spending on fire-fighting andmaintenance.

ConclusionSOA will provide greater flexibility for organisations looking to automate andfacilitate dynamic processes both within their own organisation and betweenthemselves and their suppliers and customers. However, connectivity within anSOA is a major problem, and must be addressed at an early stage. The use of abus architecture provides a high level of abstraction and minimises the number ofadaptors required, while data transformation and intelligent data mapping helps tolower the time spent on retro-testing and maintenance costs.

An independent report by Quocirca Ltd.

www.quocirca.com

Commissioned by IBM

www.quocirca.com

1 SOA – Breaking Down the Barriers A Service Oriented Architecture (SOA) brings a new approach to IT functionality within anorganisation. Whereas old approaches had to come from a starting point of an applicationproviding the total solution to specific problems, the idea behind SOA is to provide a far moreflexible system, based on discrete pieces of functionality being called as required from anybusiness function to facilitate specific business requirements.

This approach has many benefits – for example, functional redundancy, where multipleapplications carry out the same function within their own domain, is minimised, and theoptimisation of any function provided in this way is immediately applied to all processes thatuse that function. The removal of functional redundancy also means that less hardware is required to run the function – no discrete resource is required for each of application a, b, c and d’s version of the function; instead, the single instance of the function can be sized tomeet the composite requirements of the multiple processes that will be calling this function.

Also, SOA can provide a much greater level of flexibility when it comes to resource utilisation.With average hardware utilisation running around 10-15% in a standard client/server or monolithic web-based application environment, SOA can provide the means to up utilisationto 60% + through the use of virtualisation and dynamic provisioning of functions.

2 The Real Business Starting Point With all the benefits around SOAs, it feels as if SOA should have replaced existingarchitectures already and that old-style, monolithic applications should be ripped out to be replaced with new Web Services-base composite applications built from disparate functionalcomponents. As we all know, this is far from the reality, and ongoing business pressures willstop all but the very brave (or foolish) from carrying out a full “rip and replace” approach in theimplementation of SOAs.

The main problem is that heavy financial and resource investments have been made inexisting systems – and these systems were implemented for all the right reasons whenclient/server and application centric models were accepted as the norm.

Even solutions sourced in the past couple of years will not be fully SOA-enabled – themajority of applications that have been built to Web Services standards will still be monolithicin approach, and will contain all the functionality required to carry out the set of solutions that the owning vendor is trying to solve. With hard-coded internal connections between functionsbeing replaced with tightly coupled Web Service-based connections, the end users are oftenlittle better off than before.

So, the real business problem is the perennial one of how to get to the future from thepresent; how to ensure that existing investments are protected while being embraced andsuitably utilised by the new approach to business-centric computing.

3 The Need for Connectivity Existing applications tend to have been architected to deal with vertical needs – ERP systemsdeal with specific areas of inventory, business asset management and so on, while CRMsystems deal with customer issues. The expansion of the specific Enterprise ResourcePlanning (ERP), Customer Relationship Management (CRM) and Supply Chain Management(SCM) vendors into a greater range of coverage to try and tie in their own customers to asingle vendor solution has forced the vendors into creating connectivity solutions into theiroverall portfolios to enable their disparate offerings, often built up through mergers andacquisitions, to interact with each other. In many cases, this interaction is carried out throughhard coding of discrete adaptors from one part of the solution to the other. In other cases, the vendor will create more “open” connectivity for data exchange using technologies such as theeXtensible Markup Language (XML) for data formatting.

September 2006 Connectivity and SOA 2© Quocirca Ltd 2006 http://www.quocirca.com

www.quocirca.com

The biggest problems come when we look at the more heterogeneous environments, whichmay also include the need to connect mainframe and other computing environments into thedistributed SOA environment. Here, with less abstraction between the application and the runtime environment, hard coded connectivity tends not to work for long, and semi-proprietaryapproaches to “open” XML are little better.

For many organisations looking to implement SOA, connectivity will be one of the biggestissues. Getting application A and application B to interact has always been a problem, andwhole markets have grown up around this – indeed, the term “Systems Integrator” came fromthe provision of help to link disparate systems and solutions together. In the 1990s, manyvendors came to market with Enterprise Application Integration (EAI) solutions, again as ameans of creating a more closely integrated set of solutions that would help an organisationbe more flexible in its chosen market. The biggest problem has been standards, and a lack ofadherence to them – applications were coded in specific languages, using proprietary meansof dealing with internal events and data structures. The “easiest” way to enable interactionwas often through tapping in to the back end data store – and this immediately lost anybusiness context, and increased the complexity of maintenance.

For many organisations, web services are now being adopted. However, in many cases, thisadoption is being done on a project-by-project basis through the use of distinct web service toweb service adaptors, so replacing one set of hard-coded connectivity with another. It isQuocirca’s belief that this direct Web Service to Web Service connectivity is not the real way forwards. Through the use of abstraction, Quocirca believes that a much greater degree ofongoing flexibility can be obtained within an SOA, and that businesses will gain the capabilityto more closely focus on their core competencies, knowing that the infrastructure will be flexible enough to support the changing business needs.

4 Abstraction and Connectivity For a truly flexible SOA environment, it is necessary to remove the dependence of onefunction directly to another.

“Main”App

Secondary Apps

Peripheral Apps

Figure 1


www.quocirca.com

If we look at figure 1, we see the problems with an application centric view of the world whenit comes to connectivity. This figure only shows a partial map of the possible connections,showing what may be the currently utilised connections. Any actions that take place purelywithin the main application will have no problems, and any actions that involve connectivity to “preferred” external applications will generally have defined adaptors provided by one or otherof the application vendors. However, once we move through to non-preferred applications, orapplications that are more than once removed from the main application, we may well comeup against problems. To gain connectivity, we may have to use one of the secondaryapplications as a route to the peripheral application, or adaptors may only be provided by thirdparties and may need changing when either of the applications dependent on the adaptor areupdated or patched. The costs of testing all such adaptors after every patch and upgrade canbe horrendous, and the application topology can become extremely complex as the numberof applications and connections increases. If new connectivity is required between twoapplications, we are looking at two new adaptors.

However, if we take an Enterprise Service Bus (ESB) approach as in Figure 2, we raise the level of abstraction to make it that any adaptor is only dependent on a single application,rather than paired between connected application instances. The use of an ESB means thatall applications can be treated as peers, and each adaptor only has to deal with a singleapplication, as the ESB itself deals with one end of the adaptor. This lends extra flexibility –any application can change without impacting any other application – if the change to theapplication requires a change to the adaptor, this can be easily applied, and retro-testingbecomes far easier and more rapid.

Peripheral App 1

Peripheral App 2

Secondary App 1

Main App

Secondary App 2

Peripheral App 3


Figure 2

Finally, we need to look at the emergence of SOA as a force in the market. If we look atFigure 3, we see that an SOA has to be dealt with in a way that is very similar to anapplication-centric ESB. The main difference here is in the number of items that the ESB has to deal with – the decomposition of applications into services as part of an SOA requires farmore connectivity to be provided, and requires greater flexibility, greater scalability and reliability. If you try to imagine this being dealt with through a direct application connectivityapproach, the number of dependent adaptors rapidly becomes unmanageable, and theamount of network “chat” could well become appreciable, slowing down overall response.


www.quocirca.com


Services

Services

Figure 3

Historically, the main reason why an ESB approach has not been viable has been that each application vendor has worked to their own set of proprietary “standards”, and as suchadaptors have had to be hand-crafted and maintained at high cost. We are now at a positionwhere standards have emerged that are reasonably well adopted and adhered to by the majority of vendors. J2EE and .NET are the main architectures of choice, and Web Servicesare rapidly emerging as the main means of making functionality visible to the external world.Even for older applications that do not directly support Web Services and for applicationsoutside of the main distributed environment, tooling is available to uncover functional parts of the overall application to make the function available to other parts of the infrastructure. The need for optimisation of existing investments in applications leads to the need to connect all applications to an ESB, and not just new web services enabled applications. This recognitionis leading to an extension in ESB capabilities for projects requiring this capability, with off-the-shelf adaptors through to specific functionality in the more widespread enterprise applications,enabling these functions to be exposed as web services to the rest of the environment.

Through the use of an ESB, SOA becomes a more achievable aim. Whereas manyorganisations have been put off from moving to SOA due to a (misplaced) perception as a “ripand replace” project, an ESB combined with suitable tooling enables companies to maintainexisting investments while implementing new functionality as discrete services.

5 Contextuality and Data AbstractionMaintaining the context of data within connectivity is key. Tapping into data stores at the database level is relatively simple, but maintaining and understanding data maps along aconnectivity chain is not. Direct, point-to-point data maps breed a high degree of extraadaptors, and any change to a data store (e.g. the addition of a new column or field) mayresult in the need for changes to all adaptors associated with that data store. Commonlyknown as an “n² + 1” issue, the number of direct adaptors where contextuality is not maintained grows at the square of the number of data stores/end points, plus 1 – for example,full connectivity for a solution involving 5 data stores/end points would require 26 discreteadaptors.

With a bus style approach, full contextuality can be more easily maintained through the bus.Intelligence built in to the adaptors provides the capability to transform data from the


www.quocirca.com

underlying data stores so that data maps can be initially inferred and then rapidly checkedmanually for veracity and altered as required. These data maps can then more easily bemaintained, as the connection points are then only between the one end point/data sourceand the bus. A change in one data store will therefore only have a direct impact on theadaptor associated with it – other adaptors will maintain the data context through theirassociation with the ESB. This then means that full connectivity for a solution involving 5 data stores/end points would only require 5 adaptors (an “n” approach – the need for aqaptorsgrows linearly with the data stores/end points themselves). This also leads to greaterflexibility, and in the capacity for functional reuse of specific service components through theadaptor itself – a key requirement for SOA.

If we scale this to a more complex environment, involving, say, 100 data stores/end points,full connectivity in an ESB environment with data maps and transformations being dealt with by the adaptors requires 100 discrete adaptors for complete interoperability of data across thewhole system. Compare this to a direct point-to-point solution – there would be a requirementfor 10,001 adaptors – a completely unmanageable solution. Even assuming that the majorityof these connectors would not be required (that is, many data stores/end points do not havethe necessity to interoperate), we would need to go down to a 1% overall connectivity to getdown to the simplicity of an ESB approach. In the case of such a point-to-point environment,Quocirca finds that connectivity is therefore only provided where absolutely necessary,minimising flexibility and constraining the organisation’s capabilities in the market.

Now move this through to an SOA – we may have tens of thousands of discrete services,each requiring their own connectivity solution so that they can be utilised as start points,through points and end points within the changing needs of business processes. A directpoint-to-point solution means that even in an environment where we minimise overallconnectivity we will be looking at hundreds of thousands to millions of adaptors – with any change to a single service possibly impacting thousands of other adaptors. Even if you havea relatively simple system at the moment, the continuing move to SOA should make it thatensuring that you have the required flexibility for the future will mean that any new applications or functionality should be implemented utilising the connectivity capabilitiesprovided by the use of an ESB.

5.1 Generic Object Database and Common Data Definitions

As we move forwards, the need for a common data definition become more important. Evenwith an ESB approach, we still run into an overall information visibility issue. One data sourcemay well have a customer field marked as “Customer”, whereas another may have it as “Client”. Solutions that are attempting to provide a “one true source” still have dependenceson being able to request the information from the adaptor in a manner that is standardisedand common across the whole organisation.

Once way around this is to centralise the data definitions, via a generic object database.Here, a secondary map of the information held within the adaptors is created, showing howthe different data sources’ fields map on to each other. Through this means, any request for information can then be made using a common definition – a Customer information requestcan always refer to a common data definition of “Customer” – the generic object databasethen handles any translation that are required in talking to any of the dependent adaptors.

A high-level example is shown in Figure 4. Here, we have many different services, many of which have their own different definition of a customer – “Customer”, “Client”, “AccountName”, “Cust”, “Contact” and so on. For any requesting service that requires all the knowninformation about a specific customer, specific requests would have to be written tointerrogate each separate service if we were to utilise either a point-to-point or a single-connector ESB solution. However, by creating a single generic object database, the mappingof each of these different definitions is already known. Therefore, we can interrogate the generic object database through a single definition (in this case, “Customer”), and the genericdefinition then decomposes into the specific definitions as required.


www.quocirca.com


Services

Services

Generic Object Database

“Customer”

“Client”

“Contact”

“Account Name”

“Cust”

“Customer”

Figure 4

Although this requires more work up front in carrying out dual data mapping (one for theadaptor and one for the generic object database), the flexibility provided becomes a majorfacilitator for market differentiation.

6 Flexibility of connectivity and Value Chains Another area that is often overlooked when organisations look at connectivity is the growth ofinter-organisational data exchanges. More often than not, an organisation looks only withinits own four walls, neglecting to look to the massive efficiency and effectiveness gains thatcan be made through the use of connectivity along the value chain.

If we look at a simple value chain, we have a supplier, ourselves and a customer. We canwork along this chain as three separate, isolated processes, with each participant lookingafter their own responsibilities. However, if the customer requests information about thedelivery of the end item, for example, this request has to be taken from their solution, passedto our organisation in isolation, and we then have to contact the supplier and find out the status of the delivery to us. With no integration along the chain, we have the probability oferrors creeping in to the accuracy of the informational exchanges, as well as the time elementof the manual steps.

Now let us suppose that we integrate these processes. If we do this through “hard”connectivity (application to application), we become highly dependent on the status of theapplications within each of the constituents within the chain. Should one of the constituentschange an application, we can no longer be sure that the overall data flows will still work. Previous research by Quocirca has shown that the majority of companies have severalthousand suppliers and customers – and managing such a complex connectivity environmentbecomes impossible. Once we start looking at the use of services, we have a massiveincrease in the possible problem – rather than silos of application that we need to connect, wenow have decomposed services that need to be rapidly aggregated to create the facilitation for the required processes – and hard connectivity just does not allow for this.

Here again, the ESB provides the capability for the required flexibility. Internally, services areconnected via the ESB, and external connections are also included. As before, as the ESBprovides one end of the connectivity, and changes with services within the other components


www.quocirca.com

of the value chain can be more easily dealt with through changing the ESB adaptor, ratherthan trying to deal with service-to-service adaptors and the need for dependency checkingthroughout the whole system.

7 What to look for in Connectivity solutions When looking for solutions offering the best flexibility for connectivity in an SOA architecture,there are several things that should be considered.

Connectivity – Obvious, but important. Check to see what adaptors are available outof the box, and what the level of support for non-standard adaptors via the channel is, to ensure all parts of the business can benefit from enhanced connectivity.Standards – With standards now maturing rapidly, full support for evolving standardssuch as Web Services and XML alongside support for older standards is key.Interoperability – Wherever possible, the chosen solution must be able to understandthe applications that it connects to. With this capability, process flows are maintainedin context, retro-testing is minimised and flexibility is maximised.Scalability – The specific needs of a service oriented architecture means that many more calls will be made on adaptors. Therefore, the scalability of the chosen solutionwill need to cope not only with the immediate need, but also with the future need asexisting silo applications are decomposed to services.Flexibility – How can new adaptors be added and how are existing adaptorsupgraded?Manageability – Your SOA environment will be dependent on connectivity: without it,no composite application or process will be able to work. Therefore, it is imperativethat the connectivity solution is fully manageable, preferably through a centralisedsystems management solution. Alerts, automated actions, root cause identificationand the remote management should be available in the chosen solution.Resilience – It is important to ensure that the chosen SOA connectivity solution has inbuilt capabilities for failover, and for roll-back and resume should anything happenin any dependent services or applications. In these cases, the adaptor will have to bethe point of intelligence as to what steps will need to be taken. Future directions – is the vendor supportive of providing functionality such as ageneric object database? Does the vendor have a story for a move through to a fully utility style computing environment, such as Grid and Software as a Service? How does the vendor view value chain connectivity and the associated issues such asdata protection and data fidelity?

8 Customer ExampleGROHE is a company providing water fittings for bathrooms and kitchens. Headquartered inGermany, this 5,600 employee company has 20 subsidiaries and 12 sales offices across 130countries. Annual sales in 2005 were € 865m ($1.1bn).

8.1 Customer’s business issue

GROHE was implementing a new SAP enterprise resource planning system, and needed tofigure out how to exchange data between this new SAP implementation and existing legacyapplications that were crucial to the company’s business. These included duty and plantapplications and delivery, invoice and product catalogue systems, as well as bar coding,logistics and inventory management software.

GROHE was also up against tight timescales – the company needed the SAP system to beup and running, complete with data connectivity, within 2 months.


www.quocirca.com

8.2 Customer’s approach to solving business issue

In total, GROHE identified 14 interfaces that would need to be created to integrate olderapplications with the newer SAP modules. As the project had to be completed quickly,GROHE needed to determine whether it was more cost-effective to perform hand-coded,point-to-point integration or purchase a packaged solution designed for speedy integrationand continued consistency of business processes.

GROHE’s software manager, Armin von Dolenga, compared the time, cost and effort thatwould be needed to manually program 14 SAP interfaces, and then compared this to anapproach utilising an Enterprise Service Bus approach. Von Dolenga calculated that it wouldhave taken 6 months to hand-code the required connectors, and rapidly decided that an SOA approach based around an ESB would be the only viable way forwards.

SerCon, an IBM company, was chosen as the partner to design and implement an SOA for GROHE using IBM’s WebSphere family of products to provide the needed ESB.

8.3 Customer’s perceived benefits from implemented solution

The IBM WebSphere ESB implementation now handles between 5,000 and 25,000 messages per day, enabling full data transformation and providing a global exchange of information witha string of services between decoupled front and back ends.

This SOA incorporates standardized interfaces that use common message formats such asXML and SAP Intermediate Documents, so GROHE is ensured that its business services canremain stable and well-defined, yet easy to change in order to meet the fluctuating needs ofthe business. Because of this building-block approach, von Dolenga estimates that his ITgroup can bring a new service online within two to four weeks.

The new WebSphere software-based solution significantly reduces the time and cost requiredto integrate older applications with the new SAP modules compared to a hand-coded, point-to-point integration technique. By enabling reuse of existing resources with an openstandards-based solution, GROHE is preserving its investment in its existing assets.

Von Dolenga says that the solution has not only allowed him to standardise the SAP and database interfaces, but also to service-enable GROHE’s legacy systems, so facilitating future business integration projects.

9 Conclusion Connectivity within and across organisations is a problem that will only get worse in thefuture. Not only are companies looking to the use of application integration to provide greaterflexibility within existing solutions, but the increased move to Service Oriented Architectures means that connectivity requirements will grow exponentially. Point-to-point solutions willincreasingly become unsupportable, and those organisations using such solutions will spendincreasing amounts of money and time in retro-testing adaptors and processes every timethat a single service changes. However, for those who choose an Enterprise Service Bussolution, such retro-testing will be minimised – enabling the organisation to invest IT budget innew functionality and to be more responsive to the markets’ needs.


www.quocirca.com

About Quocirca Quocirca is a company that carries out world-wide perceptional research and analysis covering thebusiness impact of information technology and communications (ITC). Its analyst team is made up ofreal-world practitioners with first hand experience of ITC delivery who continuously research and trackthe industry in the following key areas:

Business Process Evolution and EnablementEnterprise Applications and IntegrationCommunications, Collaboration and MobilityInfrastructure and IT Systems ManagementUtility Computing and Delivery of IT as a Service IT Delivery Channels and PracticesIT Investment Activity, Behaviour and PlanningPublic sector technology adoption and issues

Through researching perceptions, Quocirca uncovers the real hurdles to technology adoption – thepersonal and political aspects of a company’s environment and the pressures of the need for demonstrable business value in any implementation. This capability to uncover and report back on theend-user perceptions in the market enables Quocirca to advise on the realities of technology adoption,not the promises.

Quocirca research is always pragmatic, business orientated and conducted in the context of the biggerpicture. ITC has the ability to transform businesses and the processes that drive them, but often fails todo so. Quocirca’s mission is to help organisations improve their success rate in process enablementthrough the adoption of the correct technologies at the correct time.

Quocirca has a pro-active primary research programme, regularly polling users, purchasers andresellers of ITC products and services on the issues of the day. Over time, Quocirca has built a pictureof long term investment trends, providing invaluable information for the whole of the ITC community.

Quocirca works with global and local providers of ITC products and services to help them deliver on thepromise that ITC holds for business. Quocirca’s clients include Oracle, Microsoft, IBM, Dell, T-Mobile,Vodafone, EMC, Symantec and Cisco, along with other large and medium sized vendors, serviceproviders and more specialist firms.

Sponsorship of specific studies by such organisations allows much of Quocirca’s research to be placedinto the public domain.

Quocirca’s independent culture and the real-world experience of Quocirca’s analysts, however, ensurethat our research and analysis is always objective, accurate, actionable and challenging.

Quocirca reports are freely available to everyone and may be requested via www.quocirca.com.

Contact:Quocirca Ltd Mountbatten HouseFairacresWindsorBerkshireSL4 4LE United KingdomTel +44 1753 754 838
