• 25 Feb 2019
  • 8 Minutes to read
  • Contributors
  • Comment
  • Dark
  • PDF


  • Comment
  • Dark
  • PDF

Article Summary

Integration Platform as a Service (iPaaS) is one of the key areas of interest to most companies currently in the integration space. The analysts are talking a lot about how iPaaS will help companies to be successful in the Digital Transformation world and vendors are desperate to tell you how their product stack is the best iPaaS offering available.

Recently I was looking at some of the market information in relation to vendors iPaaS offerings and what struck me is that there is a lot of high level fluff about the topic but when you drill down I think the iPaaS area is still immature in its definition of what iPaaS is and what a vendor needs to offer to be considered an iPaaS vendor and also how companies should use one to be successful.

In this article I would like to attempt to demistify some of this thinking and try to explain how the Microsoft platform stacks up against the requirements of an iPaaS.

What is iPaaS?

For a number of years companies had been aligning their Integration approaches towards Service Orientated Architecture (SOA) and Enterprise Service Bus (ESB) based approaches. There had been mixed levels of success with these approaches but the disruption of IT caused by the adoption of Digital Transformation, Agile and the API boom created a problem that ESB/SOA approaches were typically too slow to keep up with the pace of change required.

At the same time cloud adoption was growing and the services offered by cloud providers offered new paradigms for solutions to old problems.

I would suggest that the combination of these two drivers lead to the point where integration was reinvented.

While the old problems did still exist, there were also new problems and new levels of scale that enterprises needed to deal with so there was absolutely space in the eco-system for something new to help us deliver solutions.

iPaaS was the thing to fill this gap. iPaaS aims to offer a cloud platform which contains services which you can use to create solutions to integration problems.

The key differentiator is that for older integration platform technologies there was often a big investment in infrastructure and foundation activities which made it difficult for customers to be successful and also made the total cost of ownership of an integration platform high. iPaas attempts to tackle these core problems by off loading them to the Cloud Provider so that the business can focus on using the service to solve business problems.

Once we are in this place we have an integration platform which helps us build solutions that is aligned to the desires or agile, digital transformation and bi-modal IT.

What should an iPaaS do?

An iPaaS should make it easier to do integration compared to solutions you have used previously (and in particular on-premise).

From a core use case perspective, Its really that simple!

Now in the real world its still possible that you may have a mixture of different kinds of problems and things to deal with. Many companies will likely combine an iPaaS with their other existing Integration assets so that they can offer solutions to meet different requirements but having a light-weight integration approach which can still solve complex problems is absolutely something most companies want.

In terms of features however an iPaaS should do the following things:

  • Make it easy to connect to SaaS applications
  • Make it easy to work with API's
  • Allow me to create a workflow across connections to systems
  • Support connecting to on-premise and cloud resources

Another interesting area which is booming at the moment surrounds the concept of the democratisation of integration. This means that I can extend my team to include non-integration specialist resources working on integration projects. With ESB and SOA implementations I usually need specialist resources in terms of experience or product skills. With iPaaS the learning curve should be small and it should be easy to get a general-purpose developer to work on integration stuff.

What shouldn't an iPaaS do?

An iPaaS should be easy to use. It should be something I can setup easy and the time from me starting to the time I can successfully connect to an application should be small.

One of the biggest issues with some iPaaS vendors is they dont support a quick ability to get started. Any vendor who requires me to speak to a sales team should be frowned upon.

There is also a move with some vendors towards consumption based pricing. I think flexible choices are a good thing. With some vendors its possible to solve a problem for the price of a cup of coffee. Being able to run your iPaaS as an operational expense supports the digital transformation angle well. Large capital up front costs and repeatedly having to engage with vendors are all things your iPaaS may suffer from which could limit the percieved benefits of the technology and approach.

Key Features of an iPaaS

If we consider what are the typical features an iPaaS should have we can break them down into a few areas.

Area 1 - Basic / Core Features

  • Connectivity to applications
    • Line of Business applications
    • SaaS applications
  • Support for data formats
    • XML/JSON
  • Data mapping and transformation
  • Message Routing
  • Orchestration and workflow

Area 2 - Enterprise Requirements

  • API Management Support
  • Message Broker for advanced enterprise scenarios
    • Durability/Replay/Recoverability

