BACKGROUND IMAGE: stock.adobe.com
You're walking down the hall when you can't help but hear a conversation in the VP's office. The director of software development asks the director of infrastructure if he can support iPaaS. The first two times he says it, you confuse it with a toll-booth technology. As the time you spend at the office door becomes awkward, you can't help but think: "Great. Is someone who doesn't know what iPaaS now going to tell me to implement this new abbreviation? I wonder what it is."
Integration platform as a service encompasses server and data infrastructures, middleware and other software tools to build, test, deploy and manage software applications in the cloud. Development teams use iPaaS to speed up integration flows, connect components and define interactions in ways that suit business rules.
Whether or not you're under pressure to implement iPaaS, take the time to understand why it's popping up in strategic IT discussions, what problems it solves and the ones it introduces.
When should you use iPaaS?
Use an integration platform 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 software rented as a service that, hopefully, 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 offer a centralized and effective way to manage and coordinate all kinds of software and servers, including cross-environment migrations. The integration platform provides a single, consistent management view, along with dashboards and monitoring, and can help control spending.
Integration platform as a service 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. Several examples demonstrate the value of iPaaS.
IT resources management
Many organizations cloud-burst applications, meaning that they scale instances from on-premises servers that handle normal load up to cloud servers that take on unusually high demand, as for Black Friday shopping on an e-commerce website. Organizations need a management layer that facilitates the transition from on-premises to cloud resources, typically via an enterprise service bus (ESB) or service-oriented strategy. With iPaaS, the organization can essentially rent an ESB in the cloud.
Adopters even find migration between cloud vendors less difficult with iPaaS, as long as the cloud vendor uses a standard image deployed over a standard management layer.
Companies that find it difficult to document their numerous, diverse software and integration points can also find value 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, further increasing implementation and operational complexity.
Common causes of complexity
There isn't a single profile of an IT organization that should adopt iPaaS. Complexity emerges whether software teams choose to use a complete, cohesive platform or decide to string together a hodgepodge of software.
When sizable software development groups all work on the same platform, they almost invariably encounter integration and coordination challenges. These groups struggle to create test environments and integration environments because they step on each other, lack a way to visualize the entire system and either have to write a great deal of custom code that doesn't work for everyone or have each team essentially reinvent the wheel when they create custom solutions internally.
On the flip side, other IT organizations grow over years through a mix of acquisition and internal development and end up with many teams working on a range of different platforms. These teams typically support legacy software through cloud-native products. They also work through the range of integration levels that exist between their various platforms.
IPaaS doesn't pick sides when it comes to these scenarios. If software teams find themselves in either situation, the iPaaS approach might be the way to go.
A range of software implementations can spell conflict. Organizations often integrate external software with an internal directory, like Lightweight Directory Access Protocol. Certain teams rely on SaaS tools, such as Dropbox and LeanKit, for productivity. Corporate departments can have conflicting and overlapping software programs, including multiple versions of the same product, or licenses purchased in different groups or at different times. It's easy for an individual manager to pick up a SaaS offering with a corporate credit card, untracked as part of the company's IT spending.
A proper iPaaS can unify the view of these many technologies. Once installed, iPaaS gives teams one or a few standard ways to produce cloud services. An iPaaS implementation makes it easier to create a new web team or even a new corporate division or product, for example. It simplifies purchasing, making IT spending more transparent. The CIO needs a single place to see infrastructure spending, and iPaaS can deliver that.
Shadow IT and iPaaS
Shadow IT has evolved with the rise of cloud-hosted resources, to the point where modern workers can pay individually for software and even entire server infrastructures and application stacks.
IT and software managers can combat shadow IT by standardizing. If there is no standard way to add software, groups figure it out for themselves -- probably at a high cost. If ramping up a new team means creating yet another cloud architecture from scratch and it takes nine months to get anything to first demo in the cloud, then you have a problem that opens the door for shadow deployments.
Consider iPaaS adoption to make it more appealing for departments to work with IT than to go it alone with a shadow IT solution.
Plan for iPaaS
Someone -- or a team of people -- must manage iPaaS. The technology must fit with other existing systems, so architects and administrators should focus on process and change management.
If iPaaS adoption grows, it can consume the existing groups that manage servers and systems, leading to an organizational change at a fairly high level in the company. There might be political or change management problems that prevent iPaaS from taking over all aspects of IT, which relegates the technology to managing some small percentage of systems, such as only the cloud-bursting setup for the company's customer-facing application.
Whether iPaaS belongs in an IT organization also depends on the company's overall readiness for cloud computing. If your company still uses strictly on-premises infrastructure with chipsets or OSes that are not cloud-compatible, then you might not be able to manage or migrate those workloads at all with iPaaS.
These roadblocks mean iPaaS can become yet another ongoing technology to manage and pay for, without the savings or visibility promised.
Examine what your team and the organization overall need to do and if the iPaaS tool can do it. Then, plan and conduct an experiment to test if the tool performs as needed.
It isn't easy to adopt iPaaS -- the process could take thousands of dollars and a few hundred hours of work, but it's still a lot cheaper than blindly making the wrong decision.
The author would like to thank Joe Knape for his excellent peer review.