For many managers, the stories seem like wish fulfillment. Within nine months, a retail bank overcomes the limitations of thirty-year-old "legacy" IT systems to launch a high-tech operation that offers its customers a complete range of banking services over the telephone. Another bank is able to roll out, within three months of an acquisition, information systems that deliver the same level of service to all customers at all branches, new and old. An industrial goods company succeeds in building the IT support it needs for order processing in the course of a nine-month reengineering project.

For these companies, IT has genuinely become an enabler of change that boosts competitive performance. How they did it, as well as the lessons they learned along the way, can be copied by others. The secret: a "hub-and-spoke" approach to building the kind of information systems that lend themselves to rapid, continual improvement.

The airline analogy

At the simplest level, an IT hub-and-spoke-based approach is much like the strategies adopted by US airlines in the 1970s and 1980s after deregulation intensified domestic competition. At that time, most airline networks looked like spaghetti, with cities haphazardly connected as local market opportunities emerged. Airlines trying to expand or improve their services quickly found the complexity of their networks was becoming unmanageable. Changing a single service or adding even one flight to a pre-set schedule created such a domino effect on connecting flights that real optimization was impossible.

Airlines then discovered they could manage their networks much more effectively if passengers were routed through a central airport "hub," which offered fast connection times to flights along individual route "spokes" to other cities. As a result, airlines could offer a truly integrated network between as many city pairs as it had planes—a dramatic increase in customer service without heavy spending on additional planes. They could also add a new city to their network more easily. All they had to do was to establish a connection between it and the hub.

Today, many corporations face a similar kind of problem with their computer systems: a spaghetti-like mess of interconnections between legacy systems and applications, inherited from decades of IT invest-

ments and scattered across dozens of different computer technologies. In order to assemble the information required to support a single new business initiative, these corporations need to be able to integrate IT support across business processes, preferably using existing systems and without spending heavily on new development projects. They need to be able to add new applications from time to time and integrate them quickly with existing systems. And they need to be able to change systems step by step, without always being confronted by endless interdependencies.

Many projects are cancelled part way through, after huge time and cost overruns, leaving nothing to show for millions of dollars of investment

Current approaches to IT seldom meet these needs. Managers are trapped between unwelcome alternatives. Greenfield solutions—scrapping old systems and rebuilding from scratch—usually take too long and cost too much. Worse, a frightening number of projects are cancelled part way through, after huge time and cost overruns, leaving nothing to show for millions of dollars of investment. More focused attempts to upgrade existing systems piece by piece usually get bogged down in the infinite complexities of connecting old and new systems together. From this trap the IT analogue of the airlines’ hub-and-spoke approach offers a way out.

Hub-and-spoke setups can be accomplished by small teams of people in months, rather than years

The logic is simple. Start with a piece of "middleware" software, preferably one that is available off the shelf, to serve as the IT equivalent of an airline hub. Next, connect existing systems to this software hub without modifying them in any way. (This allows companies to move data to and from current applications that serve crucial business functions.) Finally, plug new capabilities into the hub or upgrade existing systems as needed. This gives new applications access to all the data and functionality of the existing systems. And that’s it. Thanks to the capabilities of the hub and the overall simplicity of the approach, each of these steps can be accomplished by small teams of people in months, rather than years.

Inventing hub-and-spoke for IT

To understand how IT hub-and-spoke works in practice, take a look at its origins in the competitive cauldron of direct marketing. The hub-and-spoke approach first emerged in the early 1980s, as companies set up "call centers" to create the new business processes needed to sell products and provide services over the telephone. In the course of a phone call lasting only a few minutes, these call centers had to have access to all of the information and capabilities needed to give customers whatever they wanted. The IT challenges in meeting this business imperative are immense. To see why, track the progress of a hypothetical call through the call center of a bank.

When the call arrives, the caller’s telephone number is automatically compared with a customer database. If it matches a known customer, all relevant information on that customer immediately comes up on the screen of the sales agent who takes the call. When the customer makes a request—say, for approval of a new loan—the system prompts the agent to gather all relevant information. The loan application is automatically sent to a loan approval system to see if it can be approved on the spot.

At the same time, a marketing database mulls over the customer’s recent pattern of purchases and requests. As a result, it may prompt the agent to offer the customer a product that it reckons he or she may want to buy. Any new transactions are then recorded in product processing systems, and the relevant paperwork is automatically printed and mailed. Finally, a workflow system reminds the appropriate people in the bank to ensure that any necessary follow-up work is executed properly and on time.

