Figure 1. Pervasive Integration Challenges

Figure 2. Integration Facilitation Team's Roles and Responsibilities

CIO Call to Action: Shake Up Your

Integration Strategy to Enable Digital

Transformation

26 November 2015 ID:G00293850

Analyst(s): Massimo Pezzini, Benoit J. Lheureux, Keith Guttridge

VIEW SUMMARY

Reshaping your integration strategy toward a bimodal and self­service "pervasive integration" approachis required to achieve sustainable advantage in the frantically evolving and increasingly digital businessworld. Follow our five integration best practices to successfully tackle this challenge.

Overview

Key ChallengesIntegration can be a source of competitive differentiation and an enabler for bimodal IT, but mostCIOs have yet to recognize that their traditional, established integration strategies cannot copewith digitalization's fast technology innovation and accelerated pace of business.

The separation between application, data, B2B, cloud service, mobile app and IoT integrationtechnologies and skills is unsustainable. Most new projects must tackle a mix of these issues.

Pervasive, "good enough" do­it­yourself (DIY) integration by LOBs and business users is neededfor Mode 2 agility. Enabling tools are widely available, but DIY integration poses governance,security, compliance and cultural challenges, and introduces technical debt risks.

New providers targeting DIY integration defy the status quo. Integration technology fromtraditional players is no longer the safest choice and may harm short­term productivity.

RecommendationsFor CIOs and senior IT leaders:

Make the re­envisioning of your integration strategy a top priority, because a holistic, pervasiveand "low touch" bimodal integration approach is an entry ticket to the digital era.

Encourage and enable DIY integration by setting up support and guardrails for nonspecialists inintegration through a "facilitation team" that complements the fulfillment role of traditionalcentralized integration teams.

Encourage and assist application development (AD) project leaders into a design­for­interoperability approach by pushing an API­first style supported by appropriate technology.

Build up, incrementally, a hybrid integration platform (HIP) that incorporates capabilities forintegration specialists, LOB developers and business users in a self­service fashion.

TABLE OF CONTENTS

CONTENTS

IntroductionAnalysis

Make a Pervasive, Bimodal Approach to Integration a Top PriorityEnable DIY Integration via a Facilitation TeamEncourage and Support the Adoption of an API­First ApproachIncrementally Build Up an HIP for Self­Service Use by Integration Specialists, and Ad Hoc and CitizenIntegratorsSelect Integration Providers for Your HIP Tactically and With an Open Mind

Case Study

FIGURES

STRATEGIC PLANNING ASSUMPTIONS

By 2017, in large organizations at least 65% of new

integration flows will be developed outside the control

of IT departments.

By 2018, in most organizations at least 50% of new

integration flows will be implemented by citizen

integrators.

By 2018, 35% of enterprises will consolidate their data

integration and application integration competencies as

one team for aligning disciplines and technologies.

By 2018, more than 40% of large organizations will

have established a hybrid integration platform.

ACRONYM KEY AND GLOSSARY TERMS

AD application development

B2B business to business

DIY do­it­yourself

HIP hybrid integration platform

ICC integration competency center

IoT Internet of Things

iPaaS integration platform as a service

iSaaS integration software as a service

LOB line of business

SDA software­defined architecture

NOTE 1BUILDING COMPETITIVE BUSINESSADVANTAGE IN THE DIGITAL ERA

Jeanne W. Ross, Cynthia M. Beath and Ina Sebastian

wrote in Harvard Business Review paper, "Why

Nordstrom's Digital Strategy Works (and Yours

Probably Doesn't)":

"In a recent MIT CISR [Center

for Information Systems

Research] poll, 42% of our

respondents said they expected

to gain competitive advantage

from social, mobile, analytics,

cloud, and internet of things

(SMACIT) technologies.

But guess what? That's not

going to happen. The most

notable characteristic of those

technologies is their

accessibility — to customers,

employees, partners, and

competitors. Because they are

