Research

Publication Date: 10 November 2010 ID Number: G00208847

The Seven Critical Success Factors for Application Integration

Jess Thompson

The fundamental nature of information systems (IS) has gradually, but irrevocably, changed. Enterprises used to write most of their application software themselves. But now the IS department's primary job is to manage applications and ensure they work together smoothly through integration. Improving this application integration depends on an IS organization's ability to address a number of critical factors. We outline seven building blocks for successful application integration. Key Findings
The primary job of the IS department is now to manage applications, rather than to write new applications. New application development is only 18% of 2010 IT budgets. Application support which includes maintaining and enhancing legacy applications, selecting, installing, tailoring and maintaining packaged applications and integrating new, purchased and legacy applications with each other also accounts for 18% (see "IT Key Metrics Data 2010: Key Industry Measures: Cross Industry Analysis: Current Year"). When the majority of integration work for a company is funneled through the integration competency center (ICC), the company: Saves an average of 30% in integration application and data interface development time and costs. Saves 20% in maintenance costs. Achieves 25% reuse of integration components. Enables top-performing ICCs to save even more. Integration project costs often run between $250,000 and $1 million over several years, which means that the potential savings can easily be $100,000 or more.

Recommendations
Deploying integration technology in the absence of a strategy is a poor approach to improving integration development and maintenance costs.

2010 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartner's research organization and should not be construed as statements of fact. The opinions expressed herein are subject to chang e without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner's Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see "Guiding Principles on Independence and Objectivity" on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp

Establishing an ICC to set up best practices, technology standards and governance, justifying it based on business benefits, not just savings to IT, ensures that the ICC uses integration "city planning," which employs: Appropriate governance Integration technology architecture standards Best practices Obtain best practices from your application integration technology provider. If you use a system integrator to install your products and complete initial interfaces, harvest best practices from those projects.

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 2 of 12

TABLE OF CONTENTS
Analysis ....................................................................................................................................... 4 Introduction...................................................................................................................... 4 Critical Success Factors................................................................................................... 5 Vision .................................................................................................................. 5 Strategy .............................................................................................................. 5 ICC ..................................................................................................................... 6 Typical Roles .......................................................................................... 7 The ICC and Integration as a Service ...................................................... 7 Governance ........................................................................................................ 8 Best Practices and Metrics .................................................................................. 8 Measuring Your Processes ..................................................................... 9 Standard Technology Architecture ..................................................................... 10 Application Integration Technology .................................................................... 10 Recommended Reading ............................................................................................................. 11

LIST OF TABLES
Table 1. RACI Chart for Application Integration Governance ......................................................... 8

LIST OF FIGURES
Figure 1. Gartner's Critical Success Factors for Application Integration ......................................... 4

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 3 of 12

ANALYSIS

Introduction
The fundamental nature of IS has gradually, but irrevocably, changed. Enterprises used to write most of their application software themselves. With the advent of distributed computing in-house and fourth-generation languages (4GLs), application development has proliferated. More recently, mergers and acquisitions have added to the enterprise's application portfolio. Yet, in many organizations, application systems primarily exchange data through batch file transfer if they exchange data at all. The rising complexity of business applications, together with the need to change directions, has frequently changed this. It has become too hard, costly, time-consuming and risky for enterprises to write new, custom applications every time business needs change, so most large systems are purchased. However, a single application system rarely fulfils all business needs. As a result, an enterprise's applications are almost always heterogeneous, yet they aren't autonomous. Processes are integrated and data and transactions are constantly transferred among different systems within an enterprise or with other enterprises. Today, the primary job of the IS department is to manage applications, rather than write new applications. More than 90% of the work of the typical IS staff involves maintaining and enhancing legacy applications, selecting, installing, tailoring and maintaining packaged applications, and integrating new, purchased and legacy applications with each other. Because application integration is a fact of life, the interfaces created can either be of high value which typically means implemented using some form of commercial off-the-shelf (COTS) middleware and reusable for more than one project or a millstone around IT's neck. Today, many organizations seek to improve application integration to reduce the number of interfaces and the time it takes to develop interfaces. Improving application integration depends on addressing a number of critical factors. The seven building blocks for success are illustrated in Figure 1, and explained in the following sections. Figure 1. Gartner's Critical Success Factors for Application Integration

Source: Gartner (November 2010)

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 4 of 12

Critical Success Factors

