Enterprise Application Integration

The legacy system problem has many symptoms: systems that don't work together, too much data and not enough information; incompatible and incorrect data; and excessive maintenance costs. 70% to 90% of an organization's IS budget is spent typically on current applications. There are lots of reasons for this, but the primary cause is the way the applications were developed:

- Independently as stand-alone, "stove-pipe" systems -- not designed to be interoperable.

- Not based upon a single enterprise standard

- Without a common data architecture to ensure data sharing

- In unstructured programming languages

- Poorly documented if documented at all

- Designed to reflect developers interpretation of business requirements ten years, twenty years, or even longer ago

Since they were first implemented, most legacy applications have been patched and modified over and over to fix errors and respond to changing requirements until the IS staff is fearful of making any changes because they cannot predict results.

Compounding the problem is the variety of technologies that exists in most organizations. In addition to multiple programming languages and methods, there are multiple platforms, operating systems, data management systems, and communication protocols.

More recently, business and competitive pressures have caused enterprises to install multiple, single function commercial packages that further complicated an already serious problem. Most CIO's recognized long ago that this is notan optimum environment for effective information management and that something must be done. The most common solution tried over the years has been developing interfaces between the applications. These included interface programs and interface data stores. This worked fairly well when only a few interfaces were needed. But as the number of interfaces grew, the result was additional maintenance problems and what the Gartner Group calls "inter-application spaghetti." Even today many organizations are still trying to integrate their applications through interfaces -- without much success.

Other organizations are trying to solve their legacy application problems using a number of relatively new approaches including:

- Replacing legacy systems with integrated COTS packages (like Baan, PeopleSoft, and SAP)

- Developing data and information warehouses

- Establishing central operational data stores or data clearinghouses

- Implementing Enterprise Portals

- Using Middleware

- Using XML

- Reengineering all applications to a single architecture

All of these approaches have value and some will even provide at least temporary benefit. However, unless they are business-driven and model-based they are more likely to further compound the problems than provide a solution.

Strategic Enterprise Application Integration is the solution.

This paper describes a method that unifies these approaches as well as other best practices and techniques. Strategic Application Integration really works! It not only solves today's problems but also helps prepare our clients for success in the future.

Strategic Enterprise Application Integration reduces maintenance overhead while providing better customer service and quality information systems. The ultimate goals of Strategic Enterprise Application Integration are shared, non-redundant data, trusted strategic information, and shared reusable software components.

Strategic Enterprise Application Integration is flexible enough to work in any Information Technology environment, yet rigorous and disciplined enough to produce results consistently. Strategic Enterprise Application Integration solutions differ from enterprise to enterprise depending upon their business requirements, the nature and seriousness of their problem, and the skills and availability of their staff. Most variations include the following activities:

- Define and document strategic enterprise business drivers

- Reverse engineer existing applications and databases to document and model the existing application architecture (it exists whether or not it is documented)

- Define and model business information and data requirements (current and future)

- Define and model business functional requirements (current and future)

- Compare application architecture models with requirements and perform gap analysis

- Choose appropriate integration method(s)

It is really important to know what to integrate and why before deciding how. Integration options include:

- Integrate current applications (data and function) that meet requirements

- Reengineer using new technologies

- Use middleware

- Remove redundant and unnecessary applications

- Develop or purchase applications to meet new/changed requirements