so accessible, it is very difficult

to generate competitive

advantage from any of them.

That doesn't mean you can

ignore them. But the truth is

that, for the most part, they

redefine minimum

requirements for operating in a

given industry — not

advantages.

Only a small percentage of

companies will gain competitive

advantage from SMACIT

technologies. Those that do will

IntroductionIncreasingly, organizations are realizing that the ability to support fast integration of applications, data,partners, providers, citizens, clients, patients, employees, temporary workers and others constituents,including "things," is imperative to survive in the digital era in terms of efficiency, effectiveness andinnovation (see "The Role of IT Integration in Today's Interoperable World"). Integration has alwaysbeen important, but in modern times it has become more critical than ever for a variety of reasons:

Digital business — A "nonintegrated digital business" is an oxymoron. Digitalization does giveorganizations an opportunity to establish personalized and responsive relationships by enabling"right­time" integration with their constituents via social media, business networks, mobileapplications and APIs.

Bimodal IT — To support the digital era's rapid pace of change, organizations of every size, inevery geography and in every industry are increasingly looking at a two­speed (bimodal) ITstrategies where slowly evolving, "run the business" IT systems (Mode 1) need to coexist andinteroperate with fast­changing and innovative "transform the business" initiatives (Mode 2).

Postmodern application strategies — Often, organizations look at cloud as the primary sourceof innovation in business applications and technology platforms — while trying to reduce their IToperation costs. However, cloud services must be integrated with established, usually on­premises, system­of­record applications in the context of postmodern application strategies.

Internet of Things — The Internet of Things (IoT) can enable unprecedented degrees ofefficiency and business model innovation. However, it also requires organizations to integrate thenew world of "smart things" and the data they produce with back­end business processes, dataand analytical environments.

The quest for sustainable competitive advantage — Modern technologies (such as social,mobile, analytics, cloud and the IoT) are easily accessible to any organization, but also to itscompetitors. They can therefore give organizations short­term, first­mover benefits; but, alone,cannot help to build a sustainable competitive advantage. Organizations can, however, maintaindifferentiation through original, smart and fast integration of such technologies (see Note 1).

Volatile business relationships — Business relationships are becoming more transient andvolatile; therefore, not only the ability to rapidly integrate, but also to quickly disintegrate iscritical. For example, rapidly disengaging from a supplier to replace it with a more efficientalternative; substituting, with minimal disruption, a cloud service with a more innovative offering;or switching to alternative IoT devices can make a big difference from a business perspective.

Effectively addressing such a pervasive integration challenge is a key business enabler and can eveninspire innovation (see Figure 1). Most CIOs have yet to come to this realization — or, if they haverecognized the need, have not yet fully addressed it.

Figure 1. Pervasive Integration Challenges

AD = application development; B2B = business­to­business; DW = data warehouse; ICC = integrationcompetency center; LOB = line of business

Source: Gartner (November 2015)

Integration is only a top priority for the most forward­looking CIOs. Often, it's an afterthought or isperceived as a "necessary evil." In many cases, CIOs consider it a done deal; a problem addressedyears ago, once and for all, via the acquisition of some traditional, high­end on­premises applicationplatforms (for example, enterprise service buses, data integration tools, integration appliances and B2Bgateway software), and by setting up a centralized "systematic" integration delivery approach (typicallybased on central IT­led data, application and B2B integration teams that carry out integration projectson behalf of the entire organization). While these traditional methods will continue to pay dividends, ithas recently become irresponsible for CIOs to rest on their laurels and assume that these systematicapproaches will sufficiently address the rapidly emerging new integration requirements.

The new bimodal IT reality of digitalization, cloud, mobile, social, big data, ubiquitous analytics, post­

advantage from SMACITtechnologies. Those that do willfocus less on the individualtechnologies and more on howthey rally all thosetechnologies, in unison, to fulfilla distinctive purpose."

