- 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.12 -Crafting a Strategy to Address the Legacy Architecture Challenge
IT or business executives would never actually say, "Let's transform our legacy systems." On the contrary, application projects are driven almost entirely by unique business requirements, with the expectation of near-term results. Occasionally, a strategic project may be funded over a period of more than a year, but this tends to be the exception more than the rule. A legacy transformation strategy recognizes where certain techniques or concepts can be applied to augment traditional IT initiatives to save time, reduce risks, lower costs, and increase the overall quality of the project.
These concepts, which will be explored throughout the remainder of this book, include
High-level and detailed application analysis and re-documentation.
Selective application of EAI solutions.
Program-level and system-wide improvements in legacy systems.
Language migration.
Data consolidation, migration, and cleanup.
Rehosting or migrating legacy systems to modern platforms.
Applying modern distributed front ends to legacy applications.
Redesign and reuse of legacy business logic.
Redesign and redeployment of legacy data structures.
Package software/legacy application hybrid deployment.
Augmentation of new development efforts through legacy analysis and reuse.
Any project impacted by or relying on one or more legacy systems or data structures can apply these concepts. The role of the management team is to understand where and how various approaches can be applied and in what combination. To accomplish this, an organization should create a transformation strategy that enables and encourages the use of legacy transformation concepts and techniques on projects. A legacy architecture transformation strategy should minimally include the following items.
Recognition and concurrence from the executive team that legacy architectures must be considered and accommodated in any type of project impacting or relying on legacy systems or data structures.
Executive support, senior management sponsorship, and well-placed transformation champions.
A general understanding or map of legacy architectures, including how systems relate to other systems and data structures.
An understanding of which systems support which business units and underlying business functions and processes.
Processes for assessing, planning, improving, integrating, transforming, and testing legacy applications.
Access to or an understanding of software tools needed to facilitate assessing, planning, improving, integrating, transforming, and testing legacy applications.
Scenario-based planning guidelines identifying the legacy transformation tasks needed to augment a variety of IT projects, including new development, package selection and implementation, and integration efforts.
General guidelines for assessing the value to be gained or cost savings associated with incorporating legacy transformation techniques into a project.
Organizational infrastructure necessary to facilitate and maintain this legacy architecture transformation strategy.
When assessing and developing such a strategy, there are several major factors to be considered. These factors include people and the roles they play, organizational infrastructure, project planning, cost analysis, and third-party participation.
For example, most people in a given IT organization are not predisposed to looking into invasive approaches for addressing issues related to legacy systems or data structures. Legacy transformation may require a shift in thinking. People have a throwaway mentality. Many things we purchase today are inexpensive or designed to be tossed out. My grandfather would be appalled at the thought of tossing out my razor when I finished with it. Throwaway cameras are another example of this concept. The idea of recycling, however, is well accepted, and that is what IT is doing when it seeks to transform and reuse legacy business rules and data.
Organizational infrastructure requires the enterprise to be set up to encourage and enable legacy transformation. This requires examining relationships within IT; between IT and the business units; and between IT, the business units, and third parties. Infrastructure also requires communication and collaboration facilities for knowledge sharing, tool distribution, training, technique deployment, project planning, and support.
Another infrastructure issue must consider prejudices of new development teams against anything that is not technologically state of the art. People working with Java, XML, and a host of newer methodologies and tools are not predisposed to working with anything with the term legacy attached. Dealing with these prejudices will need to be done judiciously.
One last infrastructure issue requires the creation of an environment that supports legacy transformation. This includes tools, training, techniques, and preliminary assessment projects. There is, of course, an initial level of funding needed to support such an infrastructure.
Project planning and cost analysis go hand in hand. Traditional development, upgrade, or other types of deployment plans, based on whatever planning methodology is used, will need to be augmented with various legacy techniques if an enterprise wishes to pursue a transformation strategy. This assumes IT does this type of planning in the first place—which it should. It also requires transformation specialists to assist with incorporating these techniques into project plans. Cost analysis is based on augmenting traditional cost models based on these plans.
Finally, third-party participation is a vital component of any transformation strategy. Management may adopt such a strategy, set up the infrastructure, and engage inhouse professionals, but end up having the entire effort sidestepped by a systems integrator, outsourcing firm, ASP, or management consulting firm. Certain consulting firms do not embrace legacy transformation options because it is frankly more profitable for them to apply traditional techniques to most IT projects. I will share a case study on such a project during the cost justification discussion in later chapters.
Third-party consulting or outsourcing firms may just not have the know-how or tool-based experience to engage in discussions about legacy transformation. This is a matter of education. Executives should be aware that a third-party recommendation not to incorporate legacy transformation into a project could be based on the fact that transformation options would reduce the implementation effort and therefore the fees to be charged for that project. Or it may just be based on a lack of experience with these techniques and related tools. Either way, executives should challenge third parties to incorporate a transformation mindset into their project plans.