Area 3 - Development and Management Experience

  • Application lifecycle management
  • Operations and management

Nice to have features of an iPaaS

There are also a few areas of features which an iPaaS may include but these are often for specific use cases which may apply to some companies but not others. Some examples of these are below:

  • B2B support for EDI, EDIFACT, HL7
  • IoT support for AMQP, MQTT, Kafka

Microsoft Technology that is iPaaS

At this point we have discussed the background to iPaaS, what an iPaaS should look like and some of the key things for success and failure.

Next I would like to look at some of the Microsoft technologies which I feel work together to belong to the Microsoft Integration Platform as a Service offering.

Logic Apps

Logic Apps are the core iPaaS component from Microsoft. On their own they can solve many problems. Logic Apps provides the enterprise scale hosting and workflow to allow you to orchestrate across API calls and application connectors.

Integration Account

The integration account allows you to add additional enterprise and B2B features to your solution if you need those scenarios.

Azure Service Bus Messaging

Service Bus messaging provides the message broker capabilities. Being able to do durable pub/sub messaging alongside your workflows allows you to do many more scenarios than just workflow on its own.

Data Gateway

The data gateway allows your solution to reach on premise resources.

Event Hubs

Event hub provides a durable stream to send messages to for highly robust message scenarios supporting things like telemetry and IoT scenarios.

Event Grid

Event Grid supports an event driven architecture where your event sources can publish events and your iPaaS-Workflow can be a source or consumer of events

API Management

API Management allows you to add mature governance and management to any API interfaces you want to use with your iPaaS. These could be API you expose or consume.

Azure Functions

Functions are the ultimate extensibility points where you can add custom code to extend and compliment out of the box features.

Data Factory

Sometimes your integration platform will need data integration scenarios beyond what can effectively be implemented by an ESB or Message Broker style approach. In these cases Azure offers Data Factory which can easily be added to your integration platform to help you.

API Connectors

With API Connectors you have a framework to compliment out of the box connectors to build your own or to share open source ones.

Microsoft Flow

If we consider the Citizen Integrator scenario and take the democratisation of integration concept further then we also have Microsoft Flow available in the platform for those business user driven workflows.

Application Lifecycle

The original requirements for an iPaaS said that there should be ALM tooling for development and fortunately in the Microsoft eco-system we have some of the best available with Visual Studio, Azure DevOps for Source Control, Continuous Integration and Continuous Deployment and also Microsoft Teams to allow your team to collaborate on the project.

Microsoft iPaaS

If we put the services together in one diagram then the Microsoft iPaaS offering looks like the below diagram:


A few of the things that are really great about this offering include:

  • For most if not all of the services there is a consumption price model meaning you can get started for a tiny cost with no big monthly commitment

  • All of these services can be spun up with just a few clicks and no need to speak to anyone at Microsoft

  • In addition to the core services in the Microsoft iPaaS there are always cases where you need something else to complement your solution. In the Microsoft platform scenario the win is that you can add other Azure services within just a few clicks. Some examples of what you might need include:

    • CosmosDB
    • SQL Azure DB
    • Cognative Services Sentiment Analysis
    • Machine Learning
    • The entire Microsoft Business Intelligence offering on Azure

Microsoft Gaps and Challenges

I dont think Microsoft has any gaps in the platform but I think the biggest challenge for customers is that the services are all individual and delivered on the Azure platform in a way that supports a cloud platform which is more than just an iPaaS vendor offering. Customers can bring in the services they need for many kinds of solution.

Withi this in mind I think its sometimes difficult if you are an Azure user to explain what is your iPaaS because its just a subset of so much more on Azure. I dont think Microsoft have effectively articulated which bits of Azure make up the iPaaS offering or present them in a way which makes it easy for analysts like Gartner or customers to be able to see an iPaaS within Azure. All too often they just think Logic Apps is the iPaaS but its more than that.


Hopefully this article has helped to explain how the Microsoft technology stack on Azure relates to what the industry expects from an iPaaS offering and you can now explain to your organisation what your iPaaS looks like.
Im sure you will agree that when you look into the detail the Azure offering is very compelling and offers features to solve many kinds of integration problems to help you be successful.

Was this article helpful?