Vision
Your vision statement will be specific to the enterprise. It must align with business goals and, when appropriate, address business problems. Here is an example of a vision statement for integration. Any enterprise that aspires to respond in real time must have the ability to be agile when needed, and that requires the enterprise to decide how it will achieve enough agility to compete in a world where instant gratification has taken on vital importance. One way to face this demand is to employ a technology strategy based on greater efficiency of operation (productivity), greater availability of information (awareness), and more options for handling anticipated changes (flexibility) and unanticipated changes (adaptability). These four enablers of agility provide a framework for examining an enterprise's agility, and provide a structure through which technology solutions can be delivered to improve on agility. Unfortunately, often technological choices only incidentally affect these enablers of agility. This means that an enterprise may have a significantly larger potential for agility (because it has many technologies that enable agility in-house) than it actually achieves. The solution to this problem is to target specific technologies to specific enablers of agility, and to deliver (using, for example, design patterns or governance practices) on the potential that these technologies impart. The vision for application integration is to improve the responsiveness of the enterprise, minimize the costs of an enterprise's IT system (formed by applications and interfaces), maximizing its ability to change the system. Integrating applications with well-architected, mediated interfaces enhances an enterprise's ability to respond to events as soon as they become known to any single part of the enterprise. The various divisions, departments and even groups in external business partners are treated as cooperating "subsystems," regardless of where they are located. As soon as new information is captured by any application system in any workgroup, it is made available to all other interested parties. In some cases, the interested party is an application system (e.g., on a mainframe or other server) that will process a transaction, update a database and maybe send a follow-up transaction elsewhere. In other cases, the interested party is a person using a browser, pager, mobile phone or desktop client/server application. Well-formed, mediated interfaces also enable an enterprise to more quickly adjust to changes in its IT system required to respond to changing business conditions. Your vision statement should: Make sense to, and be accepted by, business in addition to IT. Address all aspects of integration (application-to-application, B2B, cloud-to-onpremises). Be independent of technologies, products and vendors.

Strategy
A strategy is a plan of action intended to accomplish a specific goal. Today, virtually every project deploying an application involves integration. Companies have integrated their applications since the 1950s. Initially, the strategy employed by most enterprises was to allocate the responsibility for developing interfaces each project deploying an application. The result was a set of slow, arm's-length, point-to-point interfaces implemented using technologies such as batch file transfer. In the mid-1990s, demand for up-to-date information grew, and enterprises became increasingly frustrated with the number of interfaces being maintained. Consequently, a mediated, message-

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 5 of 12

at-a-time approach to integration (where appropriate) became more popular. Architectural patterns, such as hub and spoke, were implemented using multiple types of middleware for mediation such as message brokers, which ultimately evolved into the use of enterprise service bus (ESB) suites. Although modern, mediated approaches to integrating applications have been with us since the mid-1990s, organizations still have problems with the large number of interfaces and the time it takes to build and deploy them. Deploying technology, by itself, is a poor strategy for improving the implementation of interfaces. An effective strategy for integration is established by using these critical success factors: Establish an ICC. Develop an integration "city plan" consisting of: Policies that implement the necessary governance A set of best practices that is continually refined by measuring the result of applying the best practices in integration projects A technology architecture that establishes standards for the technologies to be used during application integration Have integration competency staff drive the selection of the integration technologies that are to be deployed. We explain each of these in greater detail in the following sections.

ICC
The integration of applications will be a major endeavor for most enterprises into the near future. An ICC provides an organizational platform to address the different integration issues through a common set of well-defined technologies, best practices and policies. This leads to reduced cost and risk, better manageability and significant economies of scale in terms of technology and skills. The ICC should have full responsibility for coordinating and overseeing application integration from strategic planning to operating the integration infrastructure. Key objectives include: Get application integration recognized as the formal discipline it needs to be. Combine the skills and processes associated with application integration into a single group, making better use of resources. Build and develop skills, capability and best practices for building interfaces and monitoring the operation of those interfaces. Monitor and assess integration technology and tools, and establish a flexible set of approved tools. Lead and support integration projects with the cooperation of application developers. Some of the resources needed to pursue these objectives can be outsourced to other internal IT groups (e.g., IT operations), or to external service providers. However, the ICC should keep governance and control of the relevant processes through proper controls specified in formal SLAs with the service provider.

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 6 of 12

