The article in this weeks reading by Burch₁ provides an excellent framework on how to organize for system maintenance, hints for improving system maintainability,  as well as methods and tools for helping the maintenance professional.  But perhaps most importantly, at least from the IT Manager's perspective, the article provides some keys for gathering information about the maintenance process. That information can be a valuable asset in assisting the IT manger in a determination as to whether to to take a serious step in the systems life cycle - migration from a centralized to a distributed type of architecture.

Question: By the year 2000, what percentage of organizations that utilize legacy mainframes will have completed migrating their systems to distributed computing (and that desire to do so)?

a. > 50%
b. about 80%
c. > 33%
d < 20%

It is not unusual for people to overestimate the number of systems they believe have been migrated to a distributed architecture. In this lecturette we will examine the frameworks from which legacy systems - those requiring the greatest amount of maintenance are viewed. Some of the issues we will examine include Why migrate? What are the incentives? Dis-incentives? and Why haven't more organizations migrated their systems?

What is a "legacy" system?

If you were to look in Random House Dictionary at the definition for legacy, you would find: "a gift of property especially personal property, as money, by will, a bequest." This is likely not the same definition an IT manager in charge of a legacy system would provide you. Instead they would likely describe it as a system which has been in the organization for some time and that requires quite a bit of care and feeding. A question continually being asked about a system such as that is whether it should be migrated/changed over to a newer more efficient hardware, software and processing platform. It is rather like an automobile that you have possessed for some time, which for the most part is still running reasonably well, but .... The malfunctions are beginning to occur more frequently. Parts are more difficult to locate and more expensive. Mechanics who know and who will work on your automobile are harder to find. And the chances are increasing that you will have a major malfunction and simply not be able to recover. And that major malfunction may just happen when you are 100 miles from nowhere, or even worse in the middle lane of an 8 lane highway traveling at 65 mph.

"Because legacy software systems are so crucial to an organization's survival, they are not retired or redesigned without compelling reasons. Major changes require a huge investment in new technology with the significant risk that the new systems may fail to deliver the required services. Therefore organizations maintain functionality, correct defects, and upgrade legacy systems to keep up with changing business conditions₂ ."

What are the major drivers for migrating legacy systems?

The Gartner Group₃ has looked at this issue from both a technical viewpoint and a managerial one. They summarize their issues in the table below.

Source: Gartner Group

 These issues are so broad based that they provide a framework for a variety of decisions. But they also point out that typically there is a lot more than meets the eye in a transitional effort. Additional factors that the group points out include:

Greater than 50% will experience delays of 1 year or greater in migration
Distributed Computing will increase overall costs, especially labor, for the majority of organizations.
Resistance to change will be the primary barrier in adoption.
Although IT will receive on average about 20% of the total budget, the majority of costs associated with information technology will be hidden in non direct costs.

Anyone who hasn't heard of the Y2K problem by now is a prime candidate for the 1999 Rip Van Winkle Award. Many organizations have been hard at work on this problem for years now. For example in 1997 Levi's Corporation spent their entire software development budget just on the Y2K issue.

The Y2K problem has hit home the need for making a keep or discard decision on legacy systems for many organizations. Horror stories flow freely about such things as lost source code - the english like computer code which must be available to diagnose the presence or absence of date manipulation.  For years organizations have grown accustomed to just pressing the button and expecting the processing to pop out flawlessly at the other end. It was never an issue - it works, doesn't it? But in many cases the original programmers have long since left - without documenting the logic of their code. And now the legacy manager is faced with the possibility that his code has gaps, perhaps serious gaps in its functioning. There are many lessons to be learned from this "crisis." Likely most importantly is the need for a better long term understanding of the actions that are taken by the organization.

A Model for Viewing Migration

To help us understand the long range viewpoint it is valuable to have a common framework for understanding the migration of our systems. The Gartner Group₄ created the following framework/taxonomy for this very purpose.

Stage 0 - Centralized Computing running legacy mainframe systems
Stage 1 - Addition of PCs and stand-alone LANs running workgroup applications
Stage 2 - Business applications on PCs but dependent on business logic or data from legacy mainframe applications
Stage 3: Applications for one Business Unit or mission-critical process completely re-engineered for distributed computing with no dependence on legacy application code
Stage 4: Applications for multiple Business Units or processes are completely re-engineered for distributed computing with no dependence on legacy application code
Stage N: Complete re-engineering of enterprise applications to the distributed model

The Technology Push 
 
From the IT managers macro viewpoint, it also helps to understand where we are with respect to the technologies drivers. If  I, as an IT manager, am about to embark on a major migration program, what can I expect down the road in terms of new technology and when can I expect it to appear? The following chart drives home the massive technology changes that have occurred in the last 10 years. What might we expect in the next 5 or 10 years?
 

1988	1993	1998	2003
Mainframe & Minis	LANs	Internet	?
COBOL	C	C++	?
Green Screens	Robust Desktop	Thin Desktop	?
IBM, DEC, Wang	UNIX Servers	NT Servers	?

 
It has almost become accepted that technology solutions will appear much sooner than we expect. And in that regard we must take care not to adopt technology that will be outdated before we even enter the implementation part of the systems development cycle. On the other hand an OT manager must take care not to get too wrapped up in the latest fads, especially those which do not relate directly to the organizations business processes.

Transitioning  Legacy Software Applications

Part of the IT manager's decision to migrate an application is the decision as to how to best accomplish that task. The following chart portrays the overall options with the two dimensional criteria of speed to market and flexibility.
 

 Source: Gartner Group

Last week we looked at ERP type packages and outsourcing, but there are other growing options as well which transcend the old method of scratch programming. They are business objects and application templates. Both these options are becoming more popular as we move to distributed computing and larger networks. Lotus Notes Domino for example allows any user to very quickly establish an internet based database using an application template. The user can also very quickly establish access privileges, and replication cycles. Replication allows only the latest changes to a database to be sent to other copies of the database which may reside in other worldwide locations. This saves significant data communications costs

Certainly with respect to legacy code there are other options as well - ReWrite, Modify and Salvage. Are there others?
What are the benefits, disadvantages of each?

Peculiar requirements of Client Server/Distributed Systems

The new focus upon long term issues and a migration from legacy systems should bring an IT manager's eyes toward the particular requirements of distributed computing.  Generally the move creates a change in the role of the IT manager from being the "provider of answers" to "caretakers of the infrastructure." The systems the IT department previously closely controlled now become much more complex to develop and maintain, are more end user focused. They also require significantly more testing - systems wide, for usability and security (basics, rollback and recovery).
 
 The table below highlights many of the issues and associated cost with which a distributed architecture provides concern. While many of these are evident irrespective of architecture, a distributed/client server framework adds significant additional concerns. Can you pick those out from the list below?

 
 Source: Gartner Group

Particular Points to Remember

We have looked at system maintenance from the standpoint where a manager is about to embark upon a major migration plan. Experience has taught other IT managers that those about to embark upon this journey should pay particular attention to the following points:

Technology moves forward relentlessly
Right now more questions than answers
Migration is a multi-faceted beast
Strategic plan should be a road map
The CIO must manage Mission, Budget, Politics and approvals, Skills and Training, Contractors, Technology, and  High Level Project Management
Investment in changing infrastructure is a fact of life - Training is a critical part of this investment.

1. Burch, J.G. and Grupe, F.H. "Improved Software Maintenance Management." Information Systems Management, 10(1), 24-32. 1993.

2. Schneidewind, Norman and Ebert, Christof. "Preserve or Redesign Legacy Systems?" IEEE Software. July August 1998.

3. Dec, K., Mack, R. and Andren, E. "From Mainframes to Distributed Computing: The Management Issues" Gartner Group Strategic Analysis Report. 23 July 1998

4. Dec, K., Mack, R. and Andren, E. "From Mainframes to Distributed Computing: The Technical Issues" Gartner Group Strategic Analysis Report. 26 February 1998
 

Answer: d. < 20% According to the Garner Group - (with a .7 assurance factor). In 1997 only about 5% of organizations had completed the transformation. And less than 33% of critical core business applications have been migrated beyond the mainframe environment.   [Go back]
 

No Discussions or Organizational Paper sections due this week. Finish Work on Paper #2.