The term app interop is used quite a lot in capital markets today. But what exactly does it mean? How is it distinct from other forms of interoperability? And why should we care?
Interoperability is a hopelessly broad topic, so let’s narrow it down a bit. App interop means something distinct. To understand what it is, it’s useful to look at how it came to be and the conditions that have formed it.
Interestingly enough, there are two distinct origin stories.
The first origin is in capital markets where extremely high value end users (financial traders) navigating multiple screens and countless information dense applications had the need for intricate orchestration and coordination between all of those windows and applications. In capital markets, app interop emerged as a feature of platforms and has generally been used by those platforms to not only improve user experience, but also to bridge across a patchwork of technologies on the financial desktop. App interop has been a major focus in the digital transformation of the financial desktop and enabling the migration of native technologies to web.
Some typical capital markets app interop use cases are:
- Contextually linking multiple apps onto a single channel, so that selecting a financial instrument in one app reloads the other apps with the new context
- A launcher that enables discovery and startup of apps running on a mix of web and native technologies.
- Enabling an application to share its underlying data with one or more other applications.
In mobile, the driver of app interop has been the need to improve experience for consumer end users within the constrained form factor of a single small screen with restricted input. In the mobile case, the interop is implemented at the OS level and serves (at least in part) as a moat around the native technology dominance in mobile and slowing encroachment from mobile web.
Some typical mobile app interop use cases are:
What are the patterns that emerge when we compare app interop in capital markets and mobile?
In conclusion, the key differentiator of app interop is that it is user lead. There must be last mile optionality for the end user to determine some part of the path for the workflow. Hard-coded workflows create interoperability and they are useful, but they aren't app interop. Intents systems that allow end users to resolve ambiguity and choose which app should handle a function, and context linking systems that enable the plug and play of end user determined apps are app interop. They produce network effects that create stickiness for product ecosystems. If the primary end users of your interop system are the developers using it for RPC and Pub/Sub, it may be doing something useful, but it may not be app interop and you may be missing out on those benefits for your end users.
In capital markets, FDC3 has successfully moved the industry to a single standard. And while there is still much work to do in fully realizing the promise of FDC3, the focus and excitement is clear to see. So what should we be setting our sights on as we enter into this next phase in the evolution of app interop?
At Connectifi, this is (some of) our list: