Academic journal article The McKinsey Quarterly

Avoiding the Mainframe Trap in Redesign

Academic journal article The McKinsey Quarterly

Avoiding the Mainframe Trap in Redesign

Article excerpt

Subject: Avoiding the mainframe trap in redesign From: Richard Heygate Date: Autumn 1993

I've pointed out to you before that the maximum amount of software any company can change in a three- to four-year period is two million lines of code. You now have more than ten million lines in your core portfolio of integrated systems. No wonder every redesign-related project your people tackle has expanded dangerously in scope to address everything that needs changing and then fallen rapidly off the track and further behind schedule as new customer needs emerge. Putting more bodies on the project will not change anything. If you stick to the road you're on, you simply cannot get there from here.

As you know, many well-intentioned efforts to redesign or re-engineer a company's core processes produce only minimal benefits. The reason usually has little to do with the variety or quality of improvement ideas and everything to do with the ability of each company's execution mechanisms -- in particular, its IT competence and delivery processes -- to make real and tangible the value contained in those ideas. There is no point in loading up the "hopper" of an execution engine that is fundamentally broken.

Effective redesign means constructing information flows across the many functions involved in managing an end-to-end core process like customer satisfaction or product development. It also means building critical new skills among huge numbers of people through screen-based systems that offer guidance and help with key decisions. Yet the ability of MIS functions to deliver against these needs has never been so much in doubt. Time after time, the potential value to be unleashed through redesign remains stacked up behind IT bottlenecks, months if not years after implementation should be complete.

There is, however, a way to proceed with cutting-edge redesign that will not catastrophically overload an already fully stretched IT implementation engine. Just think: for years now, major telecoms around the world have had to support rapidly changing customer needs -- PBXs, cellular phones, fax machines, and the like -- without throwing themselves open to a sudden, wholesale conversion of their established technology base. What they've done is invest in various "front-end" or "interface" technologies that provide, in effect, a kind of adjustable buffer or filter between installed base and new application. That way, they can permit developments on either side of the filter to proceed at their own pace -- and to converge and connect only as and when it makes sense to do so.

The use of such redesign filters is by no means limited to telecoms. A major European financial institution has, for example, recently built -- in less than nine months -- an entirely new, telephone-based bank on the back of its old software portfolio. As in telecoms, the secret is the innovative use of "front-end" software technology as a filter -- a controllable interface -- between old and new sets of activities.

Filters that work

The goal here, remember, is to leverage existing investments in mainframe data and application systems in support of redesign efforts -- but to do so without putting the costs, timescales, and risks of changing these old systems on redesign's critical path. Your mainframe systems may be old and inflexible, but they represent a huge of information about your company and the processes it uses. What you want to do is to be able to tap into all this valuable stored knowledge in ways that do not undermine, delay, or distort the uses to which it is to be put.

In practice, then, effective leverage means working deliberately back and forth across a front-end filter that is:

Invisible

If your old systems are to be useful in redesigned processes, your new applications must be able to communicate with them in a way that is invisible to their software. Whatever appears on users' terminal screens or through their printers -- no matter how novel the format or arrangement of information -- still has its roots in the data structures of "back-end" mainframe systems. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.