Software tools enable businesses to create their own call centers within three to nine months, even when their existing systems are messy

Rightly sensing that building call centers could become a booming market in several industries, a number of innovative companies began developing software tools and products that would enable businesses to create their own call centers within three to nine months, even when their existing systems were messy. To be successful, this software had to improve continually on six measures of performance:

1.Quick and efficient connection with any and all other programs, new or old. Call center providers understood that they could not expect a company to change or replace its legacy systems in order to deliver a new phone-based service. They therefore invented a variety of technological tricks to enable legacy systems to work together, connected by a "software hub," even if all that was known about them were the instructions that went in at the keyboard and the responses that came back on the screen.

With a technique called screen scraping, for example, the legacy appli-cation sends data to the hub as if it were sending it to a terminal screen. The hub then "reads" this virtual screen and sends data back to the legacy application by "typing" it on a virtual keyboard. Of course, the spoke between hub and legacy application does not actually have a physical screen or keyboard, but the legacy application works perfectly as long as it "thinks" they are there.

2.Fast response times. Customers usually expect quicker, more definite responses when they do business over the phone than when meeting face to face. A five-minute telephone call can easily involve a few dozen unrelated applications and databases spread right across a company. To keep the information moving quickly, call-center hubs must be able to manage the simultaneous execution of different tasks on the different systems connected via its spokes.

3.Access to new applications. Given the fleeting nature of their contact with customers, call-center operators are eager for applications that make them smarter about their customers’ needs. This means integrating new applications, such as expert systems, using interfacing techniques available on the market like message-based communication with modern object-oriented applications.

An effective hub hides from its users the technical differences between systems so that they see only a single coherent user interface

4.Seamless integration. Working under intense time pressure, call-center employees require seamless access to everything that their systems can provide. They have neither the time nor the inclination to learn different techniques for accessing each of the systems they use. An effective hub hides from its users the technical differences between systems so that they see only a single coherent user interface. It also protects them from the problem of keeping track of which data are located where. If legacy systems do not contain a central customer database, for example, the software hub might be extended with a new database that remembers that customer A in legacy system X is really the same as customer B in legacy system Y.

5.Seamless guidance. Call-center employees also need a system to help them manage the overall complexity of their work. Thus, workflow tools on one of the system’s spokes will keep track of non-completed tasks, send messages to all involved to ensure that deadlines are met, follow jobs that are executed in batch systems, and collect productivity statistics.

6.Fast implementation and low cost. Their 10 to 15 years of experience have helped call-center providers to streamline their approach to setting up operations in three to nine months with small teams, no matter how complex the systems their clients possess. Competitive pressure between providers has ensured continuous improvement in implementation time and cost.

Once perfected, call-center technology quickly proved applicable across a whole range of businesses, not just in direct marketing

Once perfected, call-center technology—that is, the ability to link and integrate computer systems—quickly proved applicable across a whole range of businesses, not just in direct marketing. After all, any business process, whether front or back office, can use at least some of the information support provided in call centers. And in today’s information economy, is not any office really a call center? Vendors have thus started to offer software hubs as standalone middleware products, to which companies can attach a variety of legacy systems, databases, and user interfaces such as remote PC networks and the laptops of a travelling salesforce. One US bank has even moved to a hub-and-spoke system, with more than 10,000 user interfaces, internal and external, as its overall architectural choice.

Key attributes

The software hub manages the flow of data from one application to another, no matter how different the underlying computer systems

The software hub—the central component of the hub-and-spoke approach—brings together the capabilities needed to get data from one application to another, no matter how different the underlying computer systems. But the least possible processing and transformation of information is done within the hub. By pushing such work out to the spokes, the hub itself stays uncommitted to any particular task—and thus remains relatively "future proof" even in the face of significant business and technological change.

A hub must know where to get the relevant information, how to get it quickly, and how to put it into the expected form

The essence of hub-and-spoke can best be understood by looking at the tasks that are executed when an application fires a request to the hub and expects a reply back. To answer a query, the hub must know where to get the relevant information, how to get it quickly, and how to put it into the form expected by the application that asked the question in the first place. To do all this requires:

Knowledge about the location of information. For every type of request, the hub must contain some logic that acts as a master script specifying which applications on which spokes have relevant information and so must be consulted to formulate an answer.

