Information Technology Architecture

David A. McAfee

Senior Technical Consultant

(916) 653-4240

New modes of computing are arriving faster than ever, driven by powerful new technologies. The old styles of computing seem to live on forever within organizations, leaving what is not so much an architecture as an archaeology of the history of computing.

The Information Technology (IT) manager is responsible for delivering more connections to more locations and users than ever before - and with the Web, many of those users are outside our control and security. Throw in the resulting time-to-production pressures, and there are serious challenges indeed. The Department needs to find a way to simplify the situation and to enable the department IT organizations to focus time and resources on the unique requirements of their own business.

Enterprise customers indicate they need an easy-to-read signpost, a framework to help them locate where they are and to chart where they want to be.

The framework must take into account the Department's current environment and help to guide the journey forward, noting what can be done with today's products and services while also helping to plan for the future. It should assist managers in identifying near-term and longer-term plans, based on pre-defined strategies. It must point to technologies that show real and significant potential.

Customers want to see the "big picture" that helps them to set priorities as well as see the impact of day-to-day decisions.

The Department has invested in an infrastructure of application systems and technological solutions to provide required services to the citizens of California. By careful selection of opportunities, the department has been able to coordinate the work of many Branches. The effectiveness of the IT infrastructure needs to continue over the next ten years, during a decade expected to challenge all organizations with rapid change.

There is a wealth of earlier work that is available to learn from. Some of these frameworks have looked at specific issues such as the Internet model, while others such as the Enterprise Network Strategic Plan (ENSP) a much broader scope.

To ensure continuity in decisions at all levels, The department has chosen to create a tool, the Information Technology Architecture (ITA).

The ITA tool includes the various styles of computing that a large enterprise can employ, including host systems (data-centric), PCs (desktop-centric), client-server systems (service-centric), the Internet/Intranet model (network-centric), and the rapidly arriving distributed objects model (component-centric).

The aim of the ITA to help the Department see and understand the comprehensive picture of computing in the enterprise in a view that continues over time from the past, through the present and into the future.

The ITA is a set of information technology principles, standards, guidelines, and statements of direction intended to facilitate and promote the design and purchase of interoperable systems. Appropriate architecture leads to savings in delivery time, price, training, support, and maintenance. The scope of the ITA is broad, extending from desktop computing software and hardware down through middleware, operating systems, and network protocols to voice, data and video hardware.

The notion of an ITA is relatively new, and the potential scope of an ITA is very large. The ITA should be documented on a internal WEB site The diagram in the attached document illustrates the structure of the WEB site. It also displays the fact that the ITA product (publications etc.) is created and maintained by a supporting process.

Strategic Components are projects and activities with a three to five year time horizon that will substantially move the department in the direction of the strategies.

Projects arising from the Strategic Components will be subject to the same resource and budget pressures as other work in the department. From the Information Technology Branch perspective, this means that projects must be prioritized with the regular work objectives and other ideas proposed by staff. Since resources are finite, those activities will be cut which deliver the lowest value, whether they are currently done or only proposed. It is the intention of the Department to pursue corporate strategies, with the active support of all Branches.

The Logistical Components provided for each strategy are an additional resource, suggesting small projects or activities that could be undertaken for little cost and could be completed within six to nine months of their start. Work on these could create immediate momentum for change while the necessary planning is done to make the main Strategic Components viable.

Supporting the Strategic and Logistical Components are Key Player matrices. They suggest who should be involved in implementing the supporting components. The matrices analyze the various roles staff and management will need to play, such as sponsor, support, pilots, training, etc. The identification is by position, showing the inter-organizational nature of the strategies. These matrices should be used by project staff to involve all interested parties in the design and critique of solutions.

Frameworks are analytical devices for integrating the corporate strategies and components. Although the strategies can each be considered separately for implementation projects, they have a close relationship with each other. The Frameworks describe some of these relationships. For example, many components and strategies will mention networks, only a single, integrated network is intended, not multiple networks. Similarly, although education and training will be required to support each strategy and/or component, an integrated, multi-disciplinary education plan is more desirable than fragmented plans.

As important as is the role of the Information Technology Branch, even more important are the roles of all the Branches and the Department as a whole. IT is a component in carrying out the business purposes of the Department. A good infrastructure is almost irrelevant if departments are not able or unwilling to take advantage of the opportunities offered by the technology. On the other hand, concentrating our resources will have little effect if too many parts of the organization cannot or will not cooperate in coordinated work.

These factors, plus political and market forces, make the ITA a living document. Reality will be the biggest influence on the future of the Architecture. To the extent that we can shape reality and improve the performance of the Department as a whole, we will. The Architecture will not become more important than real life forces.

Within the Information Technology Branch (ITB), the Architects are responsible for leading and coordinating a department-wide activity to create, promote, and maintain the ITA.

The biggest threat to this Architecture is that parts of it disappear from lack of action and priority. To help prevent unplanned inaction, each major component will be coordinated by a Architect . The Architect 's responsibility is to facilitate initial project definition, coordinate across strategies if necessary, and alert ITB management if parts of the strategy are not being addressed. The Architect is not responsible for ensuring that the department implement the strategy, since this is a responsibility of all Branches.

ITA is NOT a system design. Not for systems in general or any particular system. (It is a building code, not a building plan.)

ITA is NOT a Vision for Department computing. Perhaps some White Papers will address vision, but the core components are like nuts and bolts - useful in the construction of the vision.

ITA is NOT a plan for layout of administrative data - what sorts of information are provided by what IT units, who owns the data, how to find it, etc. The ITA has to do with some underlying mechanisms, such as transport and access protocols and perhaps end-user agents. (We will, however, try to collect appropriate references where available.)

For the most part, the ITA is advisory. It informs choice in a heterogeneous environment and should result in better interoperability and/or lower development and support costs when followed. There are no "ITA Police" to prevent the buying some particular thing or interfere with research or experimentation.

February 20, 1997

Click Here!