What is Enterprise Application Integration or EAI? Application Integration is – ironically – about application division. This article explains how applications are divided into separated components and how the components are glued together. Several “glue-areas” are recognized where mashups, portals, shared databases, SOA and EDA all play a role in gluing the pieces together.
In this article several steps are described to finally reach the “integrated application”. These steps however are not meant as a logical sequence. In practice these steps will evolve concurrently over time, led by architectural directions and roadmaps.
Let us start with “the chaos”.
Many current application landscapes consist of an organically grown collection of monolithic applications that interact by many different application- and technology-specific interfaces. All these applications have their own implementations of access control, user interfacing, persistency and business process control. Interface control is merged with business rules within the different applications, representing the overall business processes.
This leads to:
- Complex and long lasting maintenance efforts
- Data inconsistency
- Error-prone interface maintenance because of many (sometimes unknown) dependencies
- Exponential growth of complexity when extending the system
What is one thing we can do to bring order in the chaos? The answer is: strip the applications down to core business rules implementations by externalizing shared areas for exchange, access and persistency.
Externalize shared Exchange Area from applications
Bringing the interface control outside the application into a shared facility to be used by all applications results in uniformity of message exchange. Generic data transformation and routing services offer a layer of indirection between the communicating applications, which makes the applications less dependent on knowledge of each others data formats, technologies, addressing and location. In this layer generic facilities may be implemented to secure data transport in a standards based and sophisticated way, without any impact on the applications themselves.
Another huge advantage is that (changes of) process definitions can be accomplished much easier. Business processes that involve more than one application are established in the interface control mechanisms. Taking these mechanisms outside the applications allows for a more flexible configurable solution. This principle, combined with a design style to break down the business logic within an application into well defined components is the basis for BPM (Business Process Management).
The effects of externalizing an exchange area are:
- Less maintenance efforts
- More speed and flexibility in changing business processes
- Uniformity of management
- Linear growth of complexity when extending the system
Externalize shared Access Area from applications
Bringing user interface and access control from the individual applications to a generic facility makes the application:
- Independent from user devices
- Independent from user location
- Independent from user interface
- Independent from application access control
This leads to:
- Less maintenance efforts when changing overall presentation
- Uniformity and consistency of presentation
Externalize shared Persistency Area from applications
This externalization principle is very common for decades already: get all the fine grained data persistency logic out of the application and use shared database services. The persistency area offers services for:
- Real-time data synchronization
- Data warehouses
- Meta data management
- Data more actual (real-time synchronization)
- Consistency of data (synchronization, data warehouse)
- Less database management (recovery, meta model)
Virtual one single integrated “application”
Externalizing these three shared areas from the applications leaves a fourth area where the implementation of business logic resides. Business logic may be implemented by ERP, COTS, custom code and legacy. These concrete ways to deliver business logic don’t exclude each other, but overlap (e.g. the greater part of legacy will mostly be custom code).
Finally this architectural design leads to virtual one big integrated enterprise application.
Once in place, opportunities grow. In particular the exchange area is interesting. When business logic implementations are broken down to adequately sized and designed components, the exchange area will enable standards based BPM, BAM and CEP:
- Business Process Management: Flexible business process definition/maintenance
- Business Activity Monitoring: Real-time view on operational business state
- Event processing: React proactively to potential bottlenecks; correlate detected events to generate new events
Mashups: integration at the client side
The externalized areas can all be characterized as Enterprise Application Integration, each of which is very different from the other in nature. The areas each offer their own kind of services to glue the components together.
The multiple faces of Enterprise Application Integration recapitulated:
- Integration at the data layer: the glue is shared databases, DBMS, data warehouse
- Integration at the business logic layer : the glue is ESB, SOA, EDA
- Integration at the user interface layer (server side): the glue is portlets in portals
- Integration at the user interface layer (client side): the glue is mashups