Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gartner CIO Call to Action- Shake Up Your Integration Strategy to Enable Digital Transformation (1)

1,538 views

Published on

  • Be the first to comment

Gartner CIO Call to Action- Shake Up Your Integration Strategy to Enable Digital Transformation (1)

  1. 1. 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" approach is required to achieve sustainable advantage in the frantically evolving and increasingly digital business world. Follow our five integration best practices to successfully tackle this challenge. Overview Key Challenges Integration can be a source of competitive differentiation and an enabler for bimodal IT, but most CIOs have yet to recognize that their traditional, established integration strategies cannot cope with digitalization's fast technology innovation and accelerated pace of business. The separation between application, data, B2B, cloud service, mobile app and IoT integration technologies 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 needed for 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 from traditional players is no longer the safest choice and may harm short­term productivity. Recommendations For CIOs and senior IT leaders: Make the re­envisioning of your integration strategy a top priority, because a holistic, pervasive and "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 in integration through a "facilitation team" that complements the fulfillment role of traditional centralized 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 for integration specialists, LOB developers and business users in a self­service fashion. TABLE OF CONTENTS CONTENTS Introduction Analysis Make a Pervasive, Bimodal Approach to Integration a Top Priority Enable DIY Integration via a Facilitation Team Encourage and Support the Adoption of an API­First Approach Incrementally Build Up an HIP for Self­Service Use by Integration Specialists, and Ad Hoc and Citizen Integrators Select 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 1 BUILDING COMPETITIVE BUSINESS ADVANTAGE 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
  2. 2. Introduction Increasingly, 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 and innovation (see "The Role of IT Integration in Today's Interoperable World"). Integration has always been 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 give organizations an opportunity to establish personalized and responsive relationships by enabling "right­time" integration with their constituents via social media, business networks, mobile applications and APIs. Bimodal IT — To support the digital era's rapid pace of change, organizations of every size, in every geography and in every industry are increasingly looking at a two­speed (bimodal) IT strategies where slowly evolving, "run the business" IT systems (Mode 1) need to coexist and interoperate with fast­changing and innovative "transform the business" initiatives (Mode 2). Postmodern application strategies — Often, organizations look at cloud as the primary source of innovation in business applications and technology platforms — while trying to reduce their IT operation 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 of efficiency and business model innovation. However, it also requires organizations to integrate the new world of "smart things" and the data they produce with back­end business processes, data and 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 its competitors. They can therefore give organizations short­term, first­mover benefits; but, alone, cannot help to build a sustainable competitive advantage. Organizations can, however, maintain differentiation through original, smart and fast integration of such technologies (see Note 1). Volatile business relationships — Business relationships are becoming more transient and volatile; therefore, not only the ability to rapidly integrate, but also to quickly disintegrate is critical. For example, rapidly disengaging from a supplier to replace it with a more efficient alternative; 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 even inspire innovation (see Figure 1). Most CIOs have yet to come to this realization — or, if they have recognized the need, have not yet fully addressed it. Figure 1. Pervasive Integration Challenges AD = application development; B2B = business­to­business; DW = data warehouse; ICC = integration competency 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 is perceived as a "necessary evil." In many cases, CIOs consider it a done deal; a problem addressed years ago, once and for all, via the acquisition of some traditional, high­end on­premises application platforms (for example, enterprise service buses, data integration tools, integration appliances and B2B gateway software), and by setting up a centralized "systematic" integration delivery approach (typically based on central IT­led data, application and B2B integration teams that carry out integration projects on behalf of the entire organization). While these traditional methods will continue to pay dividends, it has recently become irresponsible for CIOs to rest on their laurels and assume that these systematic approaches 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 SMACIT technologies. Those that do will focus less on the individual technologies and more on how they rally all those technologies, in unison, to fulfill a distinctive purpose."
  3. 3. modern application strategies and IoT is forcing CIOs to change their view of integration. Pursuing integration at the stage of application design, rather than "after the fact," has become the "new normal." 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 semiautonomous initiatives from departments and lines of business (LOBs). The traditional methods must therefore evolve 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 IT strategy, figure out how to respond to the emerging pervasive integration challenges, and identify the measures they must put in place to successfully transition to a new approach. Analysis Make a Pervasive, Bimodal Approach to Integration a Top Priority Almost by definition, innovative Mode 2 digital business initiatives are interdisciplinary and require the integration of resources across multiple domains. For example, to implement its innovative car and scooter sharing service, Eni had to deal with mobile, IoT, B2B and application integration issues (refer to Case Study section, Eni). This is in contrast to the typical organizational setting, by which different integration 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 shared across different organizational units) is, by now, purely based on historical considerations and can be dysfunctional in modern times. These different disciplines are just different sides of the same multifaceted coin; pervasive integration requires organizations to holistically master all of them. CIOs must break the integration siloes and progressively converge them into a unified approach (see "Five Reasons to Begin Converging Application and Data Integration"). The fast pace of change that is driven by digitalization, the opportunity to experiment with ways to relate to constituencies via mobile, cloud and analytics, and the chance of testing new business models enabled by the IoT are at odds with the classic systematic approach to integration. Systematic integration cannot deliver new, just­in­time integrations (for example, a new API to support a mobile app for clients that must be released in just a few days) or may not be scalable enough to support the myriad of unplanned integration flows needed in the context of multiple mobile AD projects, cloud service rollouts, real­time analytics efforts and IoT initiatives. Nimbly addressing the rapid, iteratively and informally defined integration needs emerging in the context of Mode 2 projects implies that you should adopt a more flexible approach — which Gartner calls adaptive integration (see "Adopt an Adaptive Approach to Effectively Support Rapid Integration Requirements"). Adaptive integration is based on the principle of just­in­time, DIY integration carried out by the LOBs and application teams themselves, rather than by a central team of integration specialists. In LOBs and application teams there is, typically, nobody with the expertise needed to master the complex 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 develop maybe reasonably complex, ad hoc integration flows and APIs — for example, by using open­source integration frameworks. Or, there are application administrators or other personnel with enough skills to 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 individual LOB­driven projects. It also makes it possible for external entities such as business partners, clients and suppliers to rapidly link with your organization's business processes — in the context of API economy strategies, for example. Moreover, the adaptive approach can free your central integration teams from the burden of supporting simple and very specific requirements, thus allowing them to focus on the more strategic, business­critical and enterprisewide needs. However, enabling these "ad hoc integrators" to freely perform integration tasks, using whichever technology 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, enterprisewide and business­critical integration issues that often manifest in the context of Mode 1 projects may, over time, reduce in number and proportion to newer Mode 2 integration tasks, but are not going away. For example, a European bank recently found out it had to implement approximately 200 quite complex integration flows between the new payment gateway it was putting in place and other applications in its portfolio. A significant part of the project was the preliminary disengagement of the old, tightly integrated, custom­built payment gateway from the rest of the application portfolio. The disintegration/integration aspect was one of most complex, critical and expensive aspects of the new payment 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 costs of adaptive integration by extending the classic systematic model toward what Gartner refers to as a bimodal approach to integration (see "The Integrator's Dilemma: Can a Bimodal Approach Balance Integration Agility and Control?"). Bimodal integration postulates that while centralized integration teams focus their limited resources on supporting business­critical integration needs, central IT also
  4. 4. makes available skills, services, technologies and governance models to facilitate adaptive integration by ad hoc integrators. Action items: Progressively converge your data, application and B2B integration teams into a unified pervasive integration 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 to support and govern adaptive integration needs. Renovate your established integration infrastructure with technologies capable of addressing a variety of use cases and approaches. Enable DIY Integration via a Facilitation Team In the frantically evolving modern business world, even individual, non­IT skilled business users may need 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. Marketing specialists desire to quickly move clients' and prospects' email addresses from the company's CRM system into a campaign management application. Or, sales people wish to synchronize customer details between 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 by non­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 Citizen Integrator Approach to Improve Business Users' Productivity and Agility"). You cannot ignore this phenomenon; it's going to happen whether you approve it or not. You have to manage it, because you don'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 stem from unmanaged adaptive integration — only an order of magnitude higher. The similarities between the challenges posed by the need to support ad hoc and citizen integrators suggest that assisting, managing and governing your citizen integrators should be implemented as part of the adaptive integration component of your bimodal integration strategy. In particular, you should set up an integration facilitation team, either as a task allocated to one of the traditional integration teams 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 platform capability that can support the integration specialists, but also the requirements of ad hoc and citizen 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­service way (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, APIs format standard, dissemination of best practices, integration platform usage tracking, code inspection and validation services, and security policies enforcement).
  5. 5. (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
  6. 6. 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 strategic perspective, due their ability to fit with multiple use cases. To support the wide range of digital integration needs and constituents, you should implement a cohesive combination of traditional on­premises integration platforms, iPaaS and iSaaS, surrounded by an API management layer. Gartner qualifies such a combination as the HIP (see "Why There's a Move Toward 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 process integration) 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 to use HIP features to address their needs. If access to the HIP was a complex, tedious and bureaucratic process that would take days or weeks to be completed, users would refuse the organization's HIP and look for more agile alternatives — such as stand­alone iPaaS or iSaaS offerings. To be accepted, an HIP should be as easy to deal with as these tools. Authorized users should have self­service access to the organization's HIP capability via a user experience tailored to their profile, whether integration specialist, ad hoc or citizen integrator. From an IT perspective, the benefit of the HIP lies in the ability to enable decentralized, pervasive integration 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 your requirements (in terms of use cases, endpoints and fit­for­constituent user experience) and identify functional and nonfunctional gaps. To fill these gaps, incrementally add iPaaS and iSaaS capabilities in the context of an HIP that is operated, consumed and managed as a single integrated entity. Extend your established integration infrastructure with API management capabilities to ensure that 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 to the HIP features and functions according to the user's profile. Enforce centralized security, administration, monitoring and management of integration specialists, ad hoc and citizen integrators by injecting these capabilities into your HIP. Select Integration Providers for Your HIP Tactically and With an Open Mind In principle, an HIP should combine the functionality now provided by a variety of distinct products and services — including, but not limited to: enterprise service buses, data integration tools, B2B gateway software, 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 assembling best­of­breed­components, or should you look for a one­stop­shopping provider (typically the incumbent)? 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 fill gaps 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 set of HIP capabilities as a coherent and well­integrated architecture. It is likely to take another two to three years (or possibly more) to have proven and comprehensive end­to­end HIP offerings in the market 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 implement their 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 support new functionality (API management, for example), emerging use cases (such as cloud­to­cloud or IoT integration), and the ad hoc and citizen integrator profiles. However, in implementing your HIP you need to consider that the technology and vendor landscapes are 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 review as market conditions change. Action Items: Investigate your incumbent integration platform providers' plans to support an HIP setting and assess if, when and how these plans fit with your strategy. Incrementally extend your established integration infrastructure with API management, iPaaS and iSaaS components from incumbent or pure­play providers — on the basis of technology maturity,
  7. 7. 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 Study Eni 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

×