Imagine you just got a new smartphone packed with amazing apps. A beautiful calendar, a notes app with brilliant search and a task manager that’s feature-rich and intuitive. Each one is best-in-class, but they don’t talk to each other. So you’re copy-pasting meeting details, retyping action items, and manually syncing everything.
That’s desktop interop when it goes wrong.
Different teams bring in their favorite applications. Each works brilliantly on its own. But without shared planning or design standards, you end up with powerful tools that don’t click together. Users go back to manual switching, copy-paste, and errors.
Rolling out interop across an entire firm: multiple business units, workflows, and legacy systems, is where the real value lives. It’s also where complexity multiplies. It’s not just about connecting apps. It’s about orchestrating live data flows across dozens of systems, keeping users in sync, and doing all of that while staying compliant with tight regulatory and internal controls.
At the interop.io consulting team, we’ve spent over a decade implementing desktop interoperability across Tier 1 banks, hedge funds, and buy-side firms. We’ve seen the full spectrum: from clean, elegant rollouts to absolute chaos. Here I’ll share best practices that will help leaders rescue derailed projects, migrate off legacy platforms, and turn cluttered, fragmented desktops into streamlined environments that actually work.
Here’s where most projects fail: before a single line of code is even written.
Don’t skip strategy
You got a powerful toolbox that can connect anything in different ways – channels, shared context, intents, FDC3. Someone says, “Let’s connect all our apps!” The idea of smart workflows, data sharing, and seamless integration sounds great. But in all that excitement, you can forget the most important question:
Why are we doing this?
Which workflows are we trying to improve? What are the biggest pain points we are trying to solve? Without those answers, you end up integrating tools just because you *can. *
First, ask relevant questions like:
- Where are users re-entering the same data into multiple systems?
- What slows people down during high-pressure moments like market open or close?
- Where are we losing time, focus, or accuracy due to app-switching?
When you uncover those day-to-day friction points, that’s where interop can really shine. That’s when you’re solving real problems.
To do so, bring your stakeholders in early. This isn’t just a developer’s problem or a business wish list. You need alignment across the board: product owners, technical leads, compliance, security, and of course, end-users. Get them all talking before you start building. Define the goals, agree on how you’ll measure success, and make sure everyone knows who’s responsible for what.
Takeway
Interop what matters. Start with the pain, not the tech.
Don’t Underestimate Integration Complexity
In the real world, we’re dealing with software written 20 or more years ago, weird homegrown VBA macros, Excel plugins from who-knows-where, and proprietary APIs that were never designed to talk to anything else. Some of these systems don’t even have documentation, let alone a clean way to expose events or accept external triggers. Yes, the interop platform gives you the tools. But you still have to do the groundwork. That means mapping out the landscape: skipping it will set you up for surprises.
That’s why we always recommend starting with a Proof of Concept. Not just to prove if something can work, but how it should work. Build a small and focused integration. Get real users to try it and watch what they do. And then iterate. A phased approach not only reduces risk, it gives you real-world feedback early enough to make meaningful changes.
Takeway
Start small, set clear goals, progressive rollout, and constant feedback. Run a realistic PoC with legacy and modern apps.
Governance and collaboration
Here’s where projects really spiral: governance. Interop isn’t just a shiny frontend project. It cuts across almost every part of the organization: applications, infrastructure, UX, security, compliance, even legal. So unless there’s clear ownership and coordination, what you end up with isn’t integration, but chaos.
Picture this: you’ve got three different app development teams, all trying to implement interop in their own way. One builds a custom context layer, another hacks together a local framework, and the third just wires up some point-to-point messaging between apps. No one’s talking to each other. No standards. No shared roadmap. In the end you get three incompatible solutions, all branded “interop,” but none of them actually interoperate.
That’s what happens without governance. Everyone builds in isolation. Silos get a fresh coat of paint, but they’re still silos.
So your project needs leadership and it needs structure. You need someone owning the architecture, someone responsible for platform consistency, and a shared understanding of what “success” looks like across teams.
At the same time, governance doesn’t need to be heavy-handed, but it does need to be visible. A big part of that is having a central source of truth: a living repository that tracks everything from onboarded applications and available intents, to shared contexts, methods, and workflows. Most companies use something like Confluence, or an internal wiki for this. It becomes the place where onboarding new apps or defining a new intent goes through a quick review process. Not to slow things down, but to keep things aligned. That’s how you avoid duplication, conflicting designs, and “spaghetti” integrations that nobody wants to own.
It’s easy to set and forget it, but that’s not enough. Someone needs to own it and keep an eye on it. Most importantly stakeholders must comply with it, so don’t make it too complicated
Takeway
Establish governance, standards, and regular architecture reviews. Make sure documentation is up-to-date and ensure new developers are onboarded early on.
Before You Start Building
The work you do before writing code determines whether your project succeeds or gets abandoned. Before your team starts integrating:
- Identify the specific workflows you’re improving (not “everything”)
- Map your landscape to know what you’re actually working with
- Run a realistic PoC with legacy and modern apps
- Set up a governance structure and a central source of truth
- Get stakeholder alignment across teams
Next up: Part 2 will cover how to actually build interop that people use—keeping architecture simple, designing for humans, and avoiding the complexity traps that create technical debt.
Let us know if you’re interested in discussing real-world use cases and dive deeper in what we’ve seen working before (and what to avoid).