Enterprise Agility - An Integrated Approach

Earlier this year I published a posting on the purpose of Enterprise Architecture in your company. I explained what the environment dynamics are in a what technologies form the layer of indirection between the business and changing contexts.

Lars Hansen, a student at the IT-university in Denmark took the subject of enterprise agility to an academic level with a thesis called: Enterprise Agility - An Integrated Approach (PDF).

His focal point is agility in relation to business processes and information systems. He analyzes the relationship between BPM, SOA and EA (Enterprise Architecture). He sees EA playing a very different role in regards to agility compared to that of BPM and SOA; EA is taking the long-term enterprise-wide look at resource utilization in the enterprise. In some ways, this long-term view is an anti-thesis to agility, but he sees huge synergies in using EA in combination with BPM and SOA. However, he also finds that something is missing from the equation. To be able to integrate EA, BPM and SOA there need be a shared language to understand the architecture as a whole.

Worthwhile reading!

What is EAI?

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”.

Context


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

In the current age where the pace of minor and major business-changes accelerates quickly to comply with global demands and where business more and more will be implemented and performed by IT, such an application landscape will not suffice anymore.

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

Services at a shared external exchange area brings applications together at the business logic layer.

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

Generic services can establish single sign-on, customized house-style decorations, remote access, personalization (language, time-zone, preferences).

This leads to:

• Less maintenance efforts when changing overall presentation
• Uniformity and consistency of presentation

Services at a shared external access area brings applications together at the user interface layer.

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:

• Virtualization
• Real-time data synchronization
• Data warehouses
• Recovery
• Meta data management

Some of the benefits are:

• Data more actual (real-time synchronization)
• Consistency of data (synchronization, data warehouse)
• Less database management (recovery, meta model)

Services at a shared external persistency area brings applications together at the data layer.

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

The exchange area will allow for BPM, BAM and CEP to make use of standards based access services and standards based persistency services in the context of SOA and EDA.

Mashups: integration at the client side

There is however one more aspect to application integration at the user interface layer. And that is the clients. Portals facilitate integration at the server side. At the client side (e.g. the web browser) new technologies are introduced based on Javascript and AJAX. Integration at the client side of the user interface are called a mashup. Mashups bring applications together in the browser while portals bring applications together with the help of portlets on the server.

The glue

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