Digital Integration Platforms: The vendor landscape

RESEARCH REPORT // FREE
 
The Digital Integration Platform vendor landscape is really crowded: a mix of startups, specialists with significant experience and ‘heritage’ enterprise platform vendors are all busily trying to get your attention. Which kinds of vendor and service offering are going to be best-aligned to your needs?

Top takeaways

The capabilities of Digital Integration Platforms are largely a function of vendor heritage

There are three broad groups of vendors offering Digital Integration Platforms today, all competing for attention:

  • Personal Integration specialists (like IFTTT and Zapier) are ‘born on the cloud’ and design their offerings to make relatively straightforward application integration work as simple as possible.
  • Integration System specialists (like Boomi, MuleSoft and Scribe Software) are very different: these companies initially started as on-premise integration technology providers focusing on cost and ease-of-use, in opposition to broad enterprise platform vendors; then jumped to the cloud. Their propositions are principally focused on openness and choice.
  • Broad enterprise platform vendors (like IBM, Software AG and TIBCO) have reacted to the success of the other two groups, and built cloud-based offerings that avoid cannibalising their existing businesses as far as possible. As a result, their products typically share more ‘design DNA’ with the offerings of the Personal Integration specialists, than they do with the products of the more sophisticated Integration System specialists.

Navigate the vendor landscape by asking “who, what and where” about your integration requirements

Although much of what all Digital Integration Platforms provide has a consistent basis – for example all the tools provide graphical, drag-and-drop designer interfaces; all provide at least part of their platforms from a vendor-controlled cloud environment – there are significant differences when you look a bit deeper.

