iPaaS Standardization or Hybrid Integration Platform: 7 Considerations for Setting a Direction
They say the devil is in the details. This is clearly true when you’re talking about digital transformation and integrations. No one is arguing whether you need an integration strategy—quite the opposite. Experts like Gartner call integrations a “crucial part of any IT organization.”
The devil is in how you adopt integration architecture. There is a certain attraction and comfort in the idea of handing the entire challenge over to a single vendor and standardizing on a single iPaaS to handle everything. For some, that’s the right choice.
But it’s not a choice without trade-offs. Using a single vendor for your integration platform comes at the cost of some attributes that could be very important to your organization - things like agility, internal skills, and solution complexity. This is when you might consider a hybrid approach.
To choose the right path, you need to be pragmatic in your approach, evaluate the major areas involved in making the decision, and understand the advantages and disadvantages of these approaches as they align with your specific organizational needs.
Standardized iPaaS or Hybrid: Major Areas of Consideration
You need to evaluate critical areas when choosing a hybrid integration approach and a single, standardized solution. Which direction you choose depends on the current and future goals of your IT and larger organization.
IT Staff Skill Sets
The skills and experience you have within your IT organization can be one determining factor - depending on your direction. You may need to maintain existing skills or consider acquiring new ones through re-training or hiring.
For instance, if you decide to standardize on a single iPaaS platform, like MuleSoft, but aren’t already using it, you’ll need to invest in either getting your current staff up to speed on the technology or bring in new developers to address the knowledge gap. This can be a significant undertaking if your engineers have no previous experience with MuleSoft - in other words, you’ll need to get training or hiring moving just to get started.
However, a hybrid approach may permit you to utilize the skills and knowledge already in your organization while, again, training or hiring to fill gaps. There may be fewer gaps to fill, though, and that may not hold you back from getting started with your strategy.
Training staff on new technology can present its challenges. Developers who have been working on outdated technology may jump on the chance to be re-skilled. If, on the other hand, your staff doesn’t see a benefit in shifting from their existing knowledge base or learning a new skill, you could face significant pushback.
Of course, standardizing on a platform will let you focus on getting a single kind of talent in, but that can be an issue, too. Depending on the candidate market and high demand for experience in the latest and trending technology, engineers in your chosen platform may be hard to find or expensive.
Are you better off dealing with one vendor or with several? Do you have the staff and bandwidth to deal with multiple touchpoints for questions, issues, or problems?
These are just a few of the questions you’ll need to answer around vendor management when choosing between a single iPaaS and a hybrid integration architecture.
By standardizing on a platform, you benefit from knowing exactly who to go to when there is trouble. That sounds very appealing. The downside of this choice? Vendor lock-in. If it turns out that your platform can’t support a particular, critical solution or you aren’t happy with their response time, product roadmap, or adherence to their SLAs, moving to something new is going to be an uphill battle.
A hybrid approach, by comparison, can be very efficient. You’ll have a world of solutions to choose from. They may not be the best solution, but they will be workable, and you’ll have the flexibility to change later. The obvious downside to the hybrid solution is you just increased your vendor management requirements.
When considering an integration solution, you’ll need to think about more than just the skillsets within IT. Gartner estimates that by 2023, 65% of large organizations will have non-IT staff working on integrations.
If you are enabling those outside of IT to set up, monitor, and manage integrations, it will be essential to consider who and how they will do this work. Are you enabling low-code, click-oriented citizen integrators? Can these roles absorb more nuance and complexity in their integration tasks? And, can you limit both access and exposure to a multitude of systems, while still supporting the work of non-IT teams who need to perform integration tasks as part of their job?
Communication of Strategy and Standardization
Both inside and outside of IT, it will be important to have clarity around what should be used, when, and by whom.
A hybrid integration platform requires a heightened knowledge of the architecture and platform elements that should be used, depending on the project's needs and goals. Depending on the breadth of your hybrid solution, there could be several ways to complete a task. Governance and access management will need careful consideration, as will documentation and support.
This can get especially tricky when you layer in compliance requirements and industry mandates. For example, if some of your solutions need to comply with FIPS 140-2, that requirement will mandate using specific platforms. You will need to clearly communicate across your teams which platforms are FIPS 140-2 compliant.
With a standardized solution, there is no decision to make. If integration is required, there is only one place to get it done.
When it comes to the architecture of your integration solution, it comes down to a few key points:
Does your preferred vendor's roadmap align with what you need?
What is your preferred vendor’s position relative to your needs across domains (technical, business, and functional)?
Do you have the bandwidth and interest in analyzing and assessing the capabilities available?
For a standardized iPaaS solution, you’ll have access to various components that fit together and play together nicely. However, if their direction is slightly skewed from where you are, and it will continue to head off in a divergent path from what you need, that convenience could be short-lived.
A hybrid solution, in contrast, could require more time spent on the integration of various integration components. Have there been advancements in other solutions? Are you using the best in breed offerings? Can you switch, and what will it take? And do the pieces that you need work well together? These are all questions you’ll need to answer for yourself and continue to re-evaluate over time.
In the area of architecture, there is an overarching concept that may guide your decision: you’ll have more time for innovation if you are spending less time integrating your integration components.
Budget and Cost
Every organization must evaluate and determine how they measure cost versus benefit, and the decision of iPaaS standardization versus a hybrid approach is no exception. Regardless of the architecture path your organization chooses, budget and cost considerations will depend on a combination of
The organizations’ comfort with variable cost
The organizations’ budget priorities now versus in the future
In the past, the thinking on this issue was more in terms of fixed or known costs (standardization) versus variable (hybrid). Most organizations viewed variable costs as synonymous with “lower,” even if additional costs were associated with a hybrid approach, e.g., talent, training, and “per usage.” It was harder to make a clear apple to apple cost comparison because there were oranges and bananas in the hybrid column.
There may now be variable cost elements of iPaaS solutions, allowing organizations to take advantage of flexible and scalable workloads and resources. Instead of thinking “fixed versus variable,” the mindset is better described as “predictable versus variable.” An organization may be comfortable with variable costs, but that implies their budget will require additional planning, analysis, and forecasting to be accurate and thorough.
The organization may also consider the actual cost of standardization versus hybrid in near or distant terms. Standardization may predicate higher license costs but fewer human resource, support, and utilization costs. A hybrid might permit lower upfront license costs but require a more significant and growing team to support, in addition to ‘peak demand’ or ‘excessive utilization’ costs. The priorities of the organization's budget will influence this thinking.
Speed is yet another component to evaluate. Is evolving and delivering products at speed today a critical piece of your strategy? Do you have time to build out complex, reusable components that will take time, but will accelerate your responsiveness down the road?
The answer to these questions must be combined with your answers to some of the other factors, such as internal skillsets, architecture, and budget.
A driving need to have a solution today could result in bringing in experts to get the ball rolling while your team comes up to speed. Or, it could mean choosing a standard platform with a low barrier to entry to get a solution in place.
It’s important to be practical when considering your integration strategy. Standardizing on a platform offers stability, greater simplicity, and more predictability, but can require more extensive changes in your staff knowledge base and lock you into your vendor.
A hybrid solution is the ultimate in flexibility, with the option to swap in new solutions and best in breed offerings when needed, but with higher overhead, cost unpredictability, and vendor and staff management. Whichever solution you go with should align with your most important goals to meet the needs of the business.
If you’re struggling with the choice, or you’ve made it and need guidance, Big Compass is here to help. We have extensive experience with iPaaS solutions and architecting and implementing stable and flexible hybrid offerings and can help you get the answer that serves your business the best.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents