- 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.13 Taking on the Legacy Challenge
Legacy transformation does require a shift in thinking, but it is a slight shift in thinking. The concept of understanding what you are replacing prior to building a new system is not radical. Neither is the concept of reusing established, reliable business logic. Programmers have been doing this on a small scale for years, but that was back when legacy programmers were still building replacement or add-on systems.
Today, however, a 20-something Java programmer would never think to go back and examine a COBOL or PL/I system to determine where and how reuse could be leveraged as part of the planning, analysis, design, and deployment process. A formal legacy transformation strategy would therefore compensate for loss of the legacy expert's insight into these systems.
It takes a person of conviction at the executive level to stand up to peers and incorporate legacy transformation options into more traditional project plans. Over the years, some executives made these commitments, and I will share certain studies outlining how they did.
Legacy transformation tends to boil down to common sense. The business has changed, but the systems have not. Writing a new system is time-consuming, costly, and rarely if ever replaces the need for the legacy system or systems it was supposed to replace. Buying a package makes better sense, but many times companies end up leaving inhouse legacy systems intact even after a package is partially implemented. This is the result of realizing that a package can sacrifice strategic value of inhouse systems that may have been doing a better job in the first place.
Connecting legacy architectures to new Web-based applications has merit, but this assumes that the legacy architecture can mimic the demands of high-speed, Web-based environments. Legacy systems and data were not meant to perform in a zero latency environment, and even the best EAI technology cannot change this situation.
Finally, there are the basic requirements involving the enhancement of legacy systems and data structures required as part of ongoing business operations. Clean, consistent data is a requirement if data is being opened up to customers or business partners or being used as part of a CRM initiative.
Enterprise executives that ignore these factors are more likely than not betting that they will be gone long before legacy systems catch up with them. This may be the case, but legacy systems will catch up with the enterprise as a whole sooner or later. That will be the time when someone will wish that a legacy transformation strategy had been deployed before it was too late.