Integration: An Architecture Example

The Problem:

You have five applications, one that manages item information, one that needs that item information for back office operations, and the others use that item information for work management. Now you need to tie them together for real-time transaction capability. 

Application One:

This application is used to allow users to create and update item information. It is the origin of item data. Creates and updates must be sent to the downstream applications. It resides in the cloud and has the capability to call an API to send the Item information. It needs to communicate information to Application Two to start the process and must receive notification of success or failure.

Application Two:

Application Two is an on-premise ERP application that will use item information to receive requisitions and generate purchase orders for items needed by Applications Three, Four and Five. Item information must be successfully processed before sending item information to the downstream applications. Integration capabilities consist of existing, out-of-the-box APIs. To complete an action within this application, multiple APIs need to be called. This application also owns certain aspects of the item data not maintained by Application One. These updates must also flow down to Applications Three, Four and Five.

Application Three:

Application Three is an on-premise work management application that requires item information to assign to work orders and to create requisitions that are sent to Application Two. Integration consists of only database stored procedures. The procedures will return output and this application users are required to receive notifications upon failure.

Application Four:

Application Four is another work management system much like Application Three, but integration options are limited to database staging tables. Internal batch processing is responsible for error handling and notification.

Application Five:

This application is yet another work management application. Integration capabilities for this functionality consist of APIs and database connectivity. As with Application Four, internal processing of queues is responsible for error handling and notifications. 

Goals

Create an API that can be used by Application One to synchronize Item information to multiple applications where:

• Loose coupling is used to buffer applications from each other,
• Existing API’s are re-used where possible,
• New API’s are geared toward re-usability and
• Business needs are met.

Solution: Use a Layered Integration Architecture

Layered Integration Architecture

Using a layered architecture between the application allows separation of responsibilities for integration components, increases flexibility and allows for reusability. Components should represent isolatable capabilities that could be used independently and when combined together with orchestration, implement a larger business process. Communication between the layers utilizes a common messaging model. The model can take shape in different ways, but the goal is to use messages made up of common formats for the data flowing through that specific operation. This architecture can be implemented with a multitude of technologies and frameworks such as MuleSoft, Oracle SOA Suite, and custom development using various languages.

Typically, a layered integration architecture that we implement consists of three layers:

• Requester/Experience
• Business/Process
• Provider/System

Requester/Experience Layer

This layer is used to provide an entry point into the integration layers for applications. APIs in this layer conform to the integration capabilities of a calling application. The calling application could be anything that ranges from server based calls to browser based calls from JavaScript. They will utilize operations on APIs in the Business/Process layer as building blocks to satisfy their requirements. Logic to transform the application information into common messages will be contained here as well as any possible validation or enrichment needed.

Business/Process Layer

APIs in this layer can be used to expose operations specific to business entities, and business orchestrations/processes. They will use APIs in the Provider/System layer as their building blocks to complete requirements. It is entirely possible to have APIs in this layer to call other APIs in this layer as well. This layer should also be used as a routing layer when messages need to be sent to multiple systems.

Provider/System Layer

This layer contains the finest set of APIs of all the three layers and consists of components that expose interfaces to application capabilities. These capabilities make up the building blocks for your Enterprise APIs. The Provider/System APIs are much like the Requester/Experience components, but in reverse. Messages get transformed from the common message to whatever the target application needs to communicate. Validation and enrichment can be contained here as well.

Solution Applied to the Problem

In this example, we have broken down components into reusable APIs that have been stitched together to support the Application One ItemSync requester/experience API. The Create Item and Update Item APIs will orchestrate the necessary Application Two APIs, and in this case respond back to Application One before sending the item information on to Applications Three, Four and Five.

Let’s revisit the goals to see if they have been achieved.

• Loose coupling: Using a common messaging model and abstracting applications with an integration layer, we have achieved loose coupling. This will also buffer applications from changes in the ecosystem. 
• Use existing APIs where possible: Provider/System APIs utilize existing application interfaces without modification by the application teams.
• New APIs are created for re-usability: Breaking down the process into individually callable APIs allows for use by other processes and applications. Using an API manager for discoverability of APIs is beneficial to bolster re-use.
• Business Needs are met: The Create and Update Item Process APIs orchestrate provider/system APIs to achieve the results required

A layered integration architecture is beneficial in many more ways than what was covered, but hopefully it gave some insight on how a complex business problem can be solved. Here at Zirous, we have vast experience in creating Enterprise Integrations using the layered approach. If you have an integration problem to solve and need help, reach out; we would be happy to understand your business and create solutions for your needs. If you have more interest in learning more details about this example, please contact us as well.