Abstract

Enterprise Application Integration (EAI) is problem many large organisations are facing today. With the emphasis on the Integration part of the applications within the enterprise, more recently made even more complex by B2B which is integrating applications outside of the enterprise. There are business engineering approaches which can alleviate many of these problems, and have in particular organisations. These business engineering approaches from the top down merged with Environment & SCM engineering practises from the bottom up will further stem the flow of risks to any organisation.

Introduction

Winston Churchill said "to improve is to change; to be perfect is to change often."  This statement has never rung as true as it does in today’s dynamic business environment.  Leading a successful business requires being alert to the impact of external change and, more importantly, structuring the correct, timely response to these outside risk influences. SCM holds the key for controlling the incremental and ever increasing changes. 

The different drivers between the Business view of the organisation 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.

However it seems the tides are turning for the better at both ends of the business vs. 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

• Programme Management involve 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 & 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 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 generalisation.

Let's look at the four additional disciplines that have been added in more detail below.

Programme Management Discipline

Programme 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 organisation should align themselves with the three layers controlling the overall Architecture of the Organisation:

• The Business Architecture of the organisation - Executive Strategy, logical business processes, etc.

• The Applications and inter-processes within the organisation  - 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, eMail gateways, Middleware configuration, etc.

Diagram 2 - Enterprise Architecture

Business Engineering has been around since the 1980's, 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 organisation is in.

  • Look at industry growth rates, age, size, stage of development, etc.

• Measure the existing business

  • Interpret the effect of external and target environments on the internal organisation environment.

  • Generate business strategic information models.

• Design the ideal business

  • Based on business design principals such as MRP, JIT, ERI, TQM, APC, TOC, ISO, etc.

  • Incorporate the target business into the ideal business.

  • Design the internal business architecture around a set of frameworks using a set of techniques and modeling methods.

• Plan the ideal business

  • Look at the business influence on the ideal business plan.

  • Look at the Architectural influence on the ideal business plan.

  • Accommodating the business priority into the Architectural priority.

  • 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

  • Implement as a Programme

  • Manage the change during implementation

  • 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:

There are obvious interfaces between these activities and activities of the Programme management discipline.

Enterprise Environment & 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 (RUP) 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 (PIP) 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. 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.

• 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 Programme Discipline - need overall plans, Collaboration, Issues, Risks, etc. configuration managed for incremental release.

• The Enterprise Environment & Process Engineers - need to have their processes, centralised 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 synchronisation with the Enterprise Programme and its constituent individual projects.

The information repository should be organised at an Enterprise level, to contain individual projects no matter where the location of the teams.

Diagram 4 - Enterprise Configuration & Change management

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment