How to Manage a Growing IT Integration Backlog
Your backlog has 50 requests. Half of them are just variations of the same connection between two project management tools, but without a system to recognize patterns, each request is treated as unique. Some actually have complex requirements, and others have been in your backlog for so long that the original requester has already built their own workaround, whether that’s with CSV exports, manual copying and pasting, or a rogue Zapier account no one in IT knows about.
This backlog might be IT’s responsibility, but it’s not their fault. It’s caused by a structural problem. According to a market study by IDG and TeamDynamix, 89% of businesses have a data integration backlog, even if they rely on third-party support.
The demand for integrations grows with every new tool the company adopts, but IT’s headcount doesn’t. Your backlog is the gap between these two trends.
Here’s why, and what you can do about it.
Why your integration backlog keeps growing
Organizations use an average of 106 SaaS apps. Even if each app only had to integrate with a single other app, the number of integrations you need scales exponentially. While a lot of these apps have built-in integrations with logical pairings (e.g., Jira and Azure DevOps), they can’t cover every integration request. Either the tools you need to integrate just aren’t available or the integrations themselves aren’t deep enough (i.e., they don’t support enough fields or actions).
It goes beyond the sheer number of integration requests, though. Most requests are rarely one-and-done. A seemingly simple request to pair Asana and Jira, for example, might spawn sub-requests like syncing statuses or supporting custom fields. When the scope of each request has the potential to grow from a few hours to a workday to even a full week, it’s hard to properly gauge the depth of your backlog, and it’s growing that entire time.
Another key factor contributing to that growth? Repetitive requests. Most of the integrations you get follow the same essential pattern (e.g., connecting one project management tool to another). But without a system for recognizing these patterns, there’s no efficient method for systemizing or templating your response to them. You have to address every integration request from scratch, like it’s completely distinct from the others. That leads to a lot of lost time spent on these requests.
Finally, when integration requests sit in your backlog for too long, the original requester typically figures out a workaround. But these workarounds (e.g., CSV exports, rogue automation accounts) can create technical debt as they lead to more problems than solutions. For example, an automation that IT never approved could accidentally edit fields in an Asana project and delete critical information. Then IT gets a ticket to fix the problem (which takes resources away from the initial integration request).
These factors, combined, create a perfect storm for a never-ending integration backlog.
Why hiring doesn’t solve the backlog
If your backlog is constantly growing, the solution is to keep hiring IT professionals, right? Not quite. Finance sees IT as a cost, and that cost can’t easily be linked with revenue generation. Everyone knows IT keeps the company running. But tying additional headcount to revenue growth is a harder sell. Hiring to fix your integration backlog is an uphill battle right out of the gate.
Even if you get the headcount you think you need, you won’t see a lasting impact on your integration backlog. Even a full-time integration engineer can make a dent in it but not fully address it. The rate at which your backlog grows can outpace that engineer’s work, meaning hiring can’t eliminate the backlog.
Engineers can create custom-built integrations to address integration requests, and some of them can even handle batches of requests. But every custom integration creates a maintenance burden, until most of an engineer’s time is spent maintaining existing integrations rather than addressing new integration requests.
That doesn’t mean you shouldn’t hire integration engineers. You need the headcount to address complex, mission critical integration needs — not for every Jira-to-Asana integration request. Hiring more engineers doesn’t address the core issues behind your growing backlog.
Why enterprise iPaaS isn’t the answer for most teams
When you start searching for a non-hiring solution to your integration backlog, enterprise iPaaS like Workato, Boomi, or MuleSoft quickly start coming up. But while these platforms have deep customization and tooling that IT teams can appreciate, they’re rarely the right solution for solving your backlog problems.
Most integration strategy advice is directed at a specific kind of problem: merging tech stacks, usually after a merger or acquisition. IT teams have to bridge the gap between two sets of tools while minimizing impacts on existing workflows. An enterprise iPaaS becomes the connective tissue between these two, potentially very different, stacks. But it’s not the right solution for a backlog with 40 integration requests, all covering the same tool stack.
For one, only IT has the keys to these platforms, making them a bottleneck in the queue you’re trying to clear. If you don’t have an engineer who knows how to use Workato, you’ll need to compensate for the learning curve involved before you start seeing a return on your investment in this platform. And that investment can be significant. Enterprise iPaaS is priced for enterprise organizations, which can put it out of reach for most IT teams.
Finally, enterprise iPaaS is overkill for most integration requests you’re actually dealing with. A temporary project involving two project management tools doesn’t need the robust customization — or lengthy implementation times — of an enterprise iPaaS.
The self-serve model: Shift from building to approving
With neither hiring nor enterprise iPaaS being the right approach to attacking your backlog, what’s left? Self-serve. Instead of IT building every single integration the rest of the company needs, IT is the gatekeeper. They review requests and hand the keys off to the initial requester if their request is appropriate. In practice, that means they get access to a no-code platform, easy enough for anyone to use, with guardrails set up by IT.
That comes with significant advantages. Your backlog transforms from tasks requiring build time to a list of approvals. Approving an integration will always be faster than building one, meaning this shift addresses the core issue behind your growing backlog rather than just trying to keep up with requests. There’s also less back-and-forth between IT and requesters, since requesters know what they need to build.
A robust integration governance framework allows IT to keep control over how integrations get built without building them all. This is a framework with four essential elements:
- Authentication, which validates which tools can and can’t be integrated.
- Authorization, defining which fields and work items can be synced.
- Validation, pre-approving integration patterns by tool pairing and use case.
- Audit, building visibility into your integrations so IT can audit them when things go wrong.
Many companies with a self-serve model ignore this framework. While self-serve tools are incredibly powerful for business users, using them without any oversight can create more problems than it resolves. Sure, you’ve offloaded your integration backlog, but you’ve created a potential deluge of IT tickets for troubleshooting problematic integrations or isolating data breaches. But with the right framework, self-serve integration platforms are the vehicle for dealing with your backlog.
What to look for in a platform that enables this
Not all self-serve integration platforms are created equal. The right platform has to strike a balance between ease-of-use for business users and control for IT. Here’s how you can evaluate these platforms.
No-code configuration
If an integration platform requires coding, it’s not truly self-serve. Users throughout the company need to be able to build integrations without help from a developer.
Centralized authentication
IT needs to hold the keys for the integration platform you use, without needing to authenticate accounts on an individual basis. Security measures like role-based permissions and single sign-on can help IT maintain control of integrations without excess admin work.
Field-level permissions
Just because IT approves a specific tool for an integration doesn’t mean all the data in it should be synced. Field-level permissions gives IT an additional layer of control, so they can still empower business users to build their own integrations without accidentally syncing sensitive data.
Two-way sync capability
A two-way sync keeps data consistent across multiple tools automatically, rather than requiring distinct automations for each direction. Most no-code automation tools support one-way automation, which is enough for simple workflows or one-time data transfers. A two-way sync can support more integrations without extensive IT or development work.
Audit trails and activity logs
A self-serve model requires auditability. That way, IT knows who built an integration and where to start if something goes wrong. It also gives them more visibility on the data flowing between tools, ensuring no one is syncing sensitive data.
Pre-built connectors
Pre-built connectors and pre-configured flows allow users to get their integrations up-and-running quicker. It also allows IT to approve integrations faster, since they meet pre-approved templates.
How Unito clears the backlog
Unito is a two-way sync platform with the deepest integrations for 60 of the most popular tools on the market, from Asana to Jira, ServiceNow to Google Sheets. You can set up a no-code flow in minutes, centralize authentication and data security, and build a foundation for integration governance.
By making Unito your one, central platform for software integration, you can start clearing your integration backlog by shifting to a self-serve model without sacrificing data security and best practices.
Take control of your backlog
Your integration backlog isn’t going away. Teams are going to keep adopting new tools. New workflows will need new integrations. You won’t build your way out — you’ll just keep falling behind. Shift to a self-serve model with the right tools, and you’ll actually be able to manage the backlog.
Want to see the kinds of integrations a platform like Unito can support? Check out these use cases.