4.5. Integrations with other Software
IRM can be licensed for special interoperabilty with select other products, via special integrations.
A basic level of interoperability with a great number of other products and tools is already provided in IRM though its comprehensive data import and export capabilities.
Special Integration design principles
IRM special integrations are designed to integrate with specific industry products or solutions and are based on the following principles:
-
keeping the integration as
generic as practical, without sacrificing user convenience and functionality
-
making the integration
minimal, especially with respect to the amount of copied data, using
data federation -
keeping the components
tightly aligned but loosely coupled
Generic Integration
IRM utilizes the following basic set of integration-related objects and services, which help keep much of the integration generic.
|
Proxy Objects
|
A Proxy is simply a representation of an external object within IRM. Proxies are by design lightweight objects and therefore IRM is capable of maintaining large numbers of these objects without unduly burdening the system.
|
|
Proxy Source objects
|
A Proxy Source is an abstraction for an IRM-external software system that is capable of generating Proxies. In other words, it is the software being integrated with.
|
|
Task Request objects
|
A Task Request is an object indicating that a human user has to do some work in order for a workflow to proceed. In a sense a Task Request is something like a ticket, but Task Requests are lower-level, can be generated automatically by IRM, and can be used in cases where tickets are not necessarily involved.
|
|
Alert Objects
|
An Alert is a generic IRM mechanism for calling an IRM user's attention to something. Special integrations often include generating Alerts.
|
|
Discovery Set objects
|
A Discovery Set is a collection of Proxies generated from a single Proxy Source, from some subset of the data owned by that Proxy Source.
|
|
Ticket objects
|
A Ticket (available in IRM v1.4 and later) can either represent a ticket in an external ticketing system (essentially a special-purpose Proxy) or be a standalone object, giving IRM a very basic built-in ticketing system.
|
|
Integration Services
|
Each special integration includes an Integration Service, which is a separate IRM microservice component written specifically for that integration. Most of the business logic required for the integration is contained within the Integration Service. A typical Integration Service can operate both reactively -- taking action directly on the user's request -- or actively, taking action on its own accord, say during an ongoing sync operation.
|
The above features work together to enable considerable functionality, while minimizing the need for custom code and even limiting most of the custom code to a single component (the Integration Service).
Minimal Integration
Integrations that copy large amounts of data suffer from three major problems:
-
intrinsic difficulty in accurately mapping details of disparate data models with each other
-
time and resources necessary to duplicate large amounts of data
-
problems in keeping data in sync after copies have been made
IRM seeks to avoid all of these issues by using an integration strategy that depends primarily on data federation, rather than data duplication. Using this strategy, each integrated system continues to be the primary owner of its data, while maintaining references to relevant related data in the other system. IRM accomplishes such references in a robust and general way via the Proxy objects that are described above.
The data federation approach also prevents the systems from needed to re-implement each other's user interfaces for viewing and modifying objects. For example, IRM keeps a Proxy for a Linkware Live project and Cable Ids, allowing the user to view the details in Linkware live by providing a direct link from within the IRM Interface.
Tightly aligned but loosely coupled
The Integration Service, a bit of custom user interface, and IRM Correlation Engine keeps IRM and the external system tightly aligned in that important user workflows are implemented in a convenient manner and corresponding objects in the external system can be readily referenced from IRM (and in some cases, vice versa). However, use of Proxies means that the systems are loosely coupled, meaning that each system, and to an extent even the integration itself, can continue to be used even if the other system is down or the network is partitioned. This approach makes the integration far less fragile; once IRM has Proxies for objects that it needs, it can operate directly on those Proxies even if the external system is not reachable for whatever reason. Of course, there are limits to how far a given workflow can proceed without the systems being up and connected, but the user isn't exposed to every networking hiccup or short period of downtime for the external system.