Typical Roles
The typical roles fall into three categories: Operations: System Administrator: Ensures that integration tools have adequate system resources. Ensures that policies are enforced. Database Administrator: Ensures that the database in integration tools has adequate resources. Tool Technician: Ensures the appropriate operation of integration tools; debugs problem reports. Administration: ICC Manager: Communicates vision; demonstrates business value. Project Manager: Plans integration projects; maintains project plans and project metrics. Methodologist: Specifies and maintains best practices. Asset Manager: Maintains integration artifacts and metadata. Engineering: Business Analyst: Develops process models to document interface requirements. System and Data Architect: Develops information models to document interface requirements. Software Engineer: Develops adapters and implements integration logic. Domain Expert: Counsels software engineering in application logic. Quality Assurance (QA): Tests that interface components function appropriately, and that the resultant system works as required.

The ICC and Integration as a Service

An ICC functions most efficiently when it provides integration as a service. The alternative is for ICC members to act as mentors who train a project member in best practices and the use of technology. Using a mentoring approach for each project that requires integration wastes the time of valuable resources. A development team may find it faster to modify the application or build adapters to the application (because they know the code and wrote the application, or bought it and modified it), rather than having people from the ICC code adapters to an application they don't understand or have never seen. This is overcome by incorporating the use of the domain expert described in the previous section. The objective is for the ICC to use the necessary governance, best practices and standard technologies on each project that requires integration. Gartner research shows that such an approach can reduce the time required to deploy an interface by 30%, and the cost of maintaining interfaces by 20%.

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 7 of 12

Governance
Governance helps an enterprise effectively and efficiently allocate resources to achieve business results, using a set of policies, procedures and rules. The leader of an ICC can use the disciplines of governance to create a framework for how best to run an enterprise application integration project. "Application Governance Key Initiative Overview" provides a framework the ICC leader can use to determine your organization's readiness to accept governance. The correct governance will be in part determine by your organizational structure. Table 1 provides an example of a responsible, accountable, consulted and informed (RACI) chart for decisions that must be made for integration projects. Table 1. RACI Chart for Application Integration Governance
Decision Which interfaces to do? Responsible Enterprise architects, data architects, application developers Enterprise architects, data architects Accountable Enterprise architects Consulted Application owners, application managers, security experts, database experts Application owners, application managers, security experts, database experts Application developers, security experts, database experts Informed All ICC staff

Which interfaces to do first?

Enterprise architects, ICC internal marketing, ICC manager

All ICC staff, integration project owner

Is this really a new interface, or an extension of an existing one?

Enterprise architects, ICC administration, application developers, integration project owner Enterprise architects, application developers, application owners, IT budget committee Enterprise architects, data architects, application developers

Enterprise architects, ICC manager

If a new interface is agreed on, all ICC staff; If not, the owners of the interface that will be extended Application developers, interface owner

Who will pay for the development and maintenance of the interface?

ICC project sponsor, IT budget committee

Application owners, application managers, security experts, database experts Application owners, application developers, operations, security experts, database experts

Who owns the interface?

Enterprise architects, data architects, application owners

All ICC staff

Source: Gartner (November 2010)

Best Practices and Metrics

Integration aspects of a development project are different from other development projects; they involve distinct problems, methodologies and roles. A simple methodology, including the sequence of activities and various checklists, can make integration projects go more smoothly.
Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Page 8 of 12

Do not attempt to apply all aspects of a software engineering methodology to an integration project; however, such methodology may be useful. The methodologies can serve as a starting point from which you can cut unneeded activities and add typical integration activities. The resulting practices should be considerably shorter than your starting point. Example areas for which best practices can be developed include: City planning architecture consultation and definition Technology evaluation and vendor selection Integration infrastructure design and implementation Interface repository management Resource and skills planning Administration processes (billing, chargeback, etc.) Incident and problem management Quality of service and performance management Pilot management Actual integration of applications (design, development and rollout) Conflict resolution to address conflicting goals and priorities Incorporation of appropriate integration standards (for example, the use of ACORD for integrating applications used in the insurance vertical).

Measuring Your Processes

The Software Engineering Institute's Capability Maturity Model (CMM) establishes an approach for improving the software development. That model contains a set of five levels of development maturity: 1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimizing (For more information, see www.dfw-asee.org/archive/cmm-history.pdf.) During the 1990s, most IT organizations aspired to be at Level 5, but were at Level 1 or 2. At a high level, this model teaches that you can't improve what you don't measure. While it's very difficult for an entire IT organization to reach Level 5, it's not out of the reach of smaller, focused organizations, such as an ICC. An ICC that establishes a set of best practices measures the use of those best practices for all integration projects, analyzes those metrics and uses the result to tune those best practices puts an ICC at a CMM Level 5. It is this level of maturity that enables an organization to reduce the cost of interface development by 30%, and the cost of maintaining interfaces by 20%.

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 9 of 12