modern application strategies and IoT is forcing CIOs to change their view of integration. Pursuingintegration at the stage of application design, rather than "after the fact," has become the "newnormal."

The traditional, systematic approach to integration is not agile enough to support the ubiquitous, fast­time­to­value, adaptive nature of modern integration needs that is often driven by semiautonomousinitiatives from departments and lines of business (LOBs). The traditional methods must thereforeevolve dramatically to tackle the new reality of pervasive integration.

This research will help CIOs and other senior IT leaders redefine the role of integration in their ITstrategy, figure out how to respond to the emerging pervasive integration challenges, and identify themeasures they must put in place to successfully transition to a new approach.

AnalysisMake a Pervasive, Bimodal Approach to Integration a Top PriorityAlmost by definition, innovative Mode 2 digital business initiatives are interdisciplinary and require theintegration of resources across multiple domains. For example, to implement its innovative car andscooter sharing service, Eni had to deal with mobile, IoT, B2B and application integration issues (referto Case Study section, Eni). This is in contrast to the typical organizational setting, by which differentintegration disciplines (such as data, application and B2B integration) are structured into independent,loosely coordinated and governed silos. A stovepipe setting like this (where information is not sharedacross different organizational units) is, by now, purely based on historical considerations and can bedysfunctional in modern times. These different disciplines are just different sides of the samemultifaceted coin; pervasive integration requires organizations to holistically master all of them. CIOsmust break the integration siloes and progressively converge them into a unified approach (see "FiveReasons to Begin Converging Application and Data Integration").

The fast pace of change that is driven by digitalization, the opportunity to experiment with ways torelate to constituencies via mobile, cloud and analytics, and the chance of testing new business modelsenabled by the IoT are at odds with the classic systematic approach to integration. Systematicintegration cannot deliver new, just­in­time integrations (for example, a new API to support a mobileapp for clients that must be released in just a few days) or may not be scalable enough to support themyriad of unplanned integration flows needed in the context of multiple mobile AD projects, cloudservice rollouts, real­time analytics efforts and IoT initiatives.

Nimbly addressing the rapid, iteratively and informally defined integration needs emerging in thecontext of Mode 2 projects implies that you should adopt a more flexible approach — which Gartnercalls adaptive integration (see "Adopt an Adaptive Approach to Effectively Support Rapid IntegrationRequirements"). Adaptive integration is based on the principle of just­in­time, DIY integration carriedout by the LOBs and application teams themselves, rather than by a central team of integrationspecialists.

In LOBs and application teams there is, typically, nobody with the expertise needed to master thecomplex and expensive high­end integration platforms adopted in the traditional systematic approach.In these contexts there are, however, often professional developers who have the skills to developmaybe reasonably complex, ad hoc integration flows and APIs — for example, by using open­sourceintegration frameworks. Or, there are application administrators or other personnel with enough skillsto implement, via rapid­integration­focused platforms, relatively simple point­to­point integration flows(for example, to move data from a cloud to an on­premises data source).

The adaptive approach can help your organization improve the agility and time to market of individualLOB­driven projects. It also makes it possible for external entities such as business partners, clients andsuppliers to rapidly link with your organization's business processes — in the context of API economystrategies, for example. Moreover, the adaptive approach can free your central integration teams fromthe burden of supporting simple and very specific requirements, thus allowing them to focus on themore strategic, business­critical and enterprisewide needs.

However, enabling these "ad hoc integrators" to freely perform integration tasks, using whichevertechnology they prefer, does expose your organization to:

Security, compliance and governance risks

Limited, if any, cost and skill synergy benefits

Uncontrollable and mounting technical debt

