Dealing with Legacy Reality in an Integrated and Ever-Changing World

 Jaap Schekkerman, B.Sc

Thought Leader Business Technology Strategy &

Enterprise Architecture

White Paper

Content

Content.. 2

Legacy Reality.. 3

Legacy Reality intro.. 3

Legacy Reality in Context. 6

Legacy Portfolio Approach.. 8

Legacy portfolio As-Is Inventory. 9

Mapping Legacy Systems to the Business Processes. 9

Validation of the Business Processes to their contribution to the business. 10

Evaluation of the Legacy Portfolio. 11

Identification of the To-Be Situation. 13

Definition of the Migration Strategy based on Legacy Concepts. 13

Definition of the Migration Plan. 15

Transition of the Migration Plan to the timeline. 16

Definition of the Migration Program Structure. 17

Conclusion.. 18

Appendix A.. 21

References. 21

Legacy Reality

This white paper is a popularised and refined version of IFEAD's opinion regarding Legacy Reality and defines its strategy for dealing with these phenomena.   References to other documents, etc., that describe specific areas of Legacy Reality in more detail will be provided in Appendix A.

The major challenge for future business operations is aligning changing business goals with changing technologies, while at the same time taking business critical legacy systems into account.

The term Legacy as used in this white paper expresses all those systems (or parts of systems) that no longer meet enforced standards. The fact that standards evolve over time, implies that the existence of Legacy Systems is both today’s and tomorrow’s reality.

In order to describe our opinion of Legacy Reality, it is essential to place it in the systems development context. To do this, the System Life Cycle Model will be employed. This model positions the most important activities during the systems design & development process and express the different roles involved. [1]

This model is also very helpful in identifying the right moment for addressing the Legacy Reality issue.

For the purposes of this paper, the term “system” encompasses individual applications, systems in the traditional sense, subsystems, and systems of systems, product lines, product families, whole enterprises, and other aggregations of interest.

IFEAD's opnion regarding the Legacy Reality issue is that it is a combined technology and business issue for which Legacy Concepts are the key enablers for aligning changing business goals with changing technologies.

The Legacy Reality opinion is carried by the Legacy Reality model, which is a model strongly related to the context of architecture and based on the thoughts of the IEEE 1471 working group “Architectural Descriptions” [1].

Legacy Concepts are predefined architectural based concepts that identify potential solution directions related to the individual Legacy reality.

The alignment of changing business goals with changing technologies, while preserving the assets that are hidden in the legacy systems supporting today's business operations, is the real challenge.

The Legacy Reality model clarifies the relations and elements that play an essential role in the decision-making process. The Legacy Reality model is focused on systems whereby the mission of the organisation is the central factor and the stakeholders play a secondary role. The architecture based legacy concepts show alternative solution paths.

The fact that a system exists in a given environment implies that the setting and circumstances, as well as the developmental, operational, and political currents within that environment, will exert influence upon that original system.

In addition to those factors, consideration must also be given to other systems that exist in the same environment, either directly or through interfaces. Consequently, the environment in which it exists bound the scope of a respective system.

As mentioned above, stakeholders also have interests in, or concerns relative to, the respective system. Concerns are those factors, which pertain to the system’s development, its operation or any other aspects, which are critical, or otherwise important, to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.

A system exists to fulfil one or more missions in its environment. A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. In a legacy portfolio based approach, the objectives are the drivers for the different concepts.

The legacy portfolio approach will lead to different legacy concepts that can serve different goals and missions; therefore there are different concepts to address the Legacy Reality. The most important concepts [0] in this context are the concepts of system wrapping [4], system renovation [5] and the concepts of system replacement and system retirement.

We recommends a phased approach to deal with the legacy issues that encompass the legacy portfolio, refined IT strategies and systems transformation to support, in most cases, a renewed business model [2].

The Legacy Portfolio Approach addresses both changes in business and technology and is supported by the Legacy Reality model. This phased Legacy Portfolio Approach addresses the following main items:

Changes can take place in the four elements of the Legacy Reality model that influence the appearance of a system. These changes can be e.g. another way of working, different business objectives, alterations in business direction, etc. These changes influence the enforced standards to new standards in which the existing systems are unable to follow. This is the base of the Legacy Reality.

Every information system within the scope of a domain of business processes will be part of the As-Is situation. Consequently, an inventory of the business and the information systems both internal and external to the domain is necessary. This inventory should minimally include a list of the systems and their owners, and system dependencies upon other systems. In addition to the above, all legacy systems should be divided into a distinguishing category, for example:

The result of the As-Is inventory is an overview of the business, the supporting systems and the relations and dependencies between systems. Documenting the As-Is in an architectural way is very helpful in the phases that follow.

The existing legacy systems are mapped to the business processes to identify their possible support of these processes. This is done based upon the business value chain of the As-Is or To-Be situation (dependent upon whether the business is changing or not).

This mapping allows the level of support to the different business processes as well as the overlap, alignment and integration of functionality with other systems to be identified.

To identify the relative importance of the legacy systems for the business, the related business processes are validated to their level of importance to the business.  Cross-referencing the processes with their contribution to the business does this.  The end result of this activity is a Business Value List

The combination of the mapping and validation steps delivers an overview of the importance of the business processes and the supporting systems. This information can further be used in the next step to determine the effectiveness of the legacy systems.

This phase begins with an evaluation of legacy systems according to two criteria: how effectively a given system supports business missions, goals and objectives, and how efficiently this system performs its tasks [3]. To do this assessment for every legacy system, the scale of system effectiveness must be expressed in either financial (e.g. value based proceeds), or other definable terms. Once these terms are chosen, it is essential that the scale of efficiency is also defined in the same way (e.g. value based costs). It is important to note that Effectiveness and Efficiency (E2) are not singular entities; they are in fact, compound identities for different individual elements.

E2 Mapping

The acronym for Effectiveness versus Efficiency is E2.

Expressing the E2 results on a grid shows the relative position of systems in relation to their contribution to the business mission and goals. It also demonstrates how well they are doing that. Doing this analysis for the whole systems portfolio it is possible to identify the right moment in which to take action against those systems that do not support the business in the appropriate way. The results of this assessment are mapped on a grid containing the four predefined areas of legacy concepts and their suggested actions.

Legacy Concepts

1: System Wrapping [4]

Systems with a high business value and a fair technological condition (in regard to their technical functionality) must be maintained. These systems can be wrapped to isolate the “gold” and to assure that they can flexibly interact with their environment.

Most legacy systems have been in use for several years, sometimes-even decades, during which time both the technical and logical bugs have been repaired. Consequently, the systems are now quite stabile. Furthermore, a solid management routine has been developed and deployed. The end results being that these systems have become both very valuable and very inflexible.

Internet enabling these legacy systems increases their flexibility, which in turn increases the flexibility of the whole organisation. Simply adding Internet capability to these legacy systems increases both their flexibility and the flexibility of the whole organisation, but does little to assure that the system can be modified to meet future business requirements.  In order to counter this disadvantage, a general framework (an architectural concept) needs to be employed to assure that future development is not hindered. One-way to accomplish this is to web enable (wrap) the legacy and to disclose the ‘gold’ in these systems in an intelligent way. The technique of wrapping legacy systems can be used not only to open the Internet world to legacy systems, but to encapsulate a systems from its environment in such a way that the legacy systems acts as a black box for its environment.

2: System Renovation [5]

Systems with a high business value and a bad and unmaintainable technological condition must be renovated. Additionally, systems that have a low business value and a good technological condition must be renovated too.

In both situations, they should be renovated to meet both existing and future business goals.

System renovation prepares a legacy system for future changes. It is based on the view that an organization's software systems provide valuable functionality and have a proven track record. At first glance, one would assume that they should be reused whenever possible; but further review often proves that the packaging of the business functionality is far from optimal.  These systems are often based on old languages, database systems, and transaction monitors, which are monolithic in design and un-maintainable as a result of repeated undocumented modifications. Furthermore, the lack of knowledge of the old systems and the need to train new users of these systems (when used in renovated form) make the potential adaptation and prolonged usage of legacy systems difficult. As a consequence, legacy systems are very hard to change (if not immutable) and prohibit the desired business alignment.

These problems are the basis of Software renovation, which is a pro-active software maintenance technique aimed at improving the overall quality of software systems; while at the same time improving the functionality of these systems and making them easier to both use in and adapt to new application areas. Software renovation has its roots in a number of related areas. As it is fairly common that the only reliable information about what a legacy system does is the source code itself, reverse engineering is an essential aspect of software renovation. In software reverse engineering; we try to distil as much useful information as possible from the system's legacy sources. The key challenge of reverse engineering is to arrive at non-trivial, higher levels of abstraction than just the source code.

Software renovation also includes modifying the software in order to improve it. Such transformations may remain at the same level of abstraction, in which case we speak of system restructuring or refactoring.

The alternative is to perform the renovation via a reverse engineering step, which is called re-engineering: first a specification on a higher level of abstraction is constructed, then a transformation is applied on the design level, followed by a forward engineering step based on the improved design.

Last but not least, the year 2000 problem and the Euro conversion have strongly affected the area of software renovation. They have resulted in an increased awareness of the need for tools for reverse and re-engineering, adoption of source analysis and modification tools, and they have increased the maturity of the renovation tools and techniques available.

3: System Replacement

Systems that deliver tangible business benefits while at the same time being in fair technological condition should be replaced in order to avoid them becoming a cost or functionality drain on the business.System Replacement has an impact to the business as well to the technology. From a business perspective, a new system has to be implemented and will influence the existing way of supporting the business. Additionally, users will have to learn to work with another system. The end result is that the business impact is significant.From a technology perspective the migration and transition aspects are the most important issues to be addressed with this concept. Attention to the organizational and technical aspects is critical during the migration phase. Even so the derivation of management information from the legacy and the new systems has to be guaranteed during the transition. Integrity and consistency of information during the transition time are important elements to address in the project’s migration planning. Program management and process management skills and experiences in this area are also critical success factors during a migration program; especially when the transition time is spread over a long period and exiting and new systems must be interact together.

4: System Retirement

Systems that have a low business value and are technologically inefficient are candidates for retirement.

The planning aspects are the most important issues to be addressed with this concept. Attention should be paid to the organizational and technical aspects during the retirement phase. Even so, historical information and the possibility of recovering information from backups of the retired system should be kept in mind. Program management, process management skills, and experiences in this area are critical success factors during the retirement phase; especially when the time to phase out is spread over a long period.

Use of Legacy Concepts

Legacy concepts are applicable to a variety of uses, by a variety of stakeholders, throughout the system life cycle.

These uses include, but are not limited to:

·         Analysis of alternative concepts and solutions;

·         Business planning for transition from a legacy architecture to a new architecture;

·         Communications among organizations involved in the development, production, fielding, operation and maintenance of a system;

·         Communications between acquirers and developers as a part of contract negotiations;

·         Criteria for certifying conformance of implementations to the architecture;

·         Development and maintenance documentation, including material for reuse, repositories and training materials;

·         Input to subsequent system design and development activities;

·         Input to system generation and analysis tools;

·         Operational and infrastructure support, configuration management and repair, redesign and maintenance of systems, subsystems and components;

·         Planning and budget support;

·         Preparation of acquisition documents (e.g., requests for proposal, statements of work);

·         Review, analysis and evaluation of the system across the system life cycle;

·        Specification for a group of systems sharing a common set of features, (e.g., value chains or product lines).

The “To-Be” situation will reflect any new standards imposed by management. This will be a new stable-state situation until new changes are again imposed. Reaching the “To-Be” situation requires that every system within the domain must migrate to the new standard. This can mean that one or more existing legacy systems will also need to be brought into this new environment. In order to identify the impact of this migration, an analysis of the “to-be” definition is necessary.  The following aspects should be taken into consideration during the evaluation:

Migration Strategy

Based on the input from the “as-is” and “to-be” situation, a migration strategy must be set up for the business processes and for each supported system, based upon one, or more legacy concepts:

1.      System wrapping;

2.      System renovation;

3.      System replacement;

4.      System retirement.

After the evaluation of the legacy portfolio, and the To-Be desired situation, the organisation should focus on how it can recover the greatest value from its legacy assets. It does this by accommodating a mix of multiple architectures, languages, and platforms, based on the different legacy concepts. In doing so, it should consider a number of new strategies and tools, including reverse engineering, standard package software (package based solutions as alternatives for renewal), architectural layering (multi-tier architectures), data warehousing and outsourcing, etc. After the new strategy has been defined, the organization must focus on the implementation and transformation of the legacy systems using one or more legacy concepts.

 Integration Framework

The “Integration Framework” [9] is a helpful instrument integrating systems, based on multi-vendor / multi-technology experiences. This integration framework supports the concept of integration the layers ranging from business to infrastructure.

The integration framework is much more than a mechanism for integrating data, applications and systems; it is in fact a process, which guarantees that the IT will be reflective and supportive of the business strategy of the organisation. Its key to success being its ability to integrate the computing environment with the business processes; thus providing a way forward, and a direction for the future.

Impact analysis

Once the strategy for the transformation of the legacy systems is chosen, an impact analysis must follow to confirm that the choices made are applicable to the situation at hand. Depending on the results of this impact analysis, the Migration Strategy can be refined. An important item that has to be addressed during the impact analysis is the consequences upon security during all the transition phases and in the final To-Be situation.

Overall Migration Plan

To migrate from the As-Is situation towards the To-Be situation it is necessary to address several issues from a business perspective as well from a technology perspective.

Scope

To define the scope the of the legacy reality we focus on certain domains. A domain is a sub-set of the total of business processes as well as their information systems, which are bounded together in one business area together with its affiliated information systems. Theis business area will have a clear objective that is in fact the focus of the domain. A domain consists of several different aspects such as: Mission, Environment, Architecture, Stakeholders and Information systems. The extent of the domain wills depend upon the strategic choices management makes in defining the business objective.

Business Perspective

Procedures

Every business objective is accomplished through the use of procedures, which in turn may be supported by systems. This means that should a standard be changed, the procedures may need to change as well. Changing procedures may have a major impact on the manner of performing work. It is for this reason that each procedure within the domain needs to be apart of the inventory, and must be accounted for in view of the To-Be situation.

Stakeholders

Without specific stakeholders it is not possible to fulfil any business objective. Specific stakeholders are important assets as a source of knowledge of the business processes and the functionality’s of the systems. For the migration of the system there is a need to recognise and register the different types of stakeholders. [0]

For each of the stakeholder groups, a separate migration program must be defined.

Dependencies

Between business processes and systems there will be dependencies. These dependencies determine the order of the migration of the systems. For example the systems that receive (electronic) data from the outside world must migrate in a timely manner so as to account for this data format.

Technology Perspective

Best practice-conversions (improve and align the As-Is situation)

Improving the non-legacy systems is often the first step in a legacy migration plan. Because the non-legacy systems and the renewed systems have to function as a whole, some improvements (e.g. development of new interfaces) are often necessary.

Implement migration strategy

The implementation of the migration strategy is strongly dependent upon the chosen legacy concepts and the As-Is and To-Be analysis. For example, if renovation based on ‘gold’ isolation is the best solution and the To-Be Architecture has to deal with the concept of front, mid and back offices, then the possible migration steps could be:

·         Develop mid-office;          

·         Develop front offices;       

·         Uncouple generic ‘golden’ components from legacy systems;

·         Incorporate generic ‘golden’ components in renovated back-office systems; and

·         Integrate existing and renewed systems as a whole.

Maintain the Integrated Architecture        

Maintenance of the integrated architecture is a necessary action to prevent misalignment of the architectural standards, principles and guidelines of the supported systems.

When the migration plan covers a longer time period, periodical re-consolidation of the standards, concepts and techniques must be done to guarantee alignment with evolving technologies and standards. 

A transformation from the As-Is situation to the To-Be situation will take time. A timeline and a corresponding planning will be necessary. To develop a plan, a base line will be needed that accounts for decisions regarding the elements from the business as well as the existing systems that will continue to be employed in the new situation. This base line must be documented, and it belongs to the standards of the To-Be situation.

Management will have to set up a primarily timeline based on the desired business needs. This timeline is one of the strategic choices that have to be made. The above example shows a timeline from a technology perspective. A corresponding timeline from a business perspective has to be made, and brought in line with the timeline from the technology perspective.

Having identified that there is a business stream and a technology stream in the overall migration plan, it is essential that the organisational structure be implemented to manage and align them. In addition to managing this transition, a migration program also has to recognize that the ongoing business must continue. Depending on the complexity, overall timeline, number of systems involved and changes in the business, separate streams may need to be defined to manage specific elements. The above figure is an example how to organise the migration program.

The major challenge for future business operations is to align changing business goals and changing technologies, while preserving the assets that are hidden in the legacy systems.  To do that, the legacy portfolio approach is an essential instrument for continuously managing your systems portfolio.  The vision and approach is based on both scientific research and best practices accumulated from around the world.

Appendix A

[2]        ‘Application Servers: Creating the Web-enabled Enterprise’, © 1999 Rapport, Ovum Ltd.

[3]        ‘Legacy Asset Management’, Computer Sciences Corporation, white paper, 2000.

[4]        ‘Vision for the Web Legacy Development’, , December 1999.

[5]        ‘From Legacy to Component: Software Renovation in Three Steps’, CWI University of Amsterdam, May 2000.

[6]        ‘The Architecture Process Cycle, The IAF WinWin Spiral Model’, Schekkerman, ing. J., in: ‘ICT Architecture in the BeNeLux 1999’, uitgave Faculteit der Exacte Wetenschappen, Vrije Universiteit, Amsterdam,1999.

[8]        ‘The Integrated Architecture Framework’, Schekkerman, ing. J., Netherlands, 1999.

(C)Copyright IFEAD, 2001 - 2006