The importance of an Integration layer
Written by Léon Smiers | 
| 
Introduction
The Integration View is the backbone for the CORA model. A couple of things are to consider when working on the Integration layer. What components are there to consider? What is the impact of the type of functionality needed in the Integration Layer on project execution? How special is Solution Design in the Integration Layer? And lastly, the communication between application is based on a common language, what aspects should be taken into consideration.
All communication internal and external runs through the Integration Layer.
The CORA model identifies three main grouping of functionality:
- synchronous Communication, which contains mediation type of functionality;
- a-Synchronous Communication, with functionality like queueing, publish-subscribe, File Transfer;
- common type, like transformation, validation, routing, adapters.
The main reason to make a distinction between synchronous and a-synchronous is that they have different requirements, different integration patterns and within a physical architecture they are often implemented differently at run-time (two different run-time components, or one product with multiple deployments).
The type of functionality needed in the Integration Layer has great impact on the execution of a project. The Integration Layer enables living in a hybrid environment and takes care of all the connections to external applications. Often the Integration Layer contains the most riskfull areas. Examples of risk situations are:
- connections to Legacy systems: Legacy systems sometimes have the nasty habit not having 'Open standard' interfaces with the outside world. This can result in having to build your own adapter;
- providing functionality for 'out-of-the-air' situations when a system, which needs to be connected, has gone down;
- handling high volume and large data volume transactions;
- Failover and Usage: Robustness and scalablity are keywords for the Integration layer. For each Integration layer component a Service Level Agreement (SLA) must be defined. Another important piece of information to know is a prediction of the changeability in functionality and the usage.
The Integration layer therefore has a tight connection to the Governance Layer. Application Management tooling is essential in order to check check the sanity of all Integration components. Governance tooling will be used to store the SLA and usage information.
Solution Design for the Integration layer is different then in other CORA horizontal layers.
In the solution design phase Integration layer components will only be identified indirectly. Whereas for instance in the Presentation layer a functional requirement clearly states that a set of UI pages is needed. Functional requirements indicate that information should be obtained from another system. But the what and how it ties into an Integration component can only be identified with extra technical investigation.
Integration between systems often results in discussions about the meaning of data. Elements in a message coming from one system are named and designed different then that in another system. In order to be able to map the data correctly from one system to another a standardized data model is needed, also known as the Canonical Data Model (CDM), see also [Thomas Erl definition]. This information is kept in the Integration Metadata component.
Examples of principles to be considered in designing the CDM are:
- are industry standards or enterprise standards available;
- design for reuse but not for change, changing CDM information could cause rework of interfaces. Adding extra information to the CDM will on average not cause disruptions in existing interfaces;
- make a statement about the meaning of empty fields.
- CORA and Application Lifecycles
- CORA Methodology, playing with Lego
- The roadmap for Fusion Applications, CORA is there to help
- Technovisions "Sector-as-a-Service" mapped
- Business Logic and the CORA Model, Part II
- CORA and Cloud Computing: Static versus Dynamic View
- Technovisions "Thriving on Data" mapped
- CORA Foundation
- Business Logic and the CORA Model, Part I
- CORA and IBM
- CORA and Microsoft
- CORA and Cloud Computing: Overview
- Technovisions "Process-on-the-Fly" mapped onto CORA
- Risk aware design: using CORA to investigate an IT solution
- A ROA based iPhone App for SAP: Part II
- A ROA based iPhone App for SAP: Part I
- Technovisions "We Collaborate" mapped onto CORA
- SAP platform decomposition with CORA: SOA/ROA style
- 'Why' Driven Solution crafting
- CORA and TOGAF
- SAP platform decomposition with CORA: N-tier style
- Requirements for CORA
- CORA and Oracle
- Technovisions "You Experience" mapped onto CORA
- CORA and SAP
- CORA in action: design guidelines to implement repositories
- The basis of all, your data
- CORA and IAF
- Technovision and CORA - Overview
- The importance of an Integration layer
Comments