Intents in FDC3 are well-defined verbs that can be used to request and initiate actions across applications. They are a critical part of the vision for FDC3. Together with FDC3 Context Data and App Directories, Intents support loosely coupled discovery and sharing of functionality, enabling the assembly of applications as reusable components for building workflows.
While they contain great potential, intents may be the least utilized feature of FDC3. Broadcasting context data is a far more familiar construct on the financial desktop than intents-based workflows - which draw their inspiration from the mobile world. Successful intents implementation requires a different design paradigm for interoperability between applications. We might call it ‘thinking in intents’.
Three Steps
Designing the interoperability for an application can be broken down into three discrete steps:
- Identifying the key functions of the application.
- Identifying the key data that the application works with.
- Mapping the functions and data to use optimal FDC3 intents and context data definitions.
Taking a simple charting application as an example:
- The key function of the application is to provide time series charts of pricing for financial instruments.
- The key data the application works with are:
- instrument context data
- time series pricing data
- A mapping of functions and data to intents and context data definitions might look like this:
- listens for the ViewChart intent for the fdc3.instrument context type.
- can support raiseIntentsForContext on its current instrument context data.
In general, the first two steps are relatively straight-forward and the heaviest lift is in the third step where functions and data are mapped to existing FDC3 terms or crafted into new ones. Let’s go through each step in more detail.
Identifying Application Functions
Intents are like an elevator pitch of the work an application does. Intents will not necessarily cover all of the functions of an application and not all functionality an application exposes works well as an intent. Intents should capture what is most critical and actionable. There are three essential questions for identifying the optimal intents for an application to expose:
- Is it valuable?
Is this a function where the application provides distinct value to the end user?
- High: Providing a price chart for an instrument
- Low: Changing the theme of the chart
- Is it understandable?
Is the function nameable so that an end user could understand and have a reasonable expectation of behavior?
- High: starting a chat with a contact
- Low: changing application preferences relating to a contact
- Is it repeatable?
Is the function a reproducible pattern in your application and one that likely would be repeated by other applications?
- High: Creating a price chart for an instrument
- Low: Creating a chart of an internal scoring for an instrument
Identifying Data
The data an application works with drives what intents it will raise. Intents are most effective when they are relevant and reinforce the use cases for the primary data in the application. Key questions for identifying data and use cases are:
- Which are the primary data in an application and which are secondary?
- An instrument is typically a primary data item in a portfolio, a sector or region is probably secondary. Primary data items are usually jumping-off points for discovery of functionality, secondary data typically warrant more directed actions.
- Is there a specific function for the data that is most relevant given the context of the application?
- e.g. ‘ViewNews’ may be among the most relevant intents when looking at a table of top movers.
- Are there common activities for the data that end users will likely want to engage in across applications?
- for example: sharing is a common activity that applies across a wide range of content and applications.
Discovering Intents and Apps from a ticker context in an Adaptable Blotter using FDC3 Sail.
Raising an intent to ‘ViewNews’ for an instrument in a ticker grid using Connectifi.
Mapping Functions and Data
An intent should be broad as possible without adversely diluting value, and as specific as possible without becoming overly niche. In general, existing standard intents should be the first choice. However, it is OK, and ultimately valuable to define new Intents too. Whether using existing or defining new, the aim should be to strike a balance between standardization and precision.
- Standard: Using an existing standard Intent and/or Context Data definition. These are the most likely to be supported by other applications.
- Precision: Does the Intent used actually capture the function in the application or is there divergence that either results in patching by developers and/or confusion for the end user?
Effective use of intents and context data maximizes discoverability.
Custom definitions feed de facto community standards, which feed the FDC3 standard.
Other Topics
This has really just scratched the surface of what can be done with FDC3 intents and what we might want to do in the future. Some topics we did not touch on here are:
- Intents returning data. The FDC3 2.0 spec closes a previous gap for intents to have a data response. These additions to the API makes possible a number of new use cases for intents.
- Expanding the grammar for intents. Intents can currently express requests like: ‘ViewChart for the context: ticker=ibm instrument’, but there is no grammar for ‘ViewChart with Bollinger Bands for the context: ticker=ibm.’ Expanding the grammar would greatly increase the power, flexibility, and precision of FDC3 intents.
- Conversational intents? FDC3 intents and context data have a standard taxonomic structure. But given the move more and more to LLM and conversational models in search and discovery, what would a conversational model for intents in FDC3 look like?
Author: Nick Kolba
Interested in this FINOS open source project, or any of our other projects? Click the link below to see how to get involved in the FINOS Community.