Every Manager's Guide to Information Technology:

Extract (2): Architecture

Extract's Table of Contents:

• The Processing Systems Architecture
• The IT Architecture
  • The Telecommunications Architecture
  • The Data Architecture
    
• An Effective Architecture
• Open Systems Interconnection (OSI) Architecture Model
• A Common Architecture Approach - The Desktop

One of the central concepts in the organizational evolution of IT, architecture refers to a technical blueprint for evolving a corporate infrastructure resource that can be shared by many users and services. The three main elements of an architecture are themselves often referred to individually as architectures. 

• The processing systems architecture defines the technical standards for the hardware, operating systems environment, and applications software needed to handle the full spectrum of a firm's information-processing requirements. Standards are formats, procedures, and interfaces that ensure the equipment and software from a range of vendors will work together. 

The IT architecture is the strategy, not the applications built within that architecture. The architecture determines the firm's practical range of technical options and thus increasingly its business options. Do you know your organization's architecture? Your customers'? Your competitors'? You should.

• The telecommunications (or network) architecture defines the linkages among a firm's communications facilities over which information moves within the organization and to and from other organizations. It, too, depends on standards.
  
  
• The data architecture, by far the most complex of the three architectures and the most difficult to implement, defines the organization of data for purposes of cross-referencing and retrieval, and the creation of an information resource that can be accessed by a wide range of business applications. 

Because British Airways had the same technical architecture as British Caledonian, British Airways could fully merge British Caledonian's systems, when it acquired the airline, over just a weekend. Conversely, Northwest and Republican took many years to rationalize and merge their disparate systems.

The three sub-architectures fit together to provide the corporate master architecture, the blueprint by which a firm's separate IT resources can be integrated. The alternative to developing an architecture is to choose the technology base best suited to a specific application, using such criteria as cost, efficiency, speed, and ease of use. This is a sensible strategy only if business applications need not fit together in order to share data or telecommunications resources. As soon as they do, an architecture becomes essential.

Given the enormous variety of services and equipment that must be integrated, the technical details involved in defining and implementing an architecture are extraordinarily complex. Most firm's information technology facilities cover a wide range of incompatible systems that have been built up over many years. Standards are a very recent development in the IT field, and most hardware, operating systems, and telecommunications services are still unique to single vendors. Many companies are choosing to wait until the needed standards are fully implemented before defining a blueprint for integration. They are ill-advised to do so. However difficult the task of rationalizing a multi-vendor mess and moving toward integration is today, it will be even more so tomorrow.

The need for an architecture is driven by widespread "incompatibility" among existing computer and telecommunications and data formats and by the lack of an accepted set of complete, proven, and stable IT standards. Many standards have been defined but few are fully implemented and their interpretation and implementation in products vary widely, effectively rendering them nonstandard standards.

An effective architecture must satisfy three, often conflicting, requirements: 

(1) that it provide as much vendor-independence as practical (firms are increasingly hesitant to adopt "proprietary" systems that only one vendor can provide); 

(2) that it be capable of rationalizing the frequent multi-vendor, multi-technology chaos of incompatible elements (a given company may have built its financial applications on IBM systems, its engineering applications on hardware and operating systems unique to Digital Equipment Corporation, Hewlett-Packard, Prime, or Sun, its office technology applications on Wang or Data General products, and its data-base management software, local area networks, and data communications facilities on a wide variety of vendors' facilities; 

it is not unusual for a firm to have from 10 to 40 incompatible networks and from 5 to 50 incompatible processing systems); and 

(3) that it incorporate the standards being adopted or likely to be adopted by leading vendors and electronic trading partners.

The need for a comprehensive set of vendor-independent standards is increasingly being recognized by vendor and user communities alike. What is needed is the equivalent of what has evolved in the electrical utilities industry: standardized interfaces such as the three-pin plug into the wall socket, standardized voltages, specifications for light bulb fittings, and so on. The Open Systems Interconnection model, or OSI, is the internationally accepted framework for evolving a complete and open set of such standards.

Although there has been a tendency to advance OSI as the long-term solution to integration, defining and implementing an architecture can take years, possibly even a decade.

The OSI model helped create many important open standards, but it did not achieve its enthusiasts' promise of a comprehensive and stable base for open systems in every area of IT. New technologies generate new needs for standards. Older technologies still in use are built on widely varying open and proprietary standards. Both of these must be taken into account in defining the IT architecture. For example, wireless data communications were nonexistent at the time OSI was first defined. The explosion of wireless technology has led to providers like Motorola developing a product outside the OSI model and then proposing it as an industry standard. Motorola's CDPD (Cellular Digital Packet Data) leapfrogged the OSI process by the very fact it was available in a working product, and not just a proposal. IS planners must be very selective in balancing the combination of standards that preserve existing investments with those that increase openness.

The technology moves far faster than the standards-setting process. Thus, for example, wireless local area networks appeared on the market in early 1990, but products based on an industry standard weren't widely available until 1995. The new core technologies of data communications, termed "fast packet-switching" (asynchronous transfer mode, SMDS, and frame relay), will require most companies to significantly redesign their architecture. That redesign can be phased in, and vendors increasingly recognize the importance of ensuring their products can be linked into the existing technology platform. Nonetheless, ensuring that the architecture neither blocks implementation of a high payoff business opportunity nor blocks adoption of a key technology is a constant challenge.

Conceptually, architectures and open standards are deceptively simple. Managers need to be aware that the tidy diagrams hide a morass of technical details, uncertainties, and, above all, existing incompatibilities. Nevertheless, developments in standards, particularly the convergence of IBM and many of its most effective competitors on compatibility with both key IBM architectures and key vendor-independent standards (notably OSI and UNIX), are easing the architect's task.

One common approach to defining and implementing an architecture is to standardize the "desktop." In other words, select a common set of tools for personal computers, including the operating system and "suite" of applications, such as Microsoft Office or Lotus's competing SmartSuite equivalent. (Suites bundle together word processing, spreadsheet, graphics, and electronic mail.) By doing this, architects can more easily exploit the many standards and devices that link PCs to telecommunications networks, remote transaction processing systems, and information resources. They can rely on a small set of standards that address most needs instead of trying to meet every need, although even meeting basic needs is hard. One trade publication described "The Network from Hell," a relatively simple exercise in integrating four desktop computer systems with a local area network and minicomputer. This task required forty-eight separate products. By contrast, the same article described how the Associated Press integrated 2,000 workstations with an almost identical minicomputer. AP's architecture-centered planning made this work like "an IS manager's dream" versus "the network from hell."

The firm without an IT architecture has no real IT strategy. The architecture is the strategy; it determines the practical range of applications the firm can develop, which in turn determines the practical range of business and product strategies the firm may choose among. Business planners and many business managers are also well advised to know their key customers' and competitors' architectures.

Order from:

Order from: