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 store 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. The filter must, therefore, provide a set of translation tables that silently and invisibly convert data between the forms in which they are used at both front and back ends.

An example from telecoms will explain what I mean. Old, rotary-switch exchanges received information in the form of a series of electric bleeps. The input/output device for these old exchanges, the dial telephone, generated these bleeps by the rotation of its dial. When customers moved to new, push-button phones before the exchanges themselves migrated to fully digital switches, it was necessary to put in place a translation mechanism that converted the electronic signals from the new phones into the bleeps produced by the old.

User-friendly

The new business processes at the heart of most redesign efforts tend to be cross-functional in nature and, thus, more complex than those they replace. For implementation to be effective, however, the learning times associated with adopting these processes at the front line must be as short as possible. As a rule of thumb, unless learning times can be limited to six weeks or less, the operational disruption of having a permanent training team in place will be high, as will the likelihood of a crippling relapse back to poor-quality operations.

Effective filters help designers build easy-to-use screen-based learning and training systems, which allow simple access to back-end data without the need to learn complex sign-on, menu selection, or other navigation procedures. They can also help improve productivity by providing "scripts" that guide an inexperienced operator through a new process, as well as workflow management and queuing facilities, which make it easier for them to control a multi-stage process. Moreover, the filter’s flexibility allows for rapid modification to support the stream of new operational improvements that often emerge after a system goes live.

Adaptable

Cross-functional business processes rely on a wide variety of media and information sources. A sales or service representative in a bank branch, for example, may now need to access systems that support insurance as well as banking products, to reference credit data held on a third-party mainframe, and to communicate with customers by telephone, fax, hard copy, or even image transmission. Effective filters facilitate all these linkages by providing interfaces adaptable to many different back-end systems.

Why filters work

This, of course, is a lot to claim for using a filter made of front-end, interface technology. After all, I’m just talking about familiar development tasks, such as preparing screens, routing data, and writing new code. And you are right to react to these claims with a bit of caution. But a closer look at the laws and metrics of software development can help explain why these filters work as well as they do.

Bridge-building and testing

We’ve discussed before how software productivity declines exponentially as system size and complexity increase. Even with medium-sized systems, build productivity can decline tenfold or more from that achieved with small, standalone developments.¹ One of the major causes of this decline is the increasing percentage of testing time needed, especially for integration testing, as systems get larger. Indeed, with large systems, integration testing can eat up 50 percent or more of the total software cycle and often lead to major quality problems caused by ineffective debugging.

When you attempt to replace a large software portfolio piece by piece, you need to spend a considerable amount of effort first to build the "bridges" that link new and old environments, and then to test the linkages. Many of the disappointments you have had with automated programming tools can be traced to this problem. If you use such tools to generate code, you may speed up coding, but then lose even more time than you saved in splicing the automated code into the old, hand-crafted variety and testing the results. Using good filter technology, however, reduces the amount of software that needs to be replaced and simplifies building bridges to the portion that does.

Moreover, because the changes you make in front-end systems are invisible to the back end, there is little need for integration testing. I know this sounds risky, but I was in a bank the other day that had just made a policy decision to cut out integration testing for most changes made in its front-end applications. Further, the testing you do have to do—in front of the filter—can be done quickly and easily since there is less software to test.

Prototyping

The "Build it, try it, fix it" approach to IT systems development—iterative prototyping—is far more efficient than massive systems specifications, followed by long build times. In fact, it is rarely possible to identify through formal specifications all the needed functionality of a new process in advance of actual trial. One well-known estimate is that at least 40 percent of the functionality of large systems gets added after the system goes live.

In truly innovative process redesign, the problems with the traditional life-cycle approach become so restrictive as to jeopardize the benefits of redesign. Breakthrough changes are almost always associated with a steep learning curve driven by iterative piloting, field testing, and modification. This kind of activity can be supported only by the rapid development environment associated with prototyping.

Using filters helps. In the past, the prototyping of new systems often got itself a bad name because the first versions built were only mock-ups, without any real data connection to the mainframe. Users liked what they saw, then swiftly became disenchanted as they realized that they had to wait for the whole of a traditional software development cycle to be completed before they could have a working system.

Because filter technology already gives you a direct link into the mainframe, you can build functioning prototyping in weeks, then work on improvements with users in a real operating environment before rolling them out in a phased sequence. I saw this approach working to perfection in a telephone-based service operation last month. Managers were so astonished by the effectiveness of the process, especially compared with normal IT delivery routines, that they immediately gave the team responsible the corporation’s annual quality award.

Re-architecture

Probably the single greatest contributor to present disenchantment with IT delivery has been the appalling waste of money on huge data and application "architecture" projects. Hundreds of millions of dollars have been spent on these massive undertakings on the strength of the usually unproven and certainly unquantified assumption that reorganizing a corporation’s database will lead to competitive advantage. All too often, their complexity has led to a graveyard of project failures, from which even lavish further expenditure offers little promise of escape.

Using front-end filters allows you to focus whatever architectural change is needed carefully and precisely against the central goals of the process redesign. If you do so, however, your advisers on IT architecture may howl that you are sacrificing some glorious future to support mundane, short-term initiatives or give vent to dark mutterings about the existence of time bombs in the existing architecture that will bring the whole business to a halt unless urgently defused.

There is no way to address such concerns in general terms. You have to tackle the individual business cases item by item at a level of detail that quantifies the specific potential benefit or risk posed by each. The results of such analyses can be astonishing. The need for "absolutely essential" investments in major re-architecture often vanishes as mysteriously as the snow in spring. And required back-end changes can frequently be made through a series of slow, deliberate enhancements to existing architecture, or even through the addition of a separate back-end system.

Packaged software

A major barrier to the effective use of packaged software is the detrimental effect that customer-specific tailoring can have on the economic advantages of sharing the development and maintenance of common solutions. I’ve mentioned before that companies can easily see nearly a twenty-fold increase in maintenance costs if they tailor their packages into a state where they can no longer be supported under a vendor’s standard maintenance agreement.²

Again, using filters gets you around many of these problems: tailoring is done only at the front end, leaving the core of the packaged software unchanged. One MNC, for example, is now considering using a standard package in each of its many country locations and tailoring it to local needs with front-end software. The advantage of such an approach is not just a major reduction in software development and maintenance costs, but also the ability to bring international best practice in process redesign to every country by using the front-end flexibility to cater for specific local needs.

Putting filters to work

In the companies that have used such filters effectively, small front-end development teams work in a way that dramatically improves their responsiveness to redesign efforts. The main difference in their approach is that they have a skill structure that matches their incremental prototyping strategy: more than 50 percent of their members are business analysts, not career technical people. (Technical support is provided by a few programmers who know where the data is stored and can write new code as needed, as well as specialists in the interface technology itself.) Back-end enhancement tends, by contrast, to need the expertise of teams overwhelmingly composed of highly professional technicians. Work on the front end does not.

This difference in skill requirements has two Monday-morning organizational implications:

Organize by process or line of business

One of the problems that has long confounded front-line managers is that mainframe systems—as well as their support groups—are not organized along the same divisions as the businesses they serve. Many are either product- or function-focused, while the businesses are organized in terms of, say, distinct distribution channels. When such mismatches exist, attempts to distribute IT support to operating units usually end in a continual, agonized conflict over resource allocation amid competing bids to change the same code. There are few more disheartening activities for those attempting to manage the linkage between IT and business needs than participating in the ritual designed to resolve these conflicts—the awful, unproductive slog known as "prioritizing the IT backlog."

With filters in place, however, managers can align each front-end team against a particular line of business or process. As a result, taking multiple cuts at the same data or applications produces no conflict. In addition, by making clear the links between development cost and business benefit and by having all front-end investments owned by line management, such realignment makes the pointless horror of backlog prioritization virtually disappear.

Rethinking the outsourcing decision

Up to now, one of the main barriers to outsourcing has been managers’ justifiable nervousness about handing over a key potential source of competitive advantage—business process redesign and its enabling IT systems—to outsiders. At the same time, proponents of outsourcing have pointed to the benefits of having deep technical skills delivered in from outside. Using filters gives you the best of both worlds: front-end teams built and owned in-house; deeper technical skills outsourced to suppliers that have the precise skills needed. For example, maintenance of an old mainframe system can be outsourced to a specialized, low-

cost maintenance vendor (like those now springing up in third world countries), while building or buying in a new back end can be given to an industry specialist. This would be a much happier situation than your current predicament of low skills coupled with high costs.

Assessing the risks

If front-end interface technology has such powerful benefits, why are the major vendors not investing heavily in it? Does it matter if they are not? The successful providers of these "filters" have proven technologies and long lists of satisfied clients of high international standing. Yet none of them is large, and all have built their approaches around niche products and markets.

Two years ago, when I visited the US government department that provided front-end support to the military’s ordnance systems in preparation for the huge logistics exercise that surrounded Desert Storm, I was surprised by the list of vendors to which they had submitted their "request for proposal." I had never heard of any of them before. The technical manager responsible for systems development was as puzzled about this as I was. He had started with the more familiar names, but found that they lacked the skills for—or any interest in—filter technologies.

Dealing with smaller and less capitalized vendors is, obviously, a source of risk that you need to manage around. Moving cautiously here means:

• insisting on proof from vendors of concept prototyping, especially in application areas where there is no documented vendor experience; and
• not getting sidetracked by those who want to make experimentation with new technologies an explicit part of their implementation plans. IT experts often have their own technical agendas and look for any opportunity to gain experience with client-server computing, cooperative processing software development tools, graphical user interfaces, multi-media displays, and the like. Their desire is perfectly understandable, but giving in to it may load redesign efforts with unjustifiable levels of cost and technical risk.

The goal is to look for a "70 percent solution"—one that delivers the maximum functionality you need to enable process redesign with mature technologies that can be implemented in one year or less. Technology that promises an ideal solution years in the future will almost certainly be wrong-footed by new business or technical developments, creating yet another of the white elephants that have given the IT industry such a patchy reputation among senior managers. I am not being alarmist. At least one company has invested nearly $100 million over five years in building its own filter, when it could have bought in an existing solution for a fraction of the cost and in a fraction of the time.

At bottom, you are seeking business benefits, not technical solutions for their own sake. Moreover, if, in doing so, you learn how to use these front-end filters well and how to manage them effectively, you may also discover that the base levels of IT spending you have always assumed to be fixed do not really have to be. It may be, for example, that you do not have to maintain large numbers of software development people in-house but can instead rely on flexible, front-end teams, staffed largely by business-knowledgeable analysts and process redesigners, who rotate back to the line when not needed for such tasks. Even better, you can experiment with this new approach without facing the major investments or risks that have dogged previous attempts to improve mainframe architectures.

What do you have to lose by trying?

Regards,
Richard Heygate