Moreover, it would be wrong to fully abandon the classic systematic approach. Complex, enterprisewideand business­critical integration issues that often manifest in the context of Mode 1 projects may, overtime, reduce in number and proportion to newer Mode 2 integration tasks, but are not going away. Forexample, a European bank recently found out it had to implement approximately 200 quite complexintegration flows between the new payment gateway it was putting in place and other applications in itsportfolio. A significant part of the project was the preliminary disengagement of the old, tightlyintegrated, custom­built payment gateway from the rest of the application portfolio. Thedisintegration/integration aspect was one of most complex, critical and expensive aspects of the newpayment gateway project and could only be carried out by a full­time team of integration specialists.

You must therefore set up "just enough" outcome­centered governance to minimize the risks and costsof adaptive integration by extending the classic systematic model toward what Gartner refers to as abimodal approach to integration (see "The Integrator's Dilemma: Can a Bimodal Approach BalanceIntegration Agility and Control?"). Bimodal integration postulates that while centralized integrationteams focus their limited resources on supporting business­critical integration needs, central IT also

makes available skills, services, technologies and governance models to facilitate adaptive integrationby ad hoc integrators.

Action items:

Progressively converge your data, application and B2B integration teams into a unified pervasiveintegration organization that can holistically support the full spectrum of requirements.

Proactively pursue an adaptive approach to enable DIY integration on the part of subsidiaries,LOBs, AD teams and other decentralized organizational entities (including external parties).

Evolve your established systematic approach toward a bimodal integration model to be able tosupport and govern adaptive integration needs.

Renovate your established integration infrastructure with technologies capable of addressing avariety of use cases and approaches.

Enable DIY Integration via a Facilitation TeamIn the frantically evolving modern business world, even individual, non­IT skilled business users mayneed to perform relatively simple integration tasks. For example, data scientists want to extract,transform, map and combine data from a variety of sources to perform their analysis. Marketingspecialists desire to quickly move clients' and prospects' email addresses from the company's CRMsystem into a campaign management application. Or, sales people wish to synchronize customer detailsbetween the company's email system and their own personal contact management mobile app.

This was traditionally done using the common work­around of the manual, "swivel chair," copy­and­paste­enabled integration; now there are a lot of tools in the market designed to enable integration bynon­IT experts. Business users' adoption of these platforms to address this class of "personal"integration needs is giving rise to the phenomenon of "citizen integrators" (see "Embrace the CitizenIntegrator Approach to Improve Business Users' Productivity and Agility"). You cannot ignore thisphenomenon; it's going to happen whether you approve it or not. You have to manage it, because youdon't want individual business users to pursue DIY integration in a spontaneous, unregulated fashion.Ungoverned DIY integration would potentially expose your organization to the same risks that stemfrom unmanaged adaptive integration — only an order of magnitude higher.

The similarities between the challenges posed by the need to support ad hoc and citizen integratorssuggest that assisting, managing and governing your citizen integrators should be implemented as partof the adaptive integration component of your bimodal integration strategy. In particular, you shouldset up an integration facilitation team, either as a task allocated to one of the traditional integrationteams or as an independent, totally dedicated unit (see Figure 2).

Figure 2. Integration Facilitation Team's Roles and Responsibilities

HIP = hybrid integration platform

Source: Gartner (November 2015)

This team should be in charge of:

Designing and implementing — maybe by combining different tools — an integration platformcapability that can support the integration specialists, but also the requirements of ad hoc andcitizen integrators.

Providing these different constituents with training, consulting, support and help desk services.

Delivering reusable integration templates and prepackaged integration flows (aka, cloudstreams)that ad hoc and citizen integrators can select, customize, deploy, manage and run in a self­serviceway (that is, with minimal or no intervention from the facilitation team).

Defining and enforcing guardrails and risk mitigation measures via "just enough," fit­for­the­audience and outcome­centered governance processes (for example, naming conventions, APIsformat standard, dissemination of best practices, integration platform usage tracking, codeinspection and validation services, and security policies enforcement).

(See "Five Steps Toward More Effective Integration Delivery.")

Although such an approach is still not widely implemented, initial evidence seems to indicate it can lead

to notable results in terms of efficiency and effectiveness (see Case Study section, Adobe).

