Digital transformation requires cloud appropriate adoption, legacy IT systems modernization, and Agile-based methodologies for faster innovation. SaaS applications are the preferred choice for organizations adopting a digital strategy and they soon find themselves overwhelmed with cloud products. As most of the cloud products specialize in a subset of functionalities offered by their traditional monolithic on-premise counterparts, there is a surge in SaaS applications in the enterprise’s application portfolio, that addresses various specific business needs of an organization. With a plethora of SaaS applications thus introduced, it becomes paramount to establish seamless connectivity among them to behave as a well-connected system that meets the overall business objective. iPaaS (integration Platform-as-a-Service) is a next-generation integration platform that addresses the ever-evolving integration challenges with SaaS applications. iPaaS is the latest addition to the enterprise’s middleware portfolio, which offers integration as a service capability to the organization.
With growing interest in iPaaS, many organizations are curious and ready to adapt it to reap benefits. This article presents the key considerations that an enterprise architect, business, or IT team must think before jumping on the iPaaS bandwagon. Is it right to think that iPaaS is the panacea for all integration challenges?
The following are the important points to keep in mind during your product evaluation phase and before adopting the iPaaS into your organization
Motivation and Driver
The Enterprise Architect or Integration Architect needs to have a clear understanding of the primary driver for evaluating the iPaaS product. What is the main business problem or the technical challenge that is being resolved? Is the primary “driver” to improve business agility, simplify cloud connectivity, faster time-to-market, or what? Can the same result be achieved with the incumbent integration platform? If not, what are the key functionality gaps, and are those gaps precisely addressed by the selected iPaaS?
A good way to start is to clearly articulate the end goal or unambiguously represent the target state architecture, and ensure that the iPaaS is a right fit. The architect needs to have a clear vision of what kind of challenges he or she is trying to solve.
Application Ecosystem
Another key consideration is to identify whether the iPaaS will be used to address the integration needs of a specific or a set of business units, or will it be rolled out across the enterprise. This is a good challenge to have as any solution that greatly benefited a specific business unit will eventually extend to the whole enterprise. Identify whether the application portfolio has a larger footprint of cloud or on-premise, and what kind of applications are present. Do you have a significant cloud presence that has the latest bells-and-whistles or is the application footprint heavy with legacy systems that use older protocols? Will the new iPaaS predominantly connect SaaS-to-SaaS and SaaS-to-on-premise applications, or will it address mostly on-premise-to-on-premise traditional integrations? If you have more legacy on-premise applications, make sure you understand what kind of challenges iPaaS will solve and whether it is the right fit.
Use Cases
You also need to consider the organization’s direction and overall strategy regarding new application onboarding. Do you have a “cloud-first” or “cloud-appropriate” strategy? Is your organization investing heavily in the cloud rather than on-premise, which results in a shift in the application landscape?
What kind of use cases and technical challenges will be solved? Are your integration endpoints mostly using recent trends such as APIs and Webservices (REST/SOAP), or are they using older Queues, EDI, CDATA? Make sure to consider the kind of databases and file transfer protocols you will use.
Most of the iPaaS providers offer agents to run in your enterprise. Factor in where you want the processing to take place – in your data center or in the cloud? Are the use cases relatively simpler or complex? Does it involve complex orchestrations or heavier transformations?
iPaaS Provider’s Capability Maturity
Each iPaaS provider has their own key focus areas and capabilities. Identify the strengths and weaknesses of the iPaaS products that you are evaluating. Determine the iPaaS product that best meets your requirements and aligns properly in your enterprise portfolio. Understand what kind of services and offerings that the iPaaS providers have and utilize them. Also, don’t ignore to assess the maturity of their customer service.
As most iPaaS providers perform incremental releases every month, you may find a feature that you need but is not completely ready as you may expect. You may end up waiting for the feature to be completely available or perform a laborious workaround.
It is recommended to perform a proof-of-concept of your requirements with the iPaaS provider and understand their capabilities. Make sure you have a clear idea of the assumptions and expectations that need to be validated.
Your Organization’s Capability Maturity
Perform a skill assessment of the resource pool and identify the maturity level of the integration practice in your organization. How are you planning to establish and operate the iPaaS going forward? Do you plan to use the existing resource pool and provide applicable training, or do you plan to use cross-functional teams and citizen developers?
Even though the iPaaS is perceived as simplifying integration challenges and promotes “self-service” development, don’t underestimate the complexity that soon builds up. It is a good addition to the integration portfolio; however, the on-going complexity and operations involved will take the same kind of attention as any critical system.
Even though there is so much exciting work going on in the integration space, organizations should not assume iPaaS is a panacea for all their integration problems. Organizations should exercise due diligence when choosing an iPaaS product as each has its own strengths and sweet spots in addressing an organization’s integration challenges. iPaaS products still need to be robust enough and functionality-rich to position themselves as enterprise integration platforms, which are currently held by traditional on-premise platforms. iPaaS products are only used as complementary integration platforms in large enterprises in solving specific challenges, especially cloud-related, and are a long way from replacing traditional on-premise platforms. Another challenge is the loss of flexibility for heavy customizations, which is a strength for traditional tools.
Conclusion
In conclusion, organizations should perform thorough due diligence during the evaluation phase as each iPaaS provider has their own strengths and shortcomings. Once the right fit architecture for the iPaaS is established in the Enterprise Application portfolio, the benefits of using it far exceed the shortcomings.
