Technology & Engineering
Integration Platform as a S...
<p>Integration Platform as a Service: Moving Integration to the Cloud Gartner RAS Core Research Note G00210747, Massimo Pezzini, Benoit J. Lheureux, 7 March 2011 Integration platform as a service (iPaaS) is a suite of cloud services aimed at addressing a wide range of cloud, B2B, and on-premises integration and governance scenarios. This research provides user organizations’ CIOs, CTOs, enterprise technology architects, integration competency center/service-oriented architecture (SOA) center-of-excellence (COE) managers, B2B integration managers and project leaders, as well as IT providers’ planners, with an analysis of the evolution, adoption trends and industry impact of this innovative approach. Key Findings • An iPaaS consolidates multiple cloud services in a suite aimed at the integration and governance of any combination of on-premises and off-premises applications, SOA and cloud services, processes, and data, within or across organizations. An iPaaS complements the application-development- and hosting-oriented application platform as a service (aPaaS). • An iPaaS is an evolution of integration as a service, which has been widely adopted for e-commerce B2B and cloud services integration. • Midsize enterprises will endorse iPaaS first. Large organizations will prevailingly look at iPaaS as complementary to traditional application infrastructures. • Many iPaaS offerings will also be available in the form of products (cloud-enabled integration platforms [CEIP]) to be deployed in private clouds or to implement new iPaaS offerings. Recommendations • Users should initially consider iPaaS primarily to support integration and governance in e-commerce B2B scenarios, or where at least some of the involved applications are cloud-based. These are the most-proven use cases for iPaaS. • However, users should also plan for a major revision of their integration and governance strategies, as iPaaS offerings evolve into end-to-end alternatives to traditional platforms. • Users must plan for a long-term coexistence of their established integration and governance infrastructures with iPaaS-based approaches. 2 • Providers of application infrastructure, software as a service (SaaS), packaged application, system integration, cloud services brokerage and cloud services should look at iPaaS as a new business opportunity and an enabler for value-added offerings. STRATEGIC PLANNING ASSUMPTION(S) By 2016, at least 35% of all large and midsize organizations worldwide will be using one or more iPaaS offerings in some form. ANALYSIS What You Need to Know An iPaaS is a set of cloud-based services providing a multitenant and elastically scalable platform (in the cloud) to support a variety of integration scenarios: • Cloud to on-premises • Cloud to cloud • On-premises to on-premises • E-commerce B2B integration In addition to a set of integration services, iPaaS provides cloud-based services aimed at enabling design time and runtime governance of the integration artifacts (process models, compositions, transformation and routing rules, service interface definitions, SLAs, policies, etc.) utilized to address specific integration issues. Although iPaaS is a fledgling market, it inherits and builds on the well-established integration-as-a-service market. While some components of the iPaaS vision — particularly those focused on the integration functionalities — are already available from many providers, more functionally complete iPaaS offerings will emerge in the 2012 to 2013 time frame. In the short term (through 2013), leading-edge user organizations, looking for greater flexibility, faster time to market, support for new cloud-centric business models and cost reduction should look at iPaaS approaches as potential alternatives to traditional (that is, non-cloud-based) integration and governance platforms for an ample set of requirements. Given the nascent state of the market, mainstream organizations should consider iPaaS offerings as complementary to traditional platforms, and primarily adopt them to address low-risk scenarios, such as e-commerce B2B integration and cloud services integration. Directly stemming from long-lasting industry experience with integration as a service, these are the most-proven iPaaS use cases so far. All users should take into account that even limited iPaaS adoption will require the extension of the responsibilities and skills of established integration competency centers and SOA COEs to cover the new approach, in addition to traditional platforms. Over time, iPaaS technology and business models will mature and vendor offerings will evolve to be able to support a greater variety of use cases, including several aspects of traditional on-premises scenarios. Meanwhile, growing user adoption of SaaS, evolving requirements for more tightly coupled multienterprise B2B integration, the necessity for improving agility in relationships with business partners and continued pressure for cost reductions will make the iPaaS value proposition increasingly compelling, even for users with large and long-established integration and governance application infrastructures. Therefore, longer term (2015 and beyond), users should prepare for a potential major rebalancing of the center of gravity of their integration and governance strategies between iPaaS and on-premises platforms. Application infrastructure middleware vendors, SaaS providers, packaged application vendors, system integrators, and integration brokerage and cloud services brokerage providers should look at iPaaS (also in the form of its rendition as an on-premises product, a CEIP) both as a business opportunity and an enabling platform for their value-added offerings. Introduction When it comes to application infrastructure, some of the burning questions that organizations are asking themselves include: • If I host some of my application functionality in the cloud, how do I integrate that with my existing on-premises applications? • How do I integrate my on-premises application with external business partners? • Everyone is talking about platform as a service (PaaS). Should I use it? If so, when, and when not? In this research, we address these questions by introducing the concept of iPaaS, a specific form of PaaS targeting integration © 2011 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 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” on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp 3 and governance requirements, and how it can be used to address cloud-to-on-premises and other related requirements. PaaS: An Evolving Market In Gartner’s view, the architecture of cloud computing is structured in three foundation layers: • The system infrastructure service layer (commonly referred to as infrastructure as a service [IaaS]), providing the core computing, networking and storage services • The application infrastructure service layer (usually called PaaS), implementing database management system (DBMS), application server, application security, messaging, business process management (BPM), managed file transfer (MFT), B2B integration, data and application integration, SOA governance, and a variety of other “middle tier” application services • The application service layer (mostly known as SaaS), delivering user application functionalities such as ERP, CRM, human capital management (HCM), collaboration, Web conferencing, e-mail and a myriad of other scenarios, including for specific vertical markets While SaaS and, to a lesser extent, IaaS are widely adopted by the user community, PaaS is less well-understood and certainly not as popular as the other cloud layers. This is in the nature of the middle-tier services it provides, which are not oriented toward end users (like SaaS) and cannot easily be used to support the deployment of existing applications, such as IaaS. PaaS is in its infancy, and most mainstream users only have a vague idea of what it is. Moreover, its intended audience is primarily the development community of architects, project leaders and developers (in end-user organizations or those working for independent software vendors [ISVs]/service providers) focused on implementing new, cloud-based application systems, which are still a minority (albeit growing) of the total number of new development projects. Toward PaaS Suites A factor that may slow down PaaS adoption is the extreme fragmentation of the market, with dozens of vendors providing individual PaaS functionalities (MFT, DBMSs, messaging, application servers, data integration, B2B integration, BPM technology, etc.). However, few (if any) providers deliver a comprehensive and integrated PaaS offering. This situation is acceptable in the initial stages of the PaaS life cycle, when users and vendors are still primarily experimenting with the concept, testing technologies and business models, and piloting applications and offerings. However, such fragmentation will be impossible to deal with when users and service providers start to implement large-scale, business-critical applications requiring the simultaneous and in concert use of multiple PaaS capabilities (for example, user experience, application servers, DBMSs, security and messaging). Developing, deploying, running, managing, monitoring and paying for an application built on PaaS services from four or five different providers deployed in multiple and geographically dispersed data centers, would pose a number of intractable performance, security, availability, management and billing issues. Implementing business- critical applications with stringent quality-of-service requirements on a multivendor, best-of-breed, distributed PaaS would be nearly impossible and certainly extremely impractical. For this reason, Gartner predicts a rapid aggregation of PaaS offerings into suites of functionalities, providing users with well- integrated and optimized platform services (from the same or different suppliers), colocated in the same data center to provide appropriate levels of performance, security, manageability and availability. This aggregation process will take place in steps. Initially (circa 2013), PaaS functionalities will consolidate around specific usage scenarios. Later (2015 onward), comprehensive PaaS offerings will also emerge. These will provide suites of integrated and colocated services, capable of supporting multiple usage scenarios and project types out of a common technology foundation. Comparing aPaaS With iPaaS The PaaS market will change from the current and growing number of vendors providing point services to a relatively low number (probably a few dozen) of vertically integrated PaaS suites (each aggregating colocated services from a “suite master” and from its partners), delivered to users through a variety of direct and indirect channels. The challenge for users will be the transition from integrating point PaaS services, to support specific requirements, to the problem of managing coexistence, interoperability and federations of vertically integrated PaaS adopted by different development teams or embedded in various cloud offerings. The trend toward specialized PaaS suites is already visible in terms of vendor strategies and available or announced offerings. At least two classes of suites are beginning to conceptually materialize to respond to well-defined user requirements: • The aPaaS suite, which is aimed at providing users with an integrated platform for hosting, and managing individual applications and application services. The aPaaS offerings typically aggregate cloud services of application server, application development tools, composition, portal and user experience, orchestration, data management, application security, and others. • The iPaaS suite, which is meant to provide users with an integrated integration and governance platform for making independently designed applications and services work together. The iPaaS offerings usually combine cloud services for protocol bridging, messaging transports, transformation, routing, service virtualization, adapters, orchestration, partner community management, MFT, registry/repository, development tools and others. 4 Other similar suites (for example, targeting BPM, collaboration and other usage scenarios) are likely to emerge during the next two or three years as technologies and offerings mature and user requirements and usage patterns manifest and crystallize. What Is iPaaS? An iPaaS combines integration and governance and other capabilities to respond to emerging user requirements to procure, deploy and manage these functionalities as a single, integrated infrastructure. This requirement is a consequence of the growing adoption of SOA, which postulates a strong tie between integration and governance. The best practices, which have matured in more than a decade of SOA experience, remain valid as cloud computing comes into the picture. Gartner believes that users will continue to address integration and governance in a unified fashion, even in an increasingly cloud-centric world, and, consequently, will favor vendors capable of providing all (or at least most) of the relevant cloud services as a consolidated platform. However, many vendors and users initially will selectively provide and consume only subsets of a full iPaaS, while they climb the learning curve of this new market. Therefore, Gartner defines iPaaS as a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual, or across multiple, organizations. Dissecting the Definition of iPaaS Let’s dissect the definition of iPaaS and clarify a few points: • An iPaaS provides users with a combination of cloud services — collectively called integration platform services — to develop, execute and manage integration flows (that is, custom- developed software and metadata implementing the “integration logic” needed to connect multiple applications by performing the appropriate message transformation, routing, protocol conversions, service virtualization, orchestrations, security federation, usage tracking, administration, monitoring and management etc.). • The integration flows running on iPaaS can connect, in a many-to-many fashion, any combination of on-premises and off-premises applications, services (in both the SOA and cloud senses of the word), processes and data. Integration flows can be developed by the iPaaS client (which has access to the iPaaS development environment) or by a service provider (including the iPaaS provider itself) on behalf of the client. If the development environment is only available to the iPaaS vendor (and not to clients and other service providers), the offerings are referred to as “embedded iPaaS,” because their capabilities are only available embedded in a broader service (e.g., integration brokerages or cloud services brokerages; see below) delivered by the iPaaS provider. • An iPaaS supports integration within the same organization, as well as across multiple organizations, in a B2B fashion that often involves the e-commerce supplier and customer, but may also include any multienterprise integration and collaboration. • In addition to integration platform services, an iPaaS provides governance platform services, including registry/repository, artifacts life cycle management, policy management and enforcement, as well as the extraction of the associated data. The iPaaS governance platform services can potentially be used independently from the integration platform services — for example, to support or enforce governance processes of an SOA initiative using a classic on-premises SOA backplane. • Ideally, iPaaS services are delivered to multiple concurrent communities of users (tenants) in an elastic, scalable and self- service fashion, with assurance of tenant integrity, security and service levels. Many iPaaS implementations do not currently support all these attributes, but most likely will do so over time. Contrasting iPaaS, Integration Brokerage and Cloud Services Brokerage The commercial offerings of iPaaS vendors are typically complemented by training, support, consulting, traditional system integration and other services, such as certain aspects of IT management and operations. It is important to emphasize that an iPaaS, per se, doesn’t provide the service of integrating a specific set of applications for a certain user organization (for example, the integration of a company’s SAP on-premises instance with its salesforce.com instance in the cloud). An iPaaS provides the development tools, execution environment and governance capabilities that end users or service providers can leverage to implement and support such a specific integration scenario. However, in many cases, vendors will provide (as a service running on their own or a third-party’s iPaaS) “prepackaged integration flows” (often referred to as cloud streams when at least one of the endpoints is a cloud service) meant to accelerate the implementation of the most-common integration scenarios by customizing, extending and configuring predefined integration flow templates. These prepackaged specialized integration modules are basically iPaaS applications, and are not a part of iPaaS, but convenient add-ons for integration specialists. As such, they are closer to the SaaS layer of the cloud-computing architecture than to the PaaS layer. Integration brokerage providers offer the full spectrum of IT services capabilities to implement, manage and support end-to- end integration solutions (including the professional services and outsourcing aspects), either on top of their own proprietary (and often embedded) iPaaS or by leveraging, transparently to the user, one or multiple third-party iPaaS offerings. However, some integration brokerage providers — typically, system integrators — allow users to select which iPaaS to use on the basis of criteria such as cost, technical affinity, SLA, geography or vertical specialization. Cloud services brokerage providers may combine iPaaS-based integration services with other cloud services (including aPaaS and others) to provide users with end-to-end solutions to specific business problems that involve the consumption of services from multiple cloud services providers. 5 Why iPaaS Is Relevant for Users An iPaaS provides the capabilities to support, in a public or private cloud, a variety of integration scenarios (cloud to cloud, cloud to on-premises, on-premises to on-premises) within the same enterprise, e-commerce B2B integration, and the appropriate governance aspects (see Figure 1). The obvious benefit for users is that they don’t need to procure, deploy and manage hardware and application infrastructure software in their own data centers, as they would when adopting traditional, on-premises integration and governance platforms. Initially, iPaaS Targets B2B and Cloud Services Integration The notion of running integration flows on a third-party integration platform provided as a service is well-understood and proven, because it’s very commonly used in the context of e-commerce B2B integration and, increasingly, for cloud-to-on-premises integration (also known as cloud services integration). Vendors addressing e-commerce B2B integration (e.g., Crossgate, E2open, GXS, Hubspan, IBM-Sterling Commerce, Seeburger, Liaison Technologies and SPS Commerce) and those targeting cloud- services integration (Appresso, Dell-Boomi, IBM-Cast Iron Systems, Informatica, Fiorano, Infoteria, iWay Software, Jitterbit, Microsoft, Pervasive Software and Vigience) have been offering at least some of the iPaaS integration platform service capabilities (previously referred to in Gartner research as integration as a service) since the early 2000s. Therefore, we consider these vendors to be iPaaS providers, although they may not provide all the capabilities of a full-fledged iPaaS yet. Historically, on-premises integration middleware vendors and integration-as-a-service providers were, in principle, different companies, even if some integration-as-a-service players (e.g., IBM-Sterling Commerce and GXS) used to also sell application infrastructure products, such as B2B integration software or cloud integration products. Like integration as a service before it, iPaaS is, to a certain extent, a complementary alternative to classic integration middleware. However, for the near future, traditional on-premises infrastructures and iPaaS-based integration will coexist and complement each other, especially in large organizations. It is also likely that, at least in an initial phase, iPaaS offerings will be more rapidly adopted to support specific scenarios, like cloud to cloud, cloud to on-premises and traditional e-commerce B2B integration, given their affinity with traditional integration as a service. In other scenarios, such as systematic integration of on-premises applications or SOA infrastructure deployments, for many users, the most comfortable option will remain the deployment of traditional on-premises integration middleware (or, in the future, some form of private iPaaS). Acronym Key: A2A — application to application Source: Gartner (March 2011) Figure 1. Deployment Scenarios for iPaaS 6 However, individual PaaS services will mature, their aggregation into more functionally complete iPaaS will progress, the offerings of established integration-as-a-service vendors will evolve and new players will enter the market. Therefore, end users and service providers will increasingly look at iPaaS as a viable alternative to traditional application infrastructure middleware (enterprise service bus [ESB] suites, B2B integration software, MFT, data integration tools, SOA governance platforms and other technologies) for a wider range of use cases. An iPaaS Will Be Pervasively Used for Multiple Scenarios Most large organizations have sizeable and widely adopted integration infrastructures and SOA governance platforms in place; therefore, it is unlikely that they will fully migrate all their applications to an iPaaS during the next three to five years. However, large organizations will familiarize themselves with cloud computing and expand their use of SaaS applications. Therefore, they will increasingly look to iPaaS to address requirements for which iPaaS is a proven and economically attractive alternative to traditional integration middleware. These include, but are not limited to, cloud services integration, e-commerce B2B integration, integration of remote subsidiaries or federated SOA support. Large organizations will also look at iPaaS to extend their current environment with functionalities (for example, certain aspects of SOA governance like registry/repository and artifacts life cycle management) that, in certain cases, would be too expensive or time consuming to implement in a traditional fashion. At the same time large enterprises currently using integration-as-a-service platforms will naturally and incrementally extend the use of these offerings to support requirements with close affinity with e-commerce B2B and cloud-service integration (for example, integration of remote subsidiaries or SOA federation support). This trend will accelerate as providers expand the reach of their platforms toward a more comprehensive set of iPaaS functionalities. Midsize organizations with minimal or no investment in application infrastructure middleware will probably adopt iPaaS more rapidly than large enterprises, as has been the case for integration as a service, which has been widely adopted by organizations that need to do e-commerce B2B integration, but lack the technical or staffing resources to unilaterally implement B2B integration software. These organizations are extensively adopting SaaS solutions, and will face the issues of integrating these applications with their established on-premises systems and governing the resulting integration flows. Therefore, they may be attracted by an iPaaS proposition (often through an integration brokerage, a cloud services brokerage provider or a SaaS provider), which would enable fast time to deployment and would avoid the capital investments and IT operation costs associated with deploying traditional application infrastructure products and the related hardware infrastructure. Even users who initially see little value in iPaaS will not be able to completely ignore this new approach within the next five years. In fact, iPaaS capabilities will be incorporated into many SaaS offerings (either through partnerships, OEM agreements or internal developments), and will also be utilized by integration brokerage, cloud services brokerage and other IT service providers as enablers of their offerings. By 2016, at least 35% of all large and midsize organizations worldwide will be using one or more iPaaS offerings in some form. Technology Context for iPaaS Schematically, we can say that cloud applications will run on one or multiple aPaaS offerings and will integrate with each other (and with on-premises applications) through one or multiple iPaaS offerings, which will also be used to manage the associated governance processes. This is very similar to the relationship between application servers, ESB suites and SOA governance tools in a traditional application infrastructure middleware setting: Applications run on application servers, are integrated through an ESB suite and the relevant governance processes are managed through SOA governance tools. The analogy doesn’t stop there, however. Next-Generation iPaaS ESB suites require a platform middleware foundation providing transaction management, clustering, load balancing, high availability and monitoring/management. In many ESB suites (e.g., Software AG’s webMethods Integration Server, Progress Software’s Sonic ESB), such a foundation is implemented as embedded (custom or third-party) software to which users usually do not have access. However, in other ESB suite products (e.g., IBM’s WebSphere ESB, Oracle’s Oracle Service Bus), the foundation services are provided by an enterprise application server (IBM’s WebSphere Application Server and Oracle’s WebLogic Server, respectively) that is also commercially available as a stand-alone product. Analogously, iPaaS requires a foundation infrastructure providing the cloud attributes of elastic scalability, multitenancy support, cloud transaction processing, provisioning, metering and billing. In some cases, these cloud attributes are implemented by means of embedded custom or third-party software. In other cases, the cloud attributes are provided through a high-control aPaaS, either from the same vendor or from a third party (that is, iPaaS from one provider can be implemented on top of the same provider’s aPaaS or on the aPaaS of a different provider). If an iPaaS provider wants to have maximum control over the underlying infrastructure, but doesn’t have the skills or resources to develop the cloud attributes, then it may decide to source a cloud-enabled application platform (CEAP; application infrastructure middleware providing, among other things, the cloud attributes “as a product”) from an OEM, rather than developing and running its iPaaS on a third-party aPaaS. More modern iPaaS offerings are typically implemented through a CEIP, which is essentially a software platform implementing the integration platform services, governance platform services, ancillary functions (management, administration, security) and the underlying cloud attributes of iPaaS. Therefore, iPaaS providers have implemented (through internal developments or by adopting third-party technologies) a full CEIP, or at least the integration platform and governance platform services that are then deployed on a third-party aPaaS (or CEAP). It may well be that some providers decide to make a business out of selling the CEIP underlying their iPaaS offerings to other service providers or to end-user organizations. In this way, service providers will be able 7 to implement a compatible iPaaS service, extended with their own added values (for example, to serve geographies or vertical industries that the original iPaaS vendor cannot, or doesn’t want to, target). End users may deploy the iPaaS vendor’s CEIP in their private clouds, to provide a private (or community) iPaaS to their internal users or partners. “Legacy” iPaaS Many iPaaS implementations for e-commerce B2B integration have been around for up to 10 years; thus, they have been implemented via a wide range of scalable, multitenant implementations of technology that combine high-capacity communication middleware (e.g., to support various B2B protocols), high-throughput integration middleware (e..g, to implement message transformation), community management and all the ancillary functions (security, management, etc.) required to support multiple, large-scale B2B projects on behalf of dozens, hundreds and sometimes even thousands of B2B communities, often with a broad international footprint. Most of these implementations have been modernized in some fashion (e.g., to improve availability and scalability and add new features, such as process visibility), but still combine legacy technology (e.g., electronic data interchange [EDI] mailboxes on mainframes) with modern technology (e.g., intelligence and provisioning tools running on an SOA infrastructure). Many deployments leverage geographically distributed, multisite disaster recovery capabilities, sometimes spanning multiple continents. While increasingly scalable and reliable, many of these implementations are not “pure” cloud implementations (that is, they lack cloud attributes, such as elasticity, APIs and self-provisioning). Industry Impact of iPaaS The concept of iPaaS is in its infancy, and very few vendors and users even recognize the term. However, Gartner believes that, during the next three years, a recognizable, sizable and vibrant iPaaS market will be well-established. The iPaaS Offerings Are Under Construction Evidence of the iPaaS market emergence includes, but is not limited to: • The precursor integration-as-a-service market is well- established, which proves that, technically, the iPaaS model can work; sizable (approximately $945 million in revenue in 2009), which proves that customers are willing to adopt iPaaS- style offerings; and supported by well-entrenched and powerful vendors, such as GXS, IBM-Sterling Commerce, E2open, Crossgate, Liaison Technologies and others. • Although the traditional e-commerce B2B integration subsegment of the integration-as-a-service market is only modestly expanding in terms of revenue (primarily owing to price erosion, not because of lower adoption), the cloud services integration submarket (epitomized by vendors such as Dell-Boomi and IBM-Cast Iron) is growing by double digits, although from a small installed-base, which proves there is a growing appetite for cloud services integration delivered in the form of a cloud service. • Although e-commerce B2B integration and cloud services integration are the two dominant scenarios for integration- as-a-service adoption, there are already examples of user organizations supporting on-premises-to-on-premises integration requirements, using iPaaS offerings from providers such as E2open, Hubspan and Liaison Technologies. Typically, such on-premises integration projects are implemented in conjunction with some form of B2B integration initiative. • Some traditional and open-source integration middleware vendors already deliver (partial) iPaaS capabilities (e.g., Cordys, through the Capgemini Immediate cloud services brokerage offering, based on the Cordys BOP application infrastructure platform; iWay Software, with its iWay Service Manager offering; Mulesoft, with its Mule iON offering; and Tibco Software, with its Tibco Silver PaaS offering), or have announced their intentions to enter the iPaaS market. More announcements and product releases are expected from application infrastructure middleware vendors during 2011. • Traditional data integration vendors, such as Informatica and Pervasive Software, have proven as-a-service of their traditional on-premises data integration middleware versions (Informatica Cloud and Pervasive DataCloud, respectively). • Cloud-focused startup companies and system integrators, such as Appresso, Infoteria, Jitterbit and Vigience, have entered the cloud services integration market with on-demand offerings, in addition to traditional middleware products. • In 2010, IBM acquired Sterling Commerce, one of the top two e-commerce B2B integration providers, and Cast Iron, one of the most notable emerging cloud services integration vendors. This is an indication of IBM top management’s growing perception of the iPaaS market as a strategically relevant opportunity, particularly if it successfully marries its e-commerce and cloud services integration assets to address hybrid usage scenarios. • In 2010, Dell acquired Boomi, one of the leading cloud services integration players, to expand its cloud offerings. • At PCD10 in October 2010, Microsoft announced a plan to release a technology preview of the Microsoft Azure AppFabric Integration Service in 2011. This will be based, in part, on Azure AppFabric Container aPaaS. Microsoft also announced its intention to release the Azure AppFabric Integration Service in the form of a CEIP. • In February 2011, Software AG announced its intention to release an “integration and SOA platform as a service,” beginning in 2012, as part of its PaaS strategy, which will also include process modeling, monitoring, development and execution services. These offerings will be based on the current ARIS (process modeling) and webMethods (integration and SOA 8 enablement/governance) application infrastructure middleware; however, they will be deeply re-engineered to support the cloud attributes, while maintaining backward compatibility. Software AG’s announcement is an example of the emerging consolidation of integration and governance functions in iPaaS. • Cloud services brokerage providers will be incorporating a combination of SaaS, aPaaS, iPaaS and IT services to deliver their solutions. Many e-commerce B2B integration service providers will modernize their solutions with native cloud support, governance technologies and other new capabilities to evolve into cloud services brokerages. Because many of these B2B integration service providers already contribute heavily to the multimillion dollar integration-as-a-service market, as they evolve into cloud services brokerages, they will continue to contribute to the iPaaS market. Providers Will Get Into iPaaS Along Multiple Strategic Directions The materialization of iPaaS suites will, in many cases, happen through the gradual extension and aggregation of established cloud services. For example, some integration-as-a-service vendors will incorporate governance platform services in their offerings, whereas some of the cloud messaging-as-a-service (MaaS) vendors, such as Amazon, my-Channels and StormMQ, will add more iPaaS capabilities on top of their core messaging platform services. In some cases, iPaaS will be implemented by re-engineering, refactoring and extending traditional integration and governance platforms into CEIPs. Vendors with a middleware background will initially focus on providing the integration platform service aspects of an iPaaS, whereas SOA governance vendors will primarily aim at the governance platform service capabilities. However, both classes of vendors will expand the reach of their offerings to cover more iPaaS capabilities, leading to some vendor and technology consolidation. The largest established application infrastructure middleware vendors and integration-as-a-service providers have the skills and the resources to release an iPaaS offering, providing both integration platform services and governance platform services within the next 12 to 18 months. Although, by definition, an iPaaS should be able to cover all integration scenarios, to concentrate their resources and efforts (or for historical reasons), many vendors will address only selected scenarios (for example, classic e-commerce B2B integration, cloud services integration, SOA federation or SOA governance). The iPaaS providers targeting large organizations will look at traditional on-premises-to-on-premises application integration or SOA backplane scenarios only as secondary markets. Vendors focused on serving midsize organizations are likely to also address on-premises-to-on-premises scenarios as a primary opportunity, given the level of user appetite for SaaS applications and the relatively scarce adoption of integration middleware Some application integration middleware vendors may not be familiar with cloud business models, or may not have enough resources to start up a parallel as-a-service business line; or may want to prudently move into the cloud arena without running into the risk of cannibalizing their established businesses. Therefore, these players may decide to focus on delivering the enabling technology for iPaaS (that is, a CEIP), rather than adopting an as-a-service business model. Through a variety of commercial agreements, they will delegate to third parties (e.g., IT service providers, telcos, IaaS providers, integration brokerage providers, cloud services brokerage providers and other entities) the implementation of (possibly multiple, largely compatible and competing) iPaaS services on top of their CEIPs. CEIPs will also be adopted by end-user organizations to implement private or community iPaaS, therefore slowly replacing traditional forms of integration-oriented application infrastructure middleware (e.g., ESB suites, B2B integration software and SOA governance platforms). Finally, iPaas offerings and CEIPs will be sourced from an OEM by packaged application vendors and SaaS providers to support the implementation of multienterprise business applications, or to provide their customers with a platform to address heterogeneous integration requirements (much in the same way as packaged application vendors provide integration middleware as an integral part of their products or as an option). Adoption Scenario In terms of the burning issues introduced at the beginning of this research (“How do I integrate cloud-based applications?,” “How do I integrate with my external business partners?” and “Should I use PaaS, and when?”), Gartner believes that: • Via the predecessor integration-as-a-service offerings, iPaaS already is (and will increasingly be) one of the main options available to users to connect with external business partners and to integrate cloud-based applications with their current on-premises applications. • For many user organizations, iPaaS will be the first approach to PaaS. Virtually all user organizations (large or small) must integrate applications, and, in a growing number of cases, at least some of these applications are in the cloud. New application development still takes place on a massive scale in some industry sectors (such as financial services, telecom, Web commerce, online gaming, social networks, cloud services and others), but most mainstream enterprises primarily look at packaged software and, increasingly, at SaaS as the main sources of new application functionality. Therefore, there likely will be more organizations considering PaaS, because they are looking to solve an integration problem, than there will be users evaluating PaaS for new application development. Hence, many user organizations will initially move into PaaS by adopting an iPaaS to address cloud integration issues (and also given the high cost and complexity of traditional integration platforms), rather than by selecting an aPaaS to support new developments. 9 The key factors slowing down adoption of iPaaS in the early stages of this new market will be: • Excessive market fragmentation • The sheer number of startup companies with unproven technologies and incomplete offerings • Providers shifting business models and pricing options • Security, privacy and SLA concerns • Uncertain ROI of iPaaS adoption • The inertia of the traditional integration-oriented application infrastructure middleware installed However, in the 2012 to 2013 time frame, as an increasing number of traditional application infrastructure middleware vendors enter this market, a cycle of consolidations, mergers and acquisitions will kick off. The emergence of relatively few large iPaaS “suite master” providers, supported by a large partner ecosystem (providing services that are colocated and integrated with the “master” iPaaS), will bring more confidence to mainstream user organizations, and widespread adoption will take off as large organizations adopt iPaaS (public, private or community) to support a wider variety of project types, not just for a few selected use cases. Until that happens (circa 2015), iPaaS will mostly be a market for leading-edge users and midsize companies, as well as a complementary opportunity (e.g., for e-commerce B2B integration, cloud services integration or SOA governance) for mainstream organizations. For most large organizations, the coexistence of possibly multiple iPaaS and traditional application infrastructures will be the norm. Therefore, established integration competency centers/SOA COEs will have to face the challenge of supporting technology, organizational and governance federation of their established integration and/or SOA backplane infrastructures with iPaaS. The convergence and consolidation process toward iPaaS will be turbulent. Many providers will disappear; in the race to leadership, vendors will bring to market immature technologies; some mergers and acquisitions will fail; some vendors will not be able to effectively scale up their platforms to support large cloud workloads; and other vendors will struggle to provide quality support to a growing number of clients. Along with analyzing an offering’s functional and nonfunctional fit with their requirements, user organizations considering iPaaS should carefully evaluate vendors’ track records in their vertical sectors and geographies, as well as the providers’ ecosystems, to minimize the risks and maximize the benefits of iPaaS adoption. Waiting too long for the maturation and consolidation of the market may be dangerous for organizations as their competitors move ahead with leveraging iPaaS to try to reduce costs, improve efficiency and creatively build competitive advantage. In the trade- off between technology and vendor risks and improved efficiency and efficacy lies the key to successful iPaaS adoption. </p>