In the prior two blogs of this series, we had introduced the fragmented desktop, and outlined the advantages of using a Desktop Integration Platform (DIP) to solve the problem. In this blog, we look at emerging standards in Desktop Integration and how vendor solutions provide advantages over homegrown solutions. We round out the conversation with a series of examples that illuminate how DIPs effectively solve real-world integration problems.

Larger organizations that have recognized the need for a DIP may consider rolling their own platform. DIPs are essential technology infrastructure and need to be aligned to specific UI styles and in-house development and deployment practices. However, as in the early years of ‘middleware’, many organizations built their own integration brokers. Over time, these implementations became more and more complex with bespoke engineering required to support security, orchestration, choreography and analytics. Ultimately, most organizations turned to independent software vendors to provide their backend integration infrastructure and ultimately drove the emergence of Enterprise Service Buses (ESBs).

The same trend is repeating now in the area of Desktop Integration. The requirements for an effective DIP go beyond publish/subscribe and an Electron Container. A modern DIP needs a full set of data exchange patterns (across all language bindings), along with advanced window management, workspaces, layouts, notifications, search, user behavior monitoring, etc. Building all that in-house is a very costly endeavor with significant maintenance obligations. Instead, choosing a vendor that provides a DIP as a set of services which can be used to configure an organization-specific platform is the most cost effective and timely approach. This will also allow corporate design systems, UI style guides and their own deployment mechanisms to be embraced and enforced. Critically, a vendor provided DIP does not mean lock-in. The emergence of open standards (e.g. FDC3) and open-source platforms (e.g. Glue42 Core) are key steps in the maturing of this market.

The effectiveness of DIPs can be best illustrated in the context of problems posed by the fragmented desktop and how DIPs solve them.

Scenario 1: Often, organizations organically grow multiple independent software teams without a centralized governance process, independently delivering capabilities requested by different stakeholders. As a result, users end up with multiple independent applications that they need to use to carry out their goals, with little or no integration.

Solution 1: An enterprise-wide platform which supports multiple client-side technologies enables a centralized delivery mechanism and shared toolset while preserving the various teams’ autonomy, their user focus and their funding sources. Using a DIP allows them to keep their tools of choice. At the same time, the end-users’ experience is improved – as the professionals now work within a unified, structured environment, with fewer repetitive actions to be performed across those multiple apps.

Scenario 2: In many large enterprises, the technology stacks used to implement the core/longer-lived applications are no longer current. Old, obsolete or simply unfashionable technology presents IT organizations with the challenge of finding suitably trained developers at a reasonable price-point. The consequence is that these systems tend to become more siloed over time and the lack of any client-side and/or server-side APIs makes the situation worse and leads to stagnation.

Solution 2: With minor code modifications, such aging software assets can serve as a foundational layer to integrate with new business functions. The codebase can be augmented with interoperability calls, allowing other apps from the platform to extend workflows, push and pull data, navigate across screens, and synchronize contexts. This approach allows the developers to deliver new capabilities which extend the existing UI. The most significant benefit is that, rather than stressing the users with a brand-new way of doing things, the UI they are using is incrementally improved. Eventually, the legacy application can be fully absorbed and recycled within the newly formed environment.

Scenario 3: The software industry suffers from an ever-increasing tech churn rate, which tends to outpace natural product lifecycles. The speed of change is especially high for web application tooling. Of course, the availability of new, more capable tech is good news for the teams who start fresh projects; unfortunately, this will leave multiple, less fashionable, languages and frameworks in its wake.

Solution 3: A Desktop Integration Platform implementation effectively addresses that by actively encouraging the development of small, independent building blocks that can work with the existing apps and which are free to make new tech choices. Since UI components are easily integrated (both logically and visually), new development can safely take advantage of the latest tech while presenting users with a seamless UI. In addition to developer convenience, developing in small blocks allows the incremental replacement of legacy parts with new ones, without users having to change habits and re-learn how to access new apps. All it takes is to replace the older component with a new one in the user’s workflow.

Scenario 4: Replacing a set of legacy apps with a centralized (a.k.a. monolithic) application is a common enterprise implementation pattern. Monoliths are not universally bad - sometimes, those projects succeed and bring significant value to the organization. In some instances, due to scope / organizational complexity, such initiatives never really get completed and are either entirely scratched off or linger alongside the apps they had to replace.

Solution 4: A Desktop Integration Platform implementation can eventually salvage some of the monolithic pieces and integrate them with the existing infrastructure, providing a functional environment for the end-user.

Scenario 5: Analyzing end-user behavior will yield valuable insights to the efficacy of the desktop and the opportunities for improvement. A few commonly occurring behaviors to look out for are:

• Copy-paste of data between applications
• Repetitive actions performed across various apps e.g., search, update
• Frequent re-adjustment of cluttered windows
• Regular switching between apps
• Non-adherence to required processes.

Solution 5: A Desktop Integration Platform treats the individual application UIs, and hence the UX, as a first-class citizen. Workspaces can be constructed to deliver the right applications at the right point during the user-process – while at the same time allowing them to share relevant data through a client-side shared data-context. This will provide improved signposting of process steps and reduce the time to upskill new starters.

In conclusion, Desktop Integration Platforms reflect an evolution of the integration marketplace in which the UI and associated end-user workflows are treated as first-class citizens. Re-use at the level of the UI, will, by definition, re-use the mid and back-end tiers. The potential for faster time to market while at same time being agnostic to the technology stacks is an architectural pattern that will continue to grow. Furthermore, the emergence of desktop integration standards and the increasing number of independent software vendors who provide client-side APIs, means that the future for DIPs looks promising.