The IT community is slowly coming to terms with the fact that no company, big or small, will ever be able to build a fully homogeneous and coherent IT infrastructure. IT people will always be developing new platforms, packages, and tools, and companies will always be seeking new business opportunities. Together, they will ensure that the perfect IT solution remains an ever-moving target. Even the company that scraps its messy systems and invests in a sleek replacement has no guarantee that the result will be compatible with the systems operated by a company it might acquire some time in the future.

Companies must therefore turn their minds to how their present systems can adapt to the technological developments and new business challenges that lie ahead. Several "front-end" approaches exist that involve bolting a new system on to old ones to create a user interface that integrates the data and functionalities of multiple existing systems. Such approaches are likely to deliver business value much faster than those that entail replacing or completely redesigning established systems, and industry experts increasingly see them as the way forward. However, some front-end approaches are better than others.

The difference lies in the way in which the old and new systems are glued together. Some methods are simply a temporary patch on an incomplete system; others, a permanent enhancement that will enable a business to stay ahead of the competition. Technical experts and CEOs alike need to be aware of the options.

The "file copy" approach

The simplest way to connect old and new is to copy files of data from the various legacy systems to each new system that the business requires. Suppose a company has set up a call center to deal with customers who fail to pay their bills. To allow operators to chase missing payments, it copies files containing default invoices, product data, and customers’ addresses and phone numbers from the relevant legacy systems to the call center system.

The drawback of this "file copy" approach is that it can act only as a temporary solution for a dynamic company. As the demand for data files from different user groups grows, the system architecture will start to look like spaghetti. Not just the call center but the audit department will want data files; so will production planning and marketing. If this improvised, case-by-case integration continues, life will become miserable for the IT department and frustrating for the rest of the business, as everything is glued to everything else in a typically undocumented fashion. Needless to say, the cost of change will rise constantly.

The "data warehouse" approach

To avoid undue fragmentation, the IT community has begun to introduce data warehouses. As in the file copy approach, these provide buffered connectivity between old and new systems, but this time at corporate level to deal with data demands from all a company’s various users. With such a warehouse, a user can collate read-only data from any system, be it marketing, production planning, or auditing. And when the IT department wants to replace one of the systems, it must simply ensure that the new one delivers the same data to the warehouse; other applications will not be affected. The data warehouse thus acts as an overall layer of insulation between different systems.

The problem with the data warehouse is that it is a read-only resource, adequate for decision-making purposes but of no value in operations that call for functionality and intelligence in both "read" and "write" modes. For such uses, a "real-time" glue is required to allow new applications to communicate directly with existing systems.

The "direct online" approach

Many tools exist for this purpose, including message exchange, direct database query techniques, and screen scrapers (a software robot controlled by the new application that "types" on the terminal interface of the existing system and "reads" the answer from the reply screens). Although many IT experts dismiss this last type of connectivity, the use of screen scrapers to link new PC applications with old mainframe systems is common. A number of banks, for instance, have installed screen scrapers in tellers’ PCs to give them online access to information from multiple systems.

Unfortunately, however, these kinds of screen scrapers cannot necessarily be reused in other operational areas. Say a bank wants to introduce home banking. This new business will need access to the same transaction systems, yet the screen scrapers may not run on its hardware platform, and security constraints may prohibit direct access to existing systems. The bank may then be forced to find another means of connecting up its home banking system—and, as channels and products proliferate, it may run into the same mess that the file copy approach produces.

The "hub-and-spoke" approach

The limitations of all these approaches have prompted the emergence of a concept that provides real-time connectivity while at the same time acting as a corporate insulation layer between applications. Compared with data warehouses, this is a concept still in its infancy—but one that industry observers such as the Gartner Group and The Yankee Group believe will become the connecting method of choice in the next two to five years.

Drawing an analogy with the airline industry, we have dubbed this new concept the "hub-and-spoke" approach to reflect the way in which new and old applications are hooked up to a central message hub.¹ The software at the hub can receive requests from a new application, connect with existing systems to access information, perform the necessary transactions, and feed data back to the original application. In doing so, it will use whatever tool is best suited to the job, be it a message, database query, or screen scraper. Unlike the bank teller’s screen scraper, these are now in a central location where they can be used by any application. New systems can be plugged into the hub and old ones upgraded or replaced with a package when necessary, allowing expansion to proceed in an orderly fashion.

To act as a seamless link between systems, the hub’s software must be able to handle large volumes of transactions at high speed. It must also incorporate a sophisticated security system that allows users from inside and outside the corporation to access the network, and a variety of interfacing techniques for communicating with all the legacy systems. There are already several products on the market that satisfy these demands.

Capturing the benefits

Since current and foreseeable technology will not allow operational transactions and cross-table analyses to be conducted concurrently on the same database, data warehouses will remain an essential tool for decision analysis purposes such as marketing. For the moment, combining a hub-and-spoke design with a pragmatic data warehouse seems to be the best method for connecting old systems with new.

To reap the full benefits of a hub-and-spoke approach, businesses will need to set up a connectivity team within their IT department to look after the hub and prevent the messy working practices that are rife in companies pursuing case-by-case integration. In these companies, every team that develops a new system has to liaise with all the teams that built the existing systems. In a bank, the call center development team would have to talk to the mortgage system team, the insurance system team, the savings system team, and so on.

With a hub-and-spoke approach, all development teams start by talking with the connectivity team, whose job it is to ensure that new systems get the links they need. In addition, the connectivity team must make sure that development teams in charge of replacing legacy systems must still support all the other systems through the hub. In effect, the connectivity team acts as mediator, allowing the "young Turks" who build elegant new applications with advanced software tools to work happily alongside the "asset managers" who look after the old but proven systems.

Though conceptually simple, hub-and-spoke technology offers a pragmatic way out of the deadlock that many companies find themselves in. Though evolutionary, it is far more effective than the big-bang renovations or replacements advocated by some, recognizing as it does that IT support is a matter of accommodating heterogeneous systems. There never will be a monolithic architecture.

Hub-and-spoke technology represents a long-term solution to companies’ IT needs. It is likely to have an enormous impact on business conduct, determining how flexible companies can be in reacting to new business challenges. CEOs would be wise not to pigeonhole connectivity as a purely technical issue. It could prove strategically crucial.