Action Items:

Do not ignore, but encourage, the drive toward DIY integration on the part of ad hoc and citizen

integrators.

Set up an integration facilitation team as the central core of your bimodal integration strategy.

Encourage and Support the Adoption of an API­First Approach

The effort required to integrate a new application or data source is a function of how many predefined

integration endpoints the application itself and the surrounding systems provide. To minimize their

integration costs and time elapsed, modern applications should expose a set of integration endpoints

that are rich, comprehensive, well­documented, and easy to discover, understand and consume

(typically in the form of RESTful APIs). API­enabled applications are much easier, faster and cheaper to

integrate with than those that can only be integrated by using undocumented database­stored

procedures, direct access to complex relational data structures, or large and convoluted comma­

separated values (CSV) flat files.

Many organizations have pursued a service­oriented architecture approach — to facilitate integration

and application component sharing — with the aim of reducing time to market and more effectively

managing the application life cycle. The evolution of such strategies toward the use of managed RESTful

APIs is referred to as software­defined architecture for applications (SDA; see: "Software­Defined

Architecture for Applications in Digital Business").

SDA greatly facilitates integration, including on the part of nonspecialists in integration, because of the

popularity of APIs, and their widespread support in packaged applications, SaaS, application

development tools and integration platforms. Moreover, through SDA it's possible to enforce security,

privacy and compliance policies for the ad hoc and citizen integrators. Key to such a strategy are the

API management platforms that support publishing, documentation, secure access, tracking, and

runtime management and monitoring of the APIs (see: "Basic API Management Will Grow Into

Application Services Governance").

You should encourage application owners, AD managers and project leaders to design for

interoperability by embracing an API­first strategy whenever possible. This will enhance application

interoperability. Well­designed, well­documented and well­managed APIs give developers and

integration specialists an opportunity to rapidly implement new integration flows without the need to

fully understand the internal architecture, business logic and data model of the endpoints. APIs also

help to minimize interaction with these endpoints' owners; indeed, APIs' availability is an indispensable

condition for DIY integration.

Action items:

To minimize time, effort and cost of integration, and enable DIY integration by nonspecialists:

Embrace an SDA­based, API­first approach when implementing new applications.

Favor offerings delivering a rich set of well­documented and easy­to­understand APIs when

selecting SaaS or packaged applications.

In the context of your integration infrastructure renovation program, set up an API management

strategy to ensure the scalability of the API­first approach by facilitating the publishing, discovery,

consumption, tracking and monetization of APIs.

Incrementally Build Up an HIP for Self­Service Use by Integration Specialists,

and Ad Hoc and Citizen Integrators

Most CIOs working for large and midsize to large organizations worldwide during the past five to 10

years have invested in classic, on­premises integration platforms from well­established vendors such as

Axway, IBM, Informatica, Microsoft, Oracle, SAP, Seeburger, Software AG and TIBCO Software. Those

platforms are effective in supporting complex and demanding systematic integration requirements, but

are proving too complex and expensive to support the adaptive approach favored by ad hoc integrators

in LOBs, let alone for use by unskilled citizen integrators. These two constituencies need specific tools

that are focused on ease of use, fast time to integration, low cost of entry and short learning curves.

Moreover, given the critical role of APIs in enabling any form of integration, API management platforms

must be an essential component of any integration technology strategy (see "Magic Quadrant for

Application Services Governance").

As organizations increasingly adopt SaaS applications and other cloud services; consume and publish

public APIs; interact via social networks; provide mobile apps to clients, employees and partners;

participate in business process networks; and engage with the IoT, the "center of gravity" for

integration is moving to the cloud. For certain use cases (such as cloud­to­cloud or mobile­to­cloud) it

makes more sense to leverage an integration platform delivered as a cloud service, than an on­

premises one. Integration platform as a service (iPaaS) offerings support this type of delivery model

and fit naturally with most adaptive integration requirements, given their focus on ease of use and fast

time to integration. Cloud characteristics such as low cost of entry, subscription­based pricing and

instant deployment also make iPaaS a good fit for ad hoc integrators (see "Magic Quadrant for

Enterprise Integration Platform as a Service, Worldwide").

Given that even iPaaS offerings may be too complex for citizen integrators, several tools are emerging

in the market to support their specific requirements (see "Market Guide for Citizen Integrator Tools").Among those tools, integration SaaS (iSaaS) offerings are of particular relevance from a strategicperspective, due their ability to fit with multiple use cases.

To support the wide range of digital integration needs and constituents, you should implement acohesive combination of traditional on­premises integration platforms, iPaaS and iSaaS, surrounded byan API management layer. Gartner qualifies such a combination as the HIP (see "Why There's a MoveToward Hybrid Integration Platforms"). The attribute "hybrid" refers to the fact that an HIP can:

Target cloud, on­premises and "mixed" deployment models

Link any combination of cloud, on­premises, mobile and "thing" endpoints

Support the full spectrum of constituents (specialists, ad hoc and citizen integrators)

Address a wide range, and any combination, of use cases (B2B, application, data and processintegration)

A key aspect of the HIP is that it has to support self­service delivery of integration capabilities.Specialists, ad hoc and citizen integrators should not depend on some central team when they need touse HIP features to address their needs. If access to the HIP was a complex, tedious and bureaucraticprocess that would take days or weeks to be completed, users would refuse the organization's HIP andlook for more agile alternatives — such as stand­alone iPaaS or iSaaS offerings. To be accepted, an HIPshould be as easy to deal with as these tools. Authorized users should have self­service access to theorganization's HIP capability via a user experience tailored to their profile, whether integrationspecialist, ad hoc or citizen integrator.

From an IT perspective, the benefit of the HIP lies in the ability to enable decentralized, pervasiveintegration fulfillment, while maintaining some level of centralized control by enforcing security,administration, monitoring and management.

Action items:

Assess the degree to which your established integration infrastructure can support yourrequirements (in terms of use cases, endpoints and fit­for­constituent user experience) andidentify functional and nonfunctional gaps.

To fill these gaps, incrementally add iPaaS and iSaaS capabilities in the context of an HIP that isoperated, consumed and managed as a single integrated entity.

Extend your established integration infrastructure with API management capabilities to ensurethat you can sufficiently secure, scale and govern API­based integrations.

Enable access to your HIP via a self­service integration portal that selectively provides access tothe HIP features and functions according to the user's profile.

Enforce centralized security, administration, monitoring and management of integrationspecialists, ad hoc and citizen integrators by injecting these capabilities into your HIP.

Select Integration Providers for Your HIP Tactically and With an Open MindIn principle, an HIP should combine the functionality now provided by a variety of distinct products andservices — including, but not limited to: enterprise service buses, data integration tools, B2B gatewaysoftware, managed file transfer, integration appliances, iPaaS, iSaaS and API management.

As CIOs you will therefore have to face the classic dilemma: should you build your HIP by assemblingbest­of­breed­components, or should you look for a one­stop­shopping provider (typically theincumbent)?

Both established on­premises integration platform vendors, and emerging API management, iPaaS and,to a certain extent, iSaaS pure plays have recognized the new HIP reality and are busy working to fillgaps in their offerings — as needed to aspire to the role of end­to­end HIP provider.

However, very few vendors, if any, today have a fully articulated HIP vision and can deliver the full setof HIP capabilities as a coherent and well­integrated architecture. It is likely to take another two tothree years (or possibly more) to have proven and comprehensive end­to­end HIP offerings in themarket that are production­ready.

At this stage, in many cases you won't be able to buy your HIP, but will have to build it. Some(prevailingly midsize) organizations will adopt a "greenfield" or rip­and­replace strategy to implementtheir HIP. Most midsize to large organizations will often plan to incrementally extend their established,typically on­premises, integration platforms by sourcing the additional components needed to supportnew functionality (API management, for example), emerging use cases (such as cloud­to­cloud or IoTintegration), and the ad hoc and citizen integrator profiles.

However, in implementing your HIP you need to consider that the technology and vendor landscapesare evolving very rapidly and some consolidation is inevitable. In principle, therefore, every choice —including products or services from well­established vendors — must be tactical and subject to reviewas market conditions change.

Action Items:

Investigate your incumbent integration platform providers' plans to support an HIP setting andassess if, when and how these plans fit with your strategy.

Incrementally extend your established integration infrastructure with API management, iPaaS andiSaaS components from incumbent or pure­play providers — on the basis of technology maturity,

availability in your geography, support capabilities and provider's track record in supporting your

short­ to medium­term requirements.

Allow for some experimentation with new tools and review your technology selection every two or

three years. Predispose contingency plans to minimize the cost of replacing some elements of your

HIP as the market matures and consolidates during the next three to five years.

Case StudyEni

Based in Italy, Eni is an integrated energy company employing more than 84,000 people in 83

countries. The company engages in oil and natural gas exploration, field development and production,

as well as in the supply, trading and shipping of natural gas, liquefied natural gas, electricity, fuels and

chemical products. In 2013, Eni further diversified its business by launching a car­sharing service in

Italy (dubbed Enjoy); initially deployed in Milan and later in Rome, Florence and Turin. In June 2015,

the service was extended to provide scooter sharing. Initially launched as an experimental business,

Enjoy is a success (with more than 400,000 subscribers, the initiative reached the break­even point two

years earlier than anticipated). The company is therefore planning to extend the service to other cities.

To implement Enjoy, the Eni IT organization had to address several mobile, application, B2B and IoT

integration challenges through a combination of ad hoc Web­service and REST interfaces. Customers

register with the service, look for available cars or scooters, book a vehicle and lock/unlock it via a

mobile app that is integrated with a control center application. This in turn integrates in real time with

the Italian Ministry of Transportation, to check the validity of a new client's driving license. The control

center application also connects bidirectionally with each vehicle to enable the client's access and to

collect usage data for billing. Finally, the control center integrates with a credit card company for

payment processing and with the company's SAP ERP­based financial system for accounting purposes.

Adobe

Adobe is a leading provider of digital marketing and digital media tools and services. In the fast­moving

market where it operates, quick delivery of innovation to clients is of paramount importance. To this

end, the company adopted a "cloud first" strategy for its internal business applications.

Full responsibility for integration projects was, until recently, allocated to a centralized delivery team

equipped with a combination of traditional high­end, on­premises enterprise service buses and data

integration platforms. The company then deemed that this setting was no longer adequate to support

the business strategy, which requires a dramatic reduction in time to integration for new applications

(from weeks to days). Because of this requirement, Adobe decided to overhaul its approach to

integration.

Adobe is gradually implementing a DIY integration strategy by making available to ad hoc and citizen

integrators a common HIP based on SnapLogic's Elastic Integration Platform iPaaS offering. Use of the

HIP by nonspecialists is facilitated by a central integration platform service team, which provides

training, mentoring, best practices and support. This team also takes care of HIP maintenance and

evolution, and delivers reusable integration templates and frameworks, which are then made available

to users via a self­service integration portal.

The DIY integration initiative was kicked off in August 2014, and has significantly progressed ever since.

During the first 10 months, about 400 ad hoc and citizen integrators have been enabled to use the

company's HIP. The collective work of these nonspecialists delivered more than 600 integration

interfaces and more than 200 APIs, a workload that would take years for a classic integration

competency center to implement.

© 2015 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. If you are authorized to access this publication, your use of it is subject to the Usage Guidelines for

Gartner Services posted on gartner.com. 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

change 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.”

About Gartner | Careers | Newsroom | Policies | Site Index | IT Glossary | Contact Gartner