In order to navigate the vendor landscape, and then to help you draw up a supplier shortlist, you should explore three questions relating to your current and future integration requirements that will require you to have architectural input as well as business change input. First, who (in terms of roles) do you need to take responsibility for designing and managing integration services? Second, what is the scope of your integration requirement – in terms of integration styles (data integration vs functional/API integration, and in terms of integration complexity? And third, where is the ‘centre of gravity’ of the integration work you need to do? Is it important that you can deploy integration services within your own data centres? Do you need to be able to execute integration services on a variety of cloud platforms?

­­­

Digital Integration Platforms: the story so far

A collision of startups and enterprise behemoths

As we highlighted in our companion report What are Digital Integration Platforms and why are they important?, over recent years, a new wave of platform and application endpoints has created a new wave of demand for technology integration – driven primarily by investments in mobile application platforms and software-as-a-service properties from the likes of Salesforce, Workday, NetSuite and more.

Enterprises’ steady progression to embrace cloud-based services and mobile application platforms over the past decade has been driven in large part by business teams rather than by IT departments, and the requirement for integration has followed the same pattern.

The market for Digital Integration Platforms (see definition below) was born:

Digital Integration Platforms enable teams to work together to design, deploy, operate, monitor and change integration software services that connect business applications, data sources and other software platforms – wherever they may be hosted. Digital Integration Platforms are delivered as-a-service, licensed on a subscription basis and priced according to usage.

It’s no surprise that Digital Integration Platforms tend to major on speed and simplicity – aiming to provide facilities for ‘citizen integrators’ (analytically-minded business professionals, rather than specialised software technologists); and moreover, it’s no surprise that we see the pattern of vendor involvement we’re seeing: a cluster of specialist vendors offering purpose-built tools aimed squarely at ‘citizen integrators’, pitched against a cluster of more established enterprise technology platform vendors retooling their core heritage integration technologies to address this new set of use cases.

It’s important to realise that although the Digital Integration Platform marketplace has really only ‘caught fire’ over the past couple of years, a number of vendors have been providing Digital Integration Platform offerings for much longer. With that in mind, in order to introduce the main players in the Digital Integration Platform technology vendor landscape, in the sections below we’ll highlight their roles in the development of this market.

First, a group of integration system specialists jumped to the cloud

The Digital Integration Platform market first began to crystallise as a small group of specialist integration vendors, already focusing particularly on speed and simplicity, launched cloud-hosted service versions of their products. For example Boomi (founded in 2000, now owned by Dell) launched AtomSphere as a cloud-based integration platform in 2007; MuleSoft (founded in 2006) first launched cloud integration capabilities in 2012.

Personal integration specialists enter the fray

As a new wave of SaaS-based marketing automation offerings really began to take root in small-to-medium sized businesses in particular, a new wave of cloud-native startup vendors entered the market with a focus on extreme simplicity through ‘plug-and-play’ experiences. They were partly able to do this thanks to the simplicity and openness of the application programming interfaces (APIs) that SaaS-based marketing automation offerings invariably provided (and still provide).

IFTTT (founded in 2010) and Zapier (founded in 2011) have been at the heart of this. The tools provided by these vendors are pitched as much personal productivity tools as they are pitched as integration tools; the technical plumbing associated with application integration is in many cases almost completely hidden from service users.

The broad enterprise platform vendors join the party

The arrival of IFTTT and Zapier provided a catalyst for established integration system specialists to step up their efforts, and it also drove vendors of broader enterprise platform (IBM, Oracle, Software AG, TIBCO and similar) to jump into the marketplace.

In a way this isn’t surprising; given their existing investments in on-premise platforms (and customer bases familiar with on-premise platforms) their primary goal for many years was to put off making a shift to the cloud for as long as possible.

At the same time, though, these vendors are keen not to be caught out by a rapidly shifting market – and as a result, over the past two years they’ve made rapid directional shifts in order to launch cloud-first integration platforms with (varying degrees of) citizen integrator-friendly tooling.

Navigating the technology landscape: who, where, what

With such a crowded marketplace, it’s important that we distinguish between vendors in a way that addresses their suitability for particular kinds of usage scenarios.

We chart the Digital Integration Platform technology landscape using a model that’s built by asking three questions about the kind of work you might want to carry out with a Digital Integration Platform. First, who do you anticipate will carry out, and take responsibility for, the work of building integration services? Second, where does it make most sense for integration services to run, and where does it make most sense for the integration tools to be hosted? Lastly, what’s the scope of the integration work you’re likely to want to carry out?

We address each of these questions in detail below.

Who creates integration services: generalists or specialists?

Although the standard pitches from the Digital Integration Platform vendors all include a focus on ‘citizen integrators’ and emphasise speed and simplicity of integration service development, in truth there are quite wide variations in how different vendors’ tools actually perform in practice.

In your organisation, are you aiming to put tools squarely in the hands of ‘citizen integrators’, or do you anticipate that professional technologists will drive the integration work you want to do (perhaps with a certain degree of input from businesspeople)?

At one end of the scale, we find tools that have speed and simplicity as their central design goal. These tools are usable by anyone with a modest degree of analytical skill; they typically provide step-by-step, simple interactive instructions to help you build simple integration services with minimal effort. At the other end of the scale we find tools that lay all the technical details out in the open, enabling trained technical specialists to create very sophisticated sets of integration services – but effectively locking out meaningful contributions from non-technical stakeholders. In addition, a growing number of vendors offer a combination of tools: one tool aimed at technical professionals, who create and package reusable integration service components; and another tool aimed more at citizen integrators, who compose and configure these integration service components to address particular use cases.

Where’s your integration centre of gravity?

All Digital Integration Platform vendors will emphasise how their tools and platforms enable you to integrate popular SaaS offerings those from Salesforce, NetSuite, Workday, and so on. But in truth, some vendors’ offerings are more ‘cloud-centric’ than others.

There are two aspects from which to consider this question: firstly, the location of the tools you’ll need to use; and secondly, the location(s) where the resulting integration services can be hosted. When you look at your integration needs, is the ‘centre of gravity’ of integration work within your corporate firewall, in a data centre that’s dedicated to you; or is it in the public cloud (or potentially multiple public clouds)? Is it important to you to be able to use a toolset that’s widely accessible from multiple locations, so multiple groups of stakeholders and contributors can be directly involved in your integration work? Or is it more important that your tools are run in a private environment? Do you want the opportunity to run and manage integration services that might connect multiple on-premise systems with each other, within your own corporate environment? Or is the value of a purely cloud-based platform worth any compromises on that score?

At one end of the scale, we find tools that are seamlessly hosted and packaged along with a runtime integration platform, and only available within the vendor’s own cloud environment. You can only develop in the vendor’s cloud, and you can only run integration services in the vendor’s cloud. At the other end of the scale, we find tools that enable developers to build integration services on their own computers, and deploy them behind a corporate firewall, or on any of the popular public cloud services (AWS, Azure, Google Cloud Platform).

What’s the scope of your integration ambition?

As anyone with a heritage in integration technology will know, ‘integration’ is not one thing. There are multiple styles of integration work you might need to carry out, with each style suited to a particular kind of requirement. This has always been the case in the past, and it’s still true today.

There are two aspects to this question that you should consider.

Firstly, there’s the issue of the dominant style of integration you need to support. Do your candidate integration use cases revolve primarily around the ability to call functions exposed by application APIs (or via application adapters) – in order to trigger actions in those applications? Or do your candidate integration use cases revolve primarily around the importance of moving data from one place to another? Or perhaps you need a mixture of both capabilities?

Secondly, there’s the issue of integration service complexity. Does your requirement primarily focus around connecting together well-known and widely-used applications that have well-documented and openly-published APIs? Or do some of the resources you need to integrate require more proprietary integration methods, which means that you’re going to need to hand-craft integration adapters or find a tool that offers such adapters? Is it enough to be able to invoke built-in common data handling functions (such as functions for field concatenation, text manipulation, date handling, text substitution and so on) or are you likely do you need to do more – for example following complicated rulesets to make automated decisions that guide processing, or aggregating data or performing other functions that act across large sets of data records? Are you likely to need your integration services to be able to orchestrate the invocation of functions (or the passing of data) across groups of applications or systems in sequence, with the sequence depending on the data that’s being worked with?

At one end of the scale we find tools that are focused very firmly on implementing relatively simple ‘point to point’ connections between applications that have open, well-documented APIs. A typical scenario these tools are ideally suited to would be ensuring that high-scoring leads captured from an online marketing automation tool like Marketo are added as opportunities in Salesforce Sales Cloud. At the other end of the scale we find tools that are designed to make it possible to create many-to-many networks of applications, all of which publish events that other applications can react to (taking action, ingesting data, and so on, as relevant). Some tools’ ‘sweet spots’ are more focused on data movement and synchronisation, rather than function-calling – for example providing tailored facilities that make it easy to stream data from collections of connected devices or transactional databases, transform and enrich that data, and then pass it to a traditional data warehouse or a data lake (potentially in the cloud).

Where different vendors play

Having summarised how the market for Digital Integration Platforms has developed, and provided an overview of the vendor landscape based on the ‘who’, ‘where’ and ‘what’ of modern integration requirements, let’s look at how different groups of vendors play in this landscape today.

Our Digital Integration Platform vendor landscape model

Figure 1 shows our model for today’s Digital Integration Platform vendor landscape. There are four dimensions we use:

  • The range of personas supported in integration service development – from ‘citizen integrators’ (top of figure 1) to technology professionals (bottom). In our positioning diagrams for vendor groupings (see below sections) we highlight the range of personas supported with vendors’ Digital Integration Platforms.
  • The range of development and deployment location options for your integration services – from local, on-premise hosting (bottom-left) to vendor-provided cloud hosting (towards top-right), to support for multiple public cloud options (far top-right). In our positioning diagrams for vendor groupings we highlight the range of deployment locations available.
  • The range of integration scenario sophistication that’s supported by the platform – from simple, plug-and-play, direct point-to-point connectivity (left) to complex, orchestration- and transformation-heavy integration (right). In our positioning diagrams for vendor groupings we highlight the range of integration scenarios supported.
  • The range of integration styles supported – from function-/API-calling (top-left) to data movement and synchronisation (bottom-right).

Figure 1: Four dimensions for positioning Digital Integration Platform vendors

Source: MWD Advisors

Personal integration specialists focus on simplicity, immediacy

The typical positioning and capabilities of the ‘Personal Integration’ players (like IFTTT, Zapier and Microsoft’s Flow) is shown in figure 2. The light orange shape shown on the chart shows the extent and positioning of the general platforms. As you can see from the chart, overall these vendors are:

  • Very firmly positioned to support citizen integrators, rather than technical professionals.
  • Designed to deliver both design-time tools and operational support for integration services from the vendor’s own cloud (but not anywhere else).
  • Almost exclusively focused on supporting the function-/API-calling integration style (rather than supporting data movement/synchronisation use cases).
  • Designed very clearly to support the ‘plug-and-play’ integration of popular, openly-accessible applications and systems.

Figure 2: Personal integration players focus on simplicity, immediacy

Source: MWD Advisors

A variety of integration system specialists focus on simplicity, but offer deployment choices and extensibility

The general positioning and capabilities of the variety of integration system specialist vendors active today (like Dell Boomi, Jitterbit, MuleSoft, Scribe Software and SnapLogic) is shown in figure 3. Note, though, that there is significant variation within this group – see below.

Overall, though, the light orange shape shown on the chart shows the general extent and positioning of these platforms. Overall these vendors are:

  • Primarily promoted to appeal to citizen integrators, although they typically also offer specialised tools (to aid customisation and extensibility) aimed at technical professionals.
  • Designed to deliver design-time tools from the vendor’s own cloud, but typically offer multiple choices regarding integration service deployment – from on-premise/private cloud, to the vendor’s own cloud, to other popular public cloud platforms (including some combination of AWS, Azure and Google Cloud Platform).
  • Able, as a group, to address both function-/API-calling integration use cases and data movement/synchronisation use cases.
  • Designed to support the ‘plug-and-play’ integration of popular, openly-accessible applications and systems, while at the same time enabling customers with more complex requirements to build and manage portfolios of reusable integration components.

Figure 3: Integration system specialists focus on simplicity, but offer deployment choices and extensibility

Source: MWD Advisors

As mentioned above, there are some significant variations in this vendor grouping that are worth calling out specifically:

  • Informatica’s Integration Cloud supports both functional and data integration use cases with a mix of technical (on-remise) and ‘citizen integrator’ (cloud-based) tools. A BPMN-enabled Process Server also provides stateful API/service orchestration features.
  • Jitterbit’s Harmony Platform includes API development and management functionality as well as core integration functionality, and promotes this combination principally as a platform on which customers enable, and then compose, API-wrapped systems to support new application and digital product development. Its development tool aimed at technical specialists, Studio, is something you run on developer workstations; its Citizen Integrator tool is hosted online on Jitterbit’s cloud service.
  • MuleSoft’s AnyPoint platform offers both a cloud-hosted version with cloud-hosted tools (CloudHub) and an on-premise version. Technical tools are Eclipse-based. As with Jitterbit, MuleSoft positions its AnyPoint platform principally as a way for clients to wrap and extend existing systems, publishing and managing APIs on which new application and product functionality can be developed.
  • SnapLogic’s platform supports both functional and data integration use cases equally well. It also enables you to deploy integration services on its own cloud, on-premise or on third-party public clouds.
  • Xplenty’s platform is designed specifically for data integration use cases, and both its design tools and your deployed integration code run on Xplenty’s own cloud service.

Broad enterprise platform vendors fit around their existing portfolios, try to appeal more widely

The typical positioning and capabilities of broad enterprise platform vendors with ‘heritage’ integration offerings (like IBM, TIBCO, Software AG and Oracle) is shown in figure 4. The light orange shape shown on the chart shows the extent and positioning of the general platforms; the location of the red circle shows where the platform’s design and management tools are hosted. As you can see from the chart, overall this group of vendors’ offerings are:

  • Positioned to support citizen integrators in some situations, although they typically require that technical professionals get involved to some extent.
  • Designed to deliver design-time tools remotely from the vendor’s own cloud platform; and also likely to offer limited choices regarding integration service deployment – the primary deployment location is the vendor’s own cloud platform, and there’s sometimes support for on-premise/private cloud deployment.
  • Primarily focused on supporting the function-/API-calling integration style (rather than supporting data movement/synchronisation use cases).
  • Designed to support the ‘plug-and-play’ integration of popular, openly-accessible applications and systems, while at the same time enabling customers with more complex requirements to build and manage portfolios of reusable integration components.

Figure 4: Enterprise platform vendors play to their strengths, try to appeal more widely

Source: MWD Advisors

It’s worth noting that there is some variation in the positioning of these vendors’ offerings, although there is a fair degree of commonality:

  • IBM’s App Connect platform provides tools from its own cloud, rather than requiring you to run them on-premise. Deployment of integration services is also restricted to IBM’s own cloud platform. App Connect Personal fulfils simple plug-and-play connectivity requirements relatively well; App Connect Professional (formerly known as Cast Iron Live) provides options for technical professionals.
  • TIBCO’s Cloud Integration platform provides tools from its own cloud, rather than requiring you to run them on-premise. Deployment is also restricted to TIBCO’s own cloud platform. However its support for plug-and-play integration is stronger than shown in figure 4.
  • Software AG’s webMethods Integration Cloud provides tools from its own cloud. Deployment is also restricted to Software AG’s own cloud platform. Software AG’s CloudStreams product also enables you to connect on-premise webMethods Integration Server instances with Integration Cloud, although you can’t manage on-premise services from Integration Cloud this way.
  • Oracle’s Integration Cloud Service provides tools from its own cloud, and deploys only to its own cloud platform (although it can implement secure connections to on-premise apps when you need them). Plug-and-play connectivity is well-supported with a library of pre-built integration templates (particularly aimed at integrating Oracle applications with each other and with others).

As you can see from figure 4 and comparing it to the other diagrams in this report, the enterprise platform vendors tend to be working in the confines of their existing integration portfolios, not wanting to cannibalise their existing offerings too much. They’ve built (or are building) offerings that stand up to some comparison with those of the personal integration players (figure 2), but in some key respects – particularly relating to support for different deployment options – they are challenged to match the flexibility of the pure-play functional or data integration specialists (figure 3).

An outlier: Capgemini

In a marketplace dominated by companies with traditional product-centric business models, Capgemini stands out. It’s launched the Capgemini Enterprise iPaaS: a pre-packaged stack of open-source integration technologies that it hosts and provides as a managed service.

Enterprise iPaaS is aimed at technical specialist teams, and is specialised to meet functional integration needs (rather than data integration needs). Crucially, Enterprise iPaaS can be hosted on AWS, Azure, Google Cloud Platform or Openstack.

Download PDF version
RESEARCH REPORT // FREE