Enterprise application integration (EAI) is problem many large organizations facie today. With the emphasis on the integration part of the applications within the enterprise, more recently made even more complex by integrating applications outside of the enterprise. There are business engineering approaches can alleviate many of these problems and have in particular organizations.
Enterprise Application Integration (EAI) is problem many large organizations are facing today. With the emphasis on the integration part of the applications within the enterprise, more recently made even more complex by integrating applications outside of the enterprise. There are business engineering approaches can alleviate many of these problems, and have in particular organizations. These business engineering approaches from the top down merged with the environment and SCM engineering practices from the bottom up will further stem the flow of risks to any organization.
The different drivers between the business view of the organization and the IT implementation view has always been a flashpoint, not least at the interface between the two. Conflicting interests between business people who want it "now" in order to react to the market, versus the IT implementation people who want to architect it properly and need more time now in order to be able to respond to business change in a more controlled manner later.
It seems, however, that the tides are turning for the better at both ends of the business versus IT scale. Business are more and more becoming involved with IT as they take control of IT projects. IT projects are now not actually even called IT projects; they are just "business projects" with members of business and IT all on the same project, taking joint responsibility.
On the other hand business are learning engineering techniques which the IT have championed for their use in obtaining the context of projects, eliciting requirements, UML and other modeling of analysis and design, etc. Business can benefit from the IT skill which has evolved in discovering and understanding systems, to using these concepts and frameworks for discovering and understanding the business. Similarly, SCM can be extended laterally to become enterprise configuration management. 
Enterprise Application Integration Issues
Without going into much detail as to what enterprise application integration is, here are a few of the properties of an EAI:
· Internal integration must be highly structured and controlled
· External integration must be open and fluid
· Focused on transactions and messages
· Standardize and leverage objects/data across systems
· System process management automates business processes across systems
· High-speed communications provide reliability, availability and speed
· Routing table is used for routing between applications
· Look-up and cross reference is easy
· Recovery from lost messages is critical but manageable
· Solutions must be robust for scalability, reliability, etc.
· Integration timeframes are measured in multiple-months
· Reuse is at the event/data layer
· Each application requires specialization but there is significant value in architecture to leverage re-use
There is an urgent need in business today to implement EAI systems because of:
· Mergers, acquisitions regulatory changes
· Supply chain movement
· e-Commerce, B2B and internet applications
Overview of the Enterprise Framework
Starting with the basis of the RUP framework for a particular project, (see diagram 1 below) this view on the enterprise uses a similar framework at a higher level to encapsulate instances of each RUP project into the enterprise to create an enterprise framework where:
· Program management involves the executive and plan all enterprise projects overall
· Enterprise architecture has three levels of control across the enterprise (business, application and technology infrastructure)
· Enterprise environment and process management involve implementing enterprise wide process and environment tooling, gathering re-useable assets from one project to another
· Enterprise change and configuration management
Diagram 1
Similar concepts and information can be obtained from the Enterprise Unified Process, however this approach still seems to concentrate itself within the IT department of the business as opposed to being at a higher business level with the enterprise. There may be some exceptions to this generalization.
Let's look at the four additional disciplines that have been added in more detail below.
Program Management Discipline
Program management is responsible for making sure strategy is aligned between the business overall goals and objectives (assume on-going change all the time here) and all individual projects. They plan and communicate between the business executive, the enterprise architects (from enterprise architecture discipline below).
They also manage the interoperability issues between the individual projects under their control.
Architectural Discipline
The architectural discipline is split into three levels of architecture. All projects within the organization should align themselves with the three layers controlling the overall architecture of the organization:
· The business architecture of the organization: Executive strategy, logical business processes, etc.
· The applications and inter-processes within the organization: Those in blue in diagram 2 as an example.
· The Infrastructure or technology environment of the enterprise: All the hardware, networking, databases, OS's, telephones, office layout, e-mail gateways, middleware configuration, etc.
Diagram 2 - Enterprise Architecture
Business Engineering
This has been around since the 1980s, however it is becoming increasingly enhanced and required for more and more complex use now. Using business engineering methodologies, business engineers and business architects can drive out the enterprise strategy and design by looking at:
· Understand the evolutionary stage the organization is in.
1. Look at industry growth rates, age, size, stage of development, etc.
· Measure the existing business
1. Interpret the effect of external and target environments on the internal organization environment.
2. Generate business strategic information models.
· Design the ideal business
1. Based on business design principals such as MRP, JIT, ERI, TQM, APC, TOC, ISO, etc.
2. Incorporate the target business into the ideal business.
3. Design the internal business architecture around a set of frameworks using a set of techniques and modeling methods.
· Plan the ideal business
1. Look at the business influence on the ideal business plan.
2. Look at the Architectural influence on the ideal business plan.
3. Accommodating the business priority into the architectural priority.
4. Do gap analysis on the three architectural levels as a whole to align them to one another and to the overall business strategy.
· Implement the ideal business
1. Implement as a program
2. Manage the change during implementation
3. Measure the results throughout and at the end
There are various EA integration modeling templates and techniques suggested by Laura Brown in her book which will not be detailed more than the following, namely:
Modeling template | Usage Description | UML Equivalent |
The Cycle template. | Clarify contexts in cycles or capture multiple perspectives (e.g., annual plan, Q2, Q3, Q4) | Sequentially numbered list of use cases and associations. |
The Seed template | The seed is a generator / transformer structure depicting a situation where a core component produces, collects or contains an array of results. | An actor and associations to numerous use cases or collaboration diagram, depending on the particular requirements |
The Web template | The web template depicts a network of nodes (or endpoints) and connectors (or arcs). It is useful in modeling network routing and for performing complex path analysis and optimization. | Uses a component diagram with components as nodes and connections set up as dependencies. Could also be done as a class diagram. |
The Flow template | The flow template is used by process and flow analysis to trace the course of information, goods, services, communications, etc. | This can be set up as an zctivity diagram with transitions to represent the flow. |
The Wave template | The wave template is used to describe the layers of a system, environment or network. Layers help manage complexity. | A wave diagram uses the components in columns captured under notes as column headings. |
The Ring template | The ring template is useful for depicting chaining of events, people, devices or network addresses. While the cycle models directional processes, the ring models peer-to-peer relationships. | Actors and associations in a relationship, or shown as classes on a class diagram with relationships. |
The Cell template | Cross application compartmentalization. (e.g., business areas: marketing, finance, sales, etc.) | Uses a class diagram or component diagrams with relationships. |
The Tree template | Function on more than one level. (more and more detail as you drill down from node to node, like a directory structure) | Using use cases in a tree layout or classes in a tree layout. |
There are obvious interfaces between these activities and activities of the program management discipline.
Enterprise Environment and Process Management Discipline
While it is all very well to spend quite some time, resource, effort and money implementing software development into the enterprise, configured from the likes of rational unified process and other sources. Much of the value of a one project implementations can be lost if there is not an on-going cyclical process implementation plan which like the software projects it directs, lives through risk and a changing business climate.
Much of the re-use on project number two will be generated from the large efforts done on project number one. Items such as the project collaboration standards using say an intranet/email combination, or architectural models on intra-system messaging, or document templates, such as use cases, directory structures, programming, testing and design guidelines, tools, etc., will all be lost if there is not a responsible element controlling these items, who survives from project number one and can set up some sort of repository to get project number two and three going.
Diagram 3 - Process of incrementally improving the Enterprise Project Software Development Process
This and the business architectural discipline are closely related in being keepers of the knowledge of the enterprise.
Enterprise Change and Configuration Management Discipline
Just like a software development project requires SCM base-lined artifacts throughout the development lifecycle in order to control the whole process, so too at the next level of abstraction up from a project, does a an Enterprise.
All sorts of roles in the enterprise ought to have their artifacts base-lined and controlled:
· Business engineers, users and enterprise architects: Need enterprise models, diagrams, papers and workshop documents configuration managed for incremental release to the rest of the business.
· The managers and workers from the program discipline: Need overall plans, collaboration, issues, risks, etc., configuration managed for incremental release.
· The enterprise environment and process engineers: Need to have their processes, centralized project repositories, guidelines, tools research and other artifacts managed for incremental release.
· The enterprise configuration people would then control and ensure this incremental releasing was in synchronization with the enterprise program and its constituent individual projects.
The information repository should be organized at an enterprise level, to contain individual projects no matter where the location of the teams.
Conclusion
Diagram 4 - Enterprise Configuration & Change management
In summary enterprise needs to realize it needs a team to manage the overall architecture above projects, manage the overall enterprise program, manage the enterprise process and environment and control the enterprise configuration and change management. This is the only way of eliminating risk and aligning and merging the many complex threads into an implementation of the executive’s vision of the enterprise.
References
1) Brown, Laura. Integration Models: Templates for Business Transformation.
2) Pinkston, Jeff. The Ins and Outs of Integration. How EAI differs from B2B Integration. EAI Journal.
3) Ambler, Scott. The Enterprise Unified Process
