Unifying the Desktop

In our prior blog, we had introduced desktop fragmentation, the problems posed by it, and how a Desktop Integration Platform (DIP) can solve them. In this blog we delve further into the architecture and structure of DIPs.

Providing a seamless user experience to end-users such as traders, analysts, data scientists, etc. has long been a challenge owing to the fragmentation of UX technologies and philosophies. The DIP solves this problem by providing a framework that allows composition and integration of applications on the desktop regardless of the technologies used in developing them. Central to this capability is the DIP’s message broker architecture.

The Desktop Integration Platform is an architectural pattern that aims to bring the benefits of service orientation, re-use and decomposition to the client workstation. DIPs enable integration of UI and data to happen entirely on end-user's devices, with applications exchanging messages instantly through a local message broker using publish/subscribe, request-response, streaming, etc. protocols. Applications, therefore, do not communicate with each other directly, but use the broker to help discover and mediate communications with others. Newly developed applications can be made DIP-aware from the outset, incorporating code to integrate with the DIP’s message broker infrastructure. Legacy in-house applications can integrate with the DIP with minor source-code changes to make themselves known to the broker and to publish their capabilities and hence their existence. This is a small price to pay when this enablement allows specific pieces of application functionality to become discoverable and re-usable by others running on the same desktop. Where desktop applications are provided via a third-party, a full-service DIP will provide other mechanisms to achieve integration e.g., plugins, add-ins, application connectors etc.

To understand this in context, let us a consider a simple example that involves a financial analyst needing to gather customer data, e.g., account information, demographics, credit history, etc. from multiple applications. The traditional integration approach would have prescribed a dedicated client-side application developed anew to visualize the consolidated information from all the services. Alternatively, a “dominant” application could have its UI extended to support this visualization by creating add-ins for the other services, assuming that it supports integration with the necessary backend services. Adopting a DIP would obviate the need for either of these approaches. Using a DIP-based approach to integration, developers would augment the existing in-house applications’ source code to connect to a locally running message broker and publish information about user actions, context, etc. So, when an end-user selects a particular customer record in one of the applications, that context of “the currently selected customer” is published to all of the subscribing applications. This can enable the other applications to concurrently display data related to the shared context, thereby eliminating the end-user to explicitly do so herself.

The most notable advantages of DIPs can be summarized as below:

• Message exchange between applications is faster because the data does not go over the network.
• Existing UIs are re-used avoiding unnecessary development.
• Data exchange does not leave the device, making the setup more secure.
• Access to data is easier to set up from a security perspective, since no federation between different applications is required. The DIP data is exposed through a single stateful client-side component rather than a remote service endpoint. The other applications on the client, reuse their DIP authentication, rather than re-authenticating to remote endpoints.
• Multi-application workflows and user-experiences can be designed regardless of the underlying application technology – as the local brokers will support old and new language bindings. Windows from different applications can be grouped into a single desktop window (Workspace) allowing easier navigation for users.
• Application performance, user experience, and UX ergonomics are improved due to a shared local context that facilitates optimal data flow.

Of course, server-side and client-side integration techniques are not mutually exclusive, and can be used together. Certain integration scenarios are better suited for a server-side approach. For example, batch update of multiple records in a back-end system where no UI update or confirmation is necessary is best implemented server-side for performance and data consistency considerations.

Desktop Integration Platforms are not entirely new in concept. In Capital Markets, firms like Bloomberg and Refinitiv (FKA Thomson Reuters) have long offered “Terminals” which incorporate everything from trading systems, risk management, data analytics, news, and even email. What sets DIPs apart is they enable incorporation of any UI technology, and do not require wholesale rewrites. Furthermore, DIPs provide a framework and methodology to create an optimal end-user experience based on efficient data management, cross-application context-sharing (interoperability), uniform workflows, and a consistent gestalt.