Standard Technology Architecture

The technology standards established by the ICC should be established as an enterprise standard for application integration technology, administration, monitoring and security. Establishing such a standard puts in place those products that enable an organization to be most productive, and to prevent the unnecessary proliferation of application integration products. When a single body such as an ICC is responsible for establishing the technology architecture for integration, it is able to apply a disciplined approach using pilot and proof-of-concept projects that selects the best products for the IT organization from among the vendor offerings being considered. However, the cost of today's commercial application integration (i.e., ESB suite) products is becoming a financial challenge to organizations, and is creating a growing adoption of supported open-source ESB suites. This renews the challenge of keeping the number of technologies that are used for application integration to a minimum. In addition to those technologies to be used for integration, the standard technology architecture should also address how the inevitable creep of alternative products that occurs through the acquisition of packaged applications, headstrong line-of-business purchases, open-source software (OSS) try-it-for-free projects, and mergers and acquisition will be integrated into the standard technology architecture.

Application Integration Technology

Integration suites were originally designed to support data consistency, multistep processes and composite application integration. They were built on a robust messaging platform and initially used proprietary messaging protocols to provide efficient and reliable messaging. ESBs were originally designed to support the deployment of applications built using Web services. To qualify as an ESB, an infrastructure must: Implement synchronous and asynchronous program-to-program communication, moving messages between service-oriented-architecture (SOA) service consumer modules and service provider modules at runtime. An ESB may also move files, database rows and other data. Support fundamental Web and Web services standards, including uniform resource identifiers, XML, SOAP and Web Services Description Language (WSDL). Almost all ESBs also move non-XML messages and data, and offer additional proprietary communication protocols. Implement a service binding to create associations between SOA consumer and provider modules. Have an architecture that enables it to apply optional intermediary functions to messages in flight. Mediation functions can be added to the core bus to, for example, inspect, validate, reroute, transform, enrich, log and track messages as they pass through. Support typed messages (that is, messages for which contents are explicitly defined and documented). This is necessary to implement many kinds of mediation. See "The Enterprise Service Bus: Communication Backbone for SOA" for more details. Since the inception of ESBs, vendors of integration technology have extended their offerings to provide the five features that define ESBs: Synchronous and asynchronous program-to-program communication
Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Page 10 of 12

Support for fundamental Web services standards Implementation of service bindings An architecture that enables users to extend the processing of in-flight messages Support for typed messages that are foundational to multiple forms of mediation As a result, integration suites are now a proper superset of ESBs. To implement this new set of functionality, integration suite vendors are transitioning to new OSGi-compliant architectures that are "service-oriented inside." Also, the new architecture now is offered via new packaging that enables consumers to buy the capabilities they require when they require them.

RECOMMENDED READING
"IT Key Metrics Data 2010: Key Industry Measures: Cross Industry Analysis: Current Year" "Application Governance Key Initiative Overview" "Cost Cutting Through the Use of an Integration Competency Center or SOA Center of Excellence" "The Enterprise Service Bus: Communication Backbone for SOA"

Evidence
Budget metrics were obtained from the research for "IT Key Metrics Data 2010: Key Industry Measures: Cross Industry Analysis: Current Year." Other information in this research has been compiled from more than 10 years of Gartner consulting experience, Gartner client inquiries and vendor interviews.

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 11 of 12

REGIONAL HEADQUARTERS
Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 U.S.A. +1 203 964 0096 European Headquarters Tamesis The Glanty Egham Surrey, TW20 9AW UNITED KINGDOM +44 1784 431611 Asia/Pacific Headquarters Gartner Australasia Pty. Ltd. Level 9, 141 Walker Street North Sydney New South Wales 2060 AUSTRALIA +61 2 9459 4600 Japan Headquarters Gartner Japan Ltd. Aobadai Hills, 6F 7-7, Aobadai, 4-chome Meguro-ku, Tokyo 153-0042 JAPAN +81 3 3481 3670 Latin America Headquarters Gartner do Brazil Av. das Naes Unidas, 12551 9 andarWorld Trade Center 04578-903So Paulo SP BRAZIL +55 11 3443 1509

Publication Date: 10 November 2010/ID Number: G00208847 2010 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 12 of 12