- The Computer of the Future Meets Reality
- Information Technology Is Your Business
- Public Sector Recognizes Critical Value of IT
- IT Can Disable an Organization
- Rapidly Shifting Business and Technological Requirements
- E-Business Meets Aging Hierarchies and Infrastructures
- No Easy Answers to Difficult Legacy Challenge
- Business Agility and Legacy Systems
- Redesigning Business Processes— Enabling the Agile Enterprise
- The Evolution of Legacy Computing Architectures
- The Business Case for Legacy Architecture Transformation
- Crafting a Strategy to Address the Legacy Architecture Challenge
- Taking on the Legacy Challenge
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.7 No Easy Answers to Difficult Legacy Challenge
Businesses have always been very dynamic, and information architectures have remained largely static. Over the years, the gap has grown between how most businesses work and how legacy architectures function. Management is typically aware of this and would like to find an easy solution. H. L. Mencken has been quoted as saying, "For every complex problem, there is a solution that is simple, neat, and wrong." IT has been looking for simple, neat solutions to the legacy systems challenge for decades.
Prior attempts to address this situation have ultimately failed. During the early 1980s, an early attempt to displace legacy systems, and IT in general, drew upon fourth-generation languages (4GL). By the end of the decade, some predicted, we would have no more need for programmers, because users could simply write new systems whenever they needed them. This did not happen.
The Computer-Aided Software Engineering (CASE) solution of the late 1980s and early 1990s would allow analysts to generate systems from business models. The idea was a good one, but the methodology and tools behind the idea were not. This solution also fell flat.
In the early 1990s some IT organizations attempted to rewrite all of their systems in C and put them into workstation-based environments. Mainframes would be gone by the mid-1990s, according to some analysts and executives. This also failed, largely because an enterprise cannot rewrite legacy systems when it does not understand what those systems do.
The most prevalent and innovative solution to date is still under way and will continue to be viewed as a partial or interim solution in years to come. It is called enterprise application integration (EAI).
The EAI concept is simple, although implementation results have grown increasingly complex. EAI can be viewed simplistically as the collective disciplines and technologies used to connect front-end and back-end applications and databases in such a way as to not impact the underlying legacy architecture. In other words, EAI is a "noninvasive" approach to meeting complex integration and business process retooling requirements.
EAI requirements are driven by the need to synthesize disparate systems and data to support various e-business, customer, supply chain, and distribution chain requirements. The industry has tried to subdivide EAI into internal (i.e., enterprise) and external (i.e., supply and distribution chain) integration. This latter category has been termed business-to-business integration (B2Bi). B2Bi is increasingly being viewed as an extension of EAI because the border between internal and external systems, and data and business units continues to blur.
As the IT industry moves toward architectures that utilize Web Services, for example, the issue as to where a given transaction begins and ends will blur to the point where it is no longer relevant. Many of the e-terms and c-terms we use today will likely either merge into a commonly understood discipline or disappear entirely. For our discussion, consider EAI to mean the noninvasive integration of internal and external systems and data structures.
Early on, EAI was simply a series of application programming interfaces (APIs), which evolved into middleware to "connect" applications. These connector-based solutions proliferated. As a result, EAI has been plagued by quick fixes, technocratic thinking, disjointed projects, false starts, inadequate requirements, and a tendency to ignore more strategic integration options.
EAI clearly plays a role in near-term and ongoing efforts to meet critical information integration requirements. Over the long term, however, the connector mentality, regardless of the degree of sophistication the middleware, application servers, and other components achieve, will be viewed as yet another level of hard-to-decipher legacy software.
Interim solutions may have a place in complex business environments as long as they are viewed as such. Noninvasive integration, however, must give way to more strategic and sophisticated thinking over the long term.