Some things are always the same, particularly the business problems facing IT organizations. Corporate management always pushes for better IT utilization, greater ROI, integration of historically separate systems, and faster implementation of new systems, but some things are different now. Now, you find more complex environments. Legacy systems must be reused rather than replaced, because with even more constrained budgets, replacement is cost-prohibitive. You find that cheap, ubiquitous access to the Internet has created the possibility of entirely new business models, which must at least be evaluated since the competition is already doing it. Growth by merger and acquisition has become standard fare, so entire IT organizations, applications, and infrastructures must be integrated and absorbed.

In an environment of this complexity, point solutions merely exacerbate the problem, and will never lead us out of the woods. Systems must be developed where heterogeneity is fundamental to the environment, because they must accommodate an endless variety of hardware, operating systems, middleware, languages, and data stores. The cumulative effect of decades of growth and evolution has produced severe complexity. With all these business challenges for IT, it is no wonder that application integration tops the priority list of many CIOs, as shown in Figure 1.

Figure 1. CIO priorities

Another Problem: Redundant and Non-Reusable Programming

Consider a bank that has separate “silos,” self-contained application systems that are oblivious to other systems within the bank. The first of these application systems may have been an excellent design, as well as the second, third, and so on, but each was produced by and for a different line of business within the bank and was a separately funded, isolated project. Thus, for example, the function of get account balance is repeated in the ATM system, the branch teller delivery system, and the credit card scoring system, even if they access the same account data in the same database.

Now, suppose the bank must develop an Internet service, online banking, and/or an online loan origination system for its customers if it is to remain competitive. The new system will just add to the problem of all the redundant programming already in place, unless somehow the existing code can be reused.

The Real Integration Killer: Multiplicity of Interfaces

Consider also the n(n-1) integration problem. All organizations face integration problems of some sort; perhaps because of a corporate merger, a new business alliance, or just the need to interconnect existing systems. If n application systems must be directly interconnected, it will produce n(n-1) connections, or interfaces. In Figure 2, each arrowhead represents an interface.

Figure 2. Direct integration of n applications

Consequently, if another application system A n+1 must be integrated, it will require that 2n new interfaces be generated, documented, tested, and maintained. While in the diagram above, where the set of five applications requires 20 direct interfaces, the addition of a sixth application will require ten new interfaces!

Worse yet, the code in each of the existing applications must be modified to include the new interfaces, thus generating substantial testing costs. Immediately, you look for the optimum solution that produces the minimum number of interfaces (n) for n applications, with only one new interface for each additional system added, but find that it can’t be done by direct connection.

Page 3: And What of the Future?