The Integration Challenge

For most companies of any size, the process of developing and implementing Enterprise application integration is a daunting task. The information technology (IT) infrastructure at most companies includes the following:

• A variety of different hardware platforms and operating systems
• Diverse software applications purchased over time
• Custom applications developed for specific purposes
• Packaged applications

Most organizations use a variety of hardware systems and software applications for critical business processes. Due largely to historical circumstances, these "back office" systems and applications represent purchases made over a considerable time, sometimes spanning several decades. This collage of software likely includes some packaged applications as well as custom applications developed in house or by vendors. Most custom applications were designed and built to accomplish a specific task well for a specific set of users, without much thought toward integration. These stovepipe systems, as they are often called, exist in most large organizations.

The applications used in an organization were likely built with different tools that leverage technologies available at the time. The mix of applications may include host applications running on IBM mainframes and minicomputers, distributed client/server applications, and newer component-based applications using distributed objects. The host applications may have been written in COBOL or PL/I to access transaction programs running on host computers and VSAM data files. Some of the client/server applications were written using proprietary fourth generation language (4GL) tools and C/C++ targeted at UNIX systems accessing a Relational Database Management System (RDBMS) using SQL. Others were based on Microsoft Visual C++ or Visual Basic and rapid application development (RAD) tools for accessing RDBMS systems such as Microsoft SQL Server on Windows. More recent applications based on distributed objects were written to operate using Microsoft's Distributed Component Object Model (DCOM), the Common Object Request Broker Architecture (CORBA), or the Java 2 Platform, Enterprise Edition (J2EE). DCOM, CORBA, and J2EE represent competing distributed object technologies. These distributed applications were developed using Visual Basic, C++, Java, or other languages. Internal web site development may include a number of scripted applications based on Visual Basic Scripting and Active Server Pages (ASP), JavaScript, Perl, Python, PHP, REXX, and the Common Gateway Interface (CGI) using UNIX shell scripts. Unfortunately, most of this software was not designed to easily integrate with other applications. For example, existing applications likely use a variety of different methods for authenticating users and providing appropriate levels of security and privacy for privileged data.

For most custom applications, it is likely that your organization has access to the source code for maintenance purposes. Integrating legacy applications may require changes to that source code, which can require extensive testing. Packaged software creates some significant additional problems. Without access to the source code and business logic (usually not an option for packaged applications), the primary options for integration are limited to those provided by the vendor.

In addition to back office applications, most organizations use a number of office productivity tools on desktop Windows or Macintosh computers as front office applications for email, document preparation, graphics, spreadsheets, small database applications, and other purposes. Very often, the information maintained in packaged desktop software applications grows over time to become critical to internal business processes and operations.

Acquisitions, mergers, and company reorganizations are only likely to have complicated this equation even more. Different companies or departments may well have followed very different development styles and cultures and used different technologies when implementing Information Technology (IT). For example, the finance division in one company was conservative and used host-based software on mainframes and minicomputers. In contrast, the human resources department may use software mostly on desktop Windows computers. Even for recent applications these differences are sometimes stark. For example, one company may have invested in custom applications based on DCOM and Visual C++, while another company may have based recent development on CORBA and Java. Now all of these software applications need to integrate with one another.

The following figure shows the requirements for increased communication across departments, along with the difficulty of integrating stovepipe application systems.

The chaos of applications in the enterprise

In hindsight, it is easy to say that these problems are a result of a lack of enterprise resource planning over time. But this is a vast simplification. When the core applications in some organizations were first developed a decade or two ago, who would have guessed that they would still be in use now. Last decade's developers could not have imagined and anticipated the distributed systems and distributed object technology we use today.

If money were no object, we would throw out all of the existing business software and start from scratch building applications using the latest and greatest technology so they can easily integrate. In the real world such a strategy is impossible (except for a few well-funded startups with no existing assets). Most organizations have made enormous investments in existing hardware and software that are too costly to replace anytime soon. These applications are essential for conducting business operations. Furthermore, company staff are trained and familiar with running business operations using these existing systems.

So, the challenge for EAI becomes accomplishing the integration process without requiring drastic changes to existing applications.

Previous  Next