Knowledge about the fastest method of access to information. The master script must also know which information has to be requested in sequence from different systems and which tasks can be executed in parallel. For example, some queries might entail translating a name and address into a customer number before further information about the customer can be gathered from other systems. If the customer does not have a number, the query stops there. But if he or she does, then requests can be fired off simultaneously to the necessary systems.

The ability to communicate with applications. To gain access to information, the hub contains a software module for each spoke that enables it to talk to the application on that spoke. If this application can understand any of the IT industry’s emerging message standards, this software can be simple. But if the hub must do "screen scraping"—that is, if it has to be able to mimic the activity of a human user, first logging on to a legacy system, and then navigating through various menu screens and other procedures to get the data it wants—the software will have to be more complex.

The ability to synthesize an answer. Finally, the hub’s master script must pick the relevant pieces of data from the material it receives and then combine them into a single reply message to the requesting application. It must also be ready to pass on error messages or incomplete answers, in case one of the applications was not able to reply or was simply out of order. And it must also complete bookkeeping tasks, provide security, gather performance statistics, and the like.

The hub manages only the dependencies between data sets; workflow software manages dependencies within business processes

These capabilities distinguish the software hub of a hub-and-spoke system from the sort of thing that techies sometimes refer to as a "network hub." The former knows about data—where it is located and how to get it. The latter knows only about communicating bits and bytes; it leaves the user to deal with the complexity of managing data. Note, further, that workflow software for managing business tasks is strictly an add-on to a hub-and-spoke system. The hub manages only the dependencies between data sets; workflow software manages dependencies within business processes, such as to-do lists, deadlines, and authorization procedures. Thus, to keep a hub lean, quick, and efficient, it makes sense to add workflow software only on a spoke.

Software hubs have been constructed for all kinds of computers—PCs, Unix servers, and mainframes. Different hubs will handle different volumes of work, offer different features, and provide different approx-

Management attention can finally shift away from technical arcana to the intelligent design and implementation of new business processes

imations of the promise of universal connectivity. Not surprisingly, hubs have been built to cater primarily for the most widespread technological standards. Although the list of technologies supported by commercially available hub-and-spoke products is already impressive, no software hub can provide instant connectivity to all computer platforms. Obviously, managers contemplating buying a software hub will need to check that it caters for the specific technologies they need. Given the capabilities of currently-available hubs, however, management attention can finally shift away from the technical arcana of network protocols and data structures to the intelligent design and implementation of new business processes.

Putting hub-and-spoke to work

As leading-edge companies have found, moving to hub-and-spoke usually requires four steps:

1. Assess current setup to define the required information support

Forging working combinations of human and machine decision making that temper human creativity with computer reliability remains one of the most challenging tasks facing today’s managers. A hub-and-spoke approach cannot make a science of this art.¹ But it can simplify the art in two ways.

First, hub-and-spoke technology, when used effectively, can support a wide range of strategies and decision-making styles—that is, it helps reconcile the apparent conflict between a company’s desire to maintain its own unique way of doing things and the pressure to save money by buying standardized computer systems off the shelf.

In personal insurance, for example, a hub-and-spoke approach has been successfully adopted by firms with radically different decision-

making styles. At some companies, it provides raw information to the desks of highly educated salespeople, who decide precisely how to tailor products for individual customers. At others, it enables a workflow system to prompt a salesperson step by step through a dialogue with a customer. It then feeds the customer’s answers to a statistical marketing database, which determines which standardized products are best suited to that customer.

Hub-and-spoke encourages IT systems to evolve—with relatively little pain

Second, and far more important, hub-and-spoke encourages IT systems to evolve—with relatively little pain. It does not require businesses to freeze their information requirements for years to allow IT departments to implement clearly-defined specifications. Nor does it place obstacles in the way of establishing connections with any piece of corporate data or any computer system. In fact, it encourages an exploratory process of design for new applications. And if something goes wrong, it also makes it easy to fall back on the old system. The conventional approach of modifying the old system often takes away this safety net.

2. Access legacy systems via hub-and-spoke

The hub-and-spoke method enables companies to treat legacy systems as assets rather than liabilities. By contrast, traditional approaches to systems development usually call for disposing of the old systems as the first step in building the new. Often, the main reason for doing this is the difficulty of getting information to pass smoothly between the two. By allowing legacy systems to communicate with new ones, hub-and-spoke makes it possible for companies to build on past IT systems, rather than perennially striving to recreate them at ever higher levels of complexity.

Building on past success has obvious advantages. One, certainly, is that it makes it possible for companies to avoid the need to devote time and money to rebuilding capabilities that a company has already developed. Another is the help it gives to managers who find it difficult to think about information needs in terms of the abstract data and process models used by IT specialists. Hub-and-spoke allows them to express their needs for information in familiar, business-relevant terms: how information should be integrated, what sequence transactions should follow, and what new functionalities should be added.

3. Hook up breakthrough capabilities on new spokes

Firms are no longer forced to recreate new applications in-house in order to get them to work with existing systems

The most visible payoff of hub-and-spoke comes from the speed with which new capabilities can be added to existing systems to create entirely new business processes. The broad connectivity that it provides allows firms to take advantage of innovations made by commercial software companies, instead of being forced to recreate new applications in-house in order to get them to work with existing systems. Consider, for example, such innovations as:

Event-driven marketing. A pioneer in direct telephone banking boosted its cross-selling when it connected to its hub a new marketing package to help anticipate customer needs. The system enables the bank to define a list of significant "events," like a recurring overdraft or a lost credit card. Each event is linked to a product that the customer might want—an approved loan, for example, or a credit card insurance scheme. When an event occurs, the system checks to see if the customer is a possible candidate for the product. If so, it prompts the salesperson through an appropriate sales dialogue. By offering new products when they are most likely to be wanted, this approach improves sales effectiveness. Better still, by tracking the success or failure of each sales pitch, it keeps the firm abreast of changes in the demand for its products.

Trying out new prices and product terms. A successful direct car insurer uses a similar system, also purchased from a commercial supplier, to try out new prices, terms, and conditions on its prospects. Most are offered car insurance in line with the existing pricing strategy. But a few are chosen randomly by the system to be offered the same insurance but with slightly different prices or terms. By comparing these sales experiments, the company discovers how price-sensitive its prospects are, and can adjust its prices accordingly. This not only enables it continually to improve its product offerings; it also informs its planning concerning how to respond to competitive threats.

Electronic data interchange (EDI). The vision of paperless buying and selling is appealing, but its realization has not come as fast as many had hoped. The challenge for EDI is related to legacy systems: when a customer wants to order a product electronically, a number of existing systems must be consulted, such as creditworthiness, available inventory, and transportation. For one major computer manufacturer, this means forging links with 13 separate product processing systems. A hub-and-spoke package makes EDI’s access to these systems feasible.

4. Upgrade/replace legacy systems as and when needed

The flipside of the coin is the ease with which hub-and-spoke technology enables companies to replace their legacy systems when they are ready to do so. Because it can deal with both old and new systems, decisions on when to upgrade old systems can be taken simply on the merits of the technology—and not on the need to extract data from the grip of a legacy system. Indeed, one of the major advantages of hub-and-spoke is that it allows old systems to be upgraded with little impact on users. So long as the user interface can still send queries to the hub and receive appropriate replies, the user need not know—or care—whether the application dealing with the messages is old or new. As a consequence, the IT department can manage its applications portfolio without constantly retraining or otherwise disturbing users.

It may be worth noting that hub-and-spoke as described above is different from client-server. Client-server computing strives toward many of the same goals as hub-and-spoke. It divides work between various machines. (Most often the "client" provides a friendly user interface and personal applications on the desktop; the "server" manages data and corporate applications.) It stresses clean interfaces so that server or client applications can be taken out and new ones plugged in with a minimum of effort and disruption. It enables rapid development and change.² But it often overlooks the easy, near-universal connectivity stressed by hub-and-spoke toward both old and new systems.

Few client-server technologies make it a simple matter to connect with legacy systems. As a result, many companies pass up the benefits of client-server because their analyses tell them that it would be prohibitively expensive to connect, say, their proposed new client-server marketing information system with the marketing data on their old mainframe. Worse, some client applications communicate poorly with any servers that do not come from the same provider.

In an ideal world, where there were no legacy systems and any client was able to talk with any server, hub-and-spoke would be unnecessary. In practice, however, hub-and-spoke technology fills the gap. It supplies the missing piece that easily and inexpensively links clients with servers, legacy systems with new technologies, and, most important, the vast capabilities of information technology with the urgent need for redesigned business processes.