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?

The two Cradles of App Interop

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.  

Capital Markets

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.

Mobile

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:

• Automatically taking the user from one app to another to complete a task.  E.g. from GMaps to Uber to a text message sharing arrival time.
• Sharing a photo and being able to choose between available installed apps that support the functionality
• Delegating common functions like photo taking, email, and maps and leaving the optionality to the end user
  

Intersecting the Two

What are the patterns that emerge when we compare app interop in capital markets and mobile?

• Discovery through intents is a key feature of app interop. Intents are fundamentally end user centric, creating last mile optionality for the end user to choose what path the workflow will take.
• While arising from very different needs, the most compelling use cases in mobile and capital markets focus on seamlessly moving data between apps - supercharging what an end user can do within the ecosystem.
• App interop creates stickiness with user-centric products. This stickiness has network effects that  increase the value for all apps participating in the ecosystem.
  

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.

So, What’s Next?

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:

• Broadening the FDC3 ecosystem by removing barriers for adoption and reducing TCO
• Bringing more vendors into the ecosystem with workflows that have measurable ROI
• Eliminating client dependencies and barriers between platforms and implementations
• Supporting FDC3 flavors for native technologies (.NET, Java, Python) and services.
• Expanding the taxonomy of widely used Context Data and Intents definitions through real world use cases

‍