When I think about integration, the first thing that comes to mind is application to application integration (A2A). Gartner states that application integration aims to make independently designed application systems work together. Their definition applies to my interpretation of A2A integration, which is the connection of disparate applications both inside and outside the firewall, regardless of location (including the Cloud). This interpretation includes integration between a few or many applications and encompasses all integration aspects such as, communications and messaging, translation and transformation, routing, process automation, data access and even extends to application access. This can apply to scenarios such as transaction replication or process activation across applications, providing web access to legacy applications and publishing information to mobile devices. Most of the integrations between these disparate applications used to occur by means of proprietary APIs, messaging or a combination of both. This can still be the case, but a larger percentage of integration today is mediated by integration middleware or via web services.
The indirect integration occurs when data is produced by upstream applications and consumed by downstream applications. This data can be stored in databases, file systems, or non-persisted forms, such as messages, XML documents or spreadsheets. The activation methods or triggers utilized to move this data can be from events, monitors or scheduled processes on either side of the integration. One scenario that illustrates this idea is the integration between a legacy order system and a warehouse management system (WMS). When an order is received and entered into the order management system, a number of automatic verification processes occur and if the order is valid, the details of the order can be sent to the WMS to initiate the fulfillment process. In this case, the data must be extracted from the order management system and transformed into a consumable format for the WMS. The two applications become integrated based on the simple need of the WMS to consume the data from the order management system.
When web services are involved, the integration is implemented using a direct request to a web service provider from a consumer. Web services integrations support using synchronous or asynchronous communications, multiple protocols (such as REST and SOAP) and web service providers and mediating web service consumers are usually non-invasive. The request to a web service provider can be activated by the same or similar methods listed in the previous paragraph. An example of this integration is an enterprise resource planning (ERP) application hosting a web service to receive updates from a WMS about an order. When an order is being processed in the WMS, a status update about the order may need to be relayed to the ERP. In this case, the data must be extracted from the WMS, marshaled into the web service request and sent to the web service provider of the ERP using an asynchronous SOAP request. The two applications become integrated based on the need to coordinate two independent applications without modifying either.
Looking at the ways to integrate applications, the same mechanisms for process automation, activation, data transformation, and resource integration extend to data integration, business to business (B2B) integration, cloud integration or any other type of integration. In the near future, I can envision a unified integration model that leverages all of these integrations between all systems (legacy database on any platform), applications (ERP, WMS, CRM) and processes (Order processing, Inventory updates). It appears that the boundaries separating the different types of integrations are slowly disappearing. Simply put, no matter how you look at it, integration is integration.