In Part 1, I covered the planning work that prevents disasters before you write a single line of code: identifying the right workflows, understanding integration complexity, and establishing governance. Now let’s talk about execution - how to actually build interop that scales and gets adopted.
Because once you move from planning to building, the stakes change completely, and this is where technical decisions compound. It’s not just whether your integrations work, but whether they’re maintainable, whether users trust them, and whether the architecture you choose today becomes technical debt tomorrow.
Keep Architecture Simple
Architecture is inherently complex. We’re solving problems across systems that were never meant to talk to each other. But sometimes, it’s not just complex, it’s complicated. And there’s a difference.
The extra complication usually comes from things we inherit like legacy systems, rushed timelines, or designs that worked in one context but don’t scale. You might build something that works perfectly for one business unit, then replicate it everywhere without thinking holistically. So again, you end up with a patchwork of siloed mini-projects that don’t play well together.
The Micro Frontend Trap
Take micro frontends as an example. They can be powerful when used wisely. But too often, teams slice their UI into dozens of tiny apps, each with its own state, services, and dependencies. Or worse, they overload the UI layer, using it as a caching layer or even a mini backend.
At first, it feels productive. Things ship faster. Components are reusable. Everything’s “decoupled.”
Fast-forward six months or a year and you’ve got ten teams coordinating versioning, dependency conflicts, inconsistent user experiences, and performance issues.
That’s when complexity stops being useful and starts being a liability.
Start Simple, Expand with Confidence
Here’s the rule for interop-heavy environments: start with the cleanest, most minimal architecture that meets requirements. Fewer moving parts mean fewer places for things to break. It’s always easier to add complexity later when you have a real reason than to untangle a mess after everything’s in production.
Build iteratively:
Phase 1: Get the basics working. Two apps sharing context. One workflow functioning end-to-end.
Phase 2: Users try it. What works? What doesn’t? Refine based on feedback.
Phase 3: Add more applications and workflows systematically. Each addition builds on lessons learned.
Phase 4: Now you have real usage data. Optimize where it actually matters.
This reduces risk and provides feedback early enough to make meaningful changes.
Design for Humans, Not Just Systems
You can have flawless architecture, perfect data flows, and APIs that communicate beautifully. Five applications syncing context behind the scenes, messages flowing, events firing exactly as designed.
And users may still use it the wrong way and even cause support burden.
Why? Because technical integration is not the same thing as usability.
What Users Need
Visibility: Users need to see what’s happening. When context is shared, show it. When data is syncing, indicate it. When an action triggers multiple apps, make it clear what’s connected.
This doesn’t mean cluttering the interface. It means providing appropriate feedback at the right moments like visual indicators when apps are linked, brief confirmations when context is shared, clear status when something is loading.
Control: Nothing kills adoption faster than a system that feels like it’s driving itself. Give users the ability to see what apps are connected, disconnect when needed, trigger actions manually when automatic isn’t right, and undo when things go wrong.
Clarity: Design interactions that make sense in the user’s mental model, not the system’s technical model.
Bad: “App has raised intent fdc3.ViewChart for instrument context”
Good: “Opening chart for AAPL”
Users don’t think in terms of “intents” and “context objects.” They think in terms of clients, securities, portfolios, orders. Your UX should speak their language.
UX Is the Delivery Mechanism
When you’re building interop, don’t stop at making it work. Make it clear. Build for confidence and control. Integration is powerful, but if users can’t see what happened, understand why it happened, or control it when they need to, they’ll misuse or abandon it.
Design matters because at the end of the day, you’re solving for humans.
Golden Rules
Here’s what separates successful interop implementations from failed ones:
1. Focus on workflows, not technology
Integrate because it solves problems, not because you can.
2. Start simple, avoid analysis paralysis
The simplest architecture that works is usually the right architecture. Complexity is costly. Don’t try to design the perfect system on paper.
3. Establish clear governance
Structure enables speed. Chaos slows everyone down.
4. Design for humans first
If users can’t understand and control it, they won’t use it.
5. Iterate gradually
Avoid big-bang rollouts and analysis. Phased approaches reduce risk and enable learning.
6. Think about performance and compliance from day one
These aren’t things you add later. They’re foundational.
The Bottom Line
Interop isn’t just about APIs and windows linking together. It’s about creating a system that people trust, that scales, and that actually solves problems.
The difference between success and failure isn’t usually the technology, but whether you kept architecture manageable, designed for how humans actually work, and built iteratively with real feedback.
Catch up on Part 1:
If you haven’t already, I recommend you to check out the first article, where we explored, setting goals, strategy and governance. Let us know if you’re interested in discussing real-world use cases and diving deeper into what we’ve seen working before (and what to better avoid).
Have you hit other obstacles that we didn’t cover? Were there things that didn’t go according to plan, but worked in the end? Any surprising user stories or neat workarounds you can share?