Is integration platform as a service right for you?

Somewhere in Slack, Zoom or Microsoft Teams, you overhear a strange conversation between the directors of software development and infrastructure about whether the company can support iPaaS. At first, you confuse it with a toll-booth technology. As the conversation intensifies, you consider that someone else who doesn't know what iPaaS is might tell you to implement this abbreviation. You resolve to find out more before it's too late.

Integration platform as a service (iPaaS) is a technology to integrate an organization's web servers, data infrastructures, middleware and other systems, including cloud-based, on-premises and even local and mobile devices. Development teams use iPaaS to speed up integration flows, connect components and define interactions in ways that suit business rules.

Take the time to understand why iPaaS is popping up in strategic IT discussions, what problems iPaaS solves and the challenges it introduces.

When should you use iPaaS?

Use iPaaS when you need to deploy or connect software that exists on different platforms. Any sizable organization has software that runs on premises, as well as third-party, cloud-based software that exposes APIs. Organizations might also run software in a private cloud such as OpenStack, or in a public cloud.

The goal for iPaaS is to provide an easy, often front-end way to coordinate information exchange between systems, including cross-environment migrations. The platform provides a single, consistent management view, management dashboards and monitoring tools. In some cases, it can add a management view over the servers to help control spending.

IPaaS enables a team to add a new capability in IT, manage a disparate range of environments, use systems across environments with predictable costs and standardize cloud adoption.

Companies that struggle to document the numerous integration points spread across software systems can find an answer in iPaaS. For example, organizations set up multiple web servers and back-end systems to support mobile software, electronic data interchange, payment processing, HR and third-party software in tandem with each other. In some cases, those integrations require special tunnels or firewall rules, which further increases implementation and operational complexity.

IPaaS can create a trigger: When an event happens, other systems are notified and integrations updated as needed. To the programmer, this is a one-time integration flow setup, perhaps through a visual interface. The iPaaS platform needs to be aware of the protocols, as well as if the technology is push or pull, if it uses API or webhooks, and if messages pass through a queue or service bus.

Shadow IT and iPaaS

Another use of iPaaS is a way to rein in shadow IT, which has surged with the rise of cloud-hosted resources. Modern workers and managers now can easily obtain SaaS -- and even entire server infrastructures and application stacks -- with just a few mouse clicks and a corporate credit card. If there is no standard way to add software in an organization, groups figure it out for themselves which creates redundancy, excessive costs and integration problems.

A proper iPaaS integrates the view of these many technologies through tools and standards, and unifies the data picture. IPaaS gives the company a list of the various systems, what they do and how they integrate. Before signing up that new SaaS cloud analytics product, the marketing department at least will ask how to integrate it -- and might find that another business unit has already purchased and integrated a similar tool. That prevents yet another one-off tool with data held captive by a vendor, with manual hand-offs and likely double entry.

Consider iPaaS adoption to help convince departments to work with IT rather than go it alone with a shadow IT option. Even if they do, iPaaS provides tools to make that integration nearly seamless and self-service.

Alternatives to iPaaS

An iPaaS is a separate, independent, third-party set of middleware designed to connect systems and pass messages back and forth using standard protocols. IPaaS vendors may create plugins to make integrations easier.

Meanwhile, major vendors such as Microsoft, Google, Amazon, Oracle and SAP offer their own integration products or integration plugins that offer similar services and capabilities, while not strictly defined as iPaaS. Some of these products are more piecemeal, providing technology for an enterprise to integrate applications built within the vendor's cloud infrastructure. For example, for event-routing and third-party integration, Amazon offers AppFlow, Amazon EventBridge and Amazon Simple Notification Service. Amazon has Amazon MQ and Simple Queue Service for messaging; Microsoft Azure has Event Grid, Queue Storage and Service Bus, while Google's Pub/Sub tool builds messaging and routing in the cloud.

These integration tools run within a public cloud to integrate applications within that public cloud -- they won't deal with on-premises, multi-cloud or external SaaS tools. A cloud-native business that chooses a single platform and has no data center could consider this approach, but a company that needs on-premises integration may be better served with iPaaS.

Plan for iPaaS

Companies that choose the iPaaS route or cloud integration tools still need someone, or a team of people, to manage the software. Because iPaaS is "as a service" and runs in the cloud, its development costs are split between dozens, hundreds, or thousands of organizations. That means the provider can focus R&D spending to create easy, point-and-click, drag-and-drop discovery and integration -- and architects and administrators can focus on process and change management.

There are challenges to consider in your iPaaS plans as well. If iPaaS adoption grows, the visualization of the data flows can become a kind of living documentation on how services communicate in the organization. A lack of support from other groups or organizational structure may limit iPaaS to only a sliver of its potential value. An organization may explore iPaaS for overall systems integration needs, only to discover dependencies on older systems that are difficult to configure with iPaaS because they have no APIs and exist through files and batch jobs.

These roadblocks mean iPaaS can fall short of its promises of visibility and savings, and become just another technology to manage technically and financially. Examine what your team and the organization overall need to do and if the iPaaS tool can do it. Then, plan and experiment with the tool to see if it performs as needed.

It isn't easy to adopt iPaaS. The process could take tens of thousands of dollars or a few thousand hours of work for a large conglomerate, perhaps a fraction for a company with a single business unit. That's still a lot cheaper than blindly making the wrong decision, and could simplify how you run your organization's IT and business systems for years to come.