David A. McAfee

Senior Technical Consultant

(916) 653-4240

What is an IT Architecture?

The IT Architecture is an organized set of consensus decisions on policies & principles, services & common solutions, standards & guidelines as well as specific vendor products used by IT providers both inside and outside the Information Technology Branch (ITB).

One of the major activities associated with producing an IT Architecture will be the process of achieving such consensus decisions. It is understood that reaching consensus may constrain purchase and design options, hopefully in the interest of enhancing interoperability. It is a given that the greater the consensus achieved, the greater the organizational benefits attained.

What are the IT Architecture Objectives

The IT Architecture is guided by the following objectives, which help make decisions for establishing individual standards:

1. Architectural decisions should serve the Department's mission.
2. The architecture serves heterogeneous environments.
3. The greater the consensus achieved for individual architectural decisions, the greater the benefit.
4. The architecture should identify areas of stability without impeding essential innovation.
5. Architectural decisions should describe the tangible results of conformance and non-conformance with the architecture.
6. Architectural decisions should provide sufficient documentation to assess the compliance of a specific implementation.

What is the purpose of the IT Architecture?

The purpose of the IT Architecture is to guide the process of planning, acquiring, building, modifying, interfacing and deploying IT resources throughout the Department.

As such the IT Architecture should offer a means of stable evolution by identifying technologies that work together to satisfy the needs of the Department users.

What are some of the key benefits of an IT Architecture?

1. It will help to insure interoperability inside and outside ITB and the Department.
2. It's a way to inform developers of Department directions.
3. It will help in making planning, development and purchase decisions.
4. It will be useful in aligning information technology providers for the Department.
5. It is a way to communicate direction (and changes) both inside and outside ITB.
6. It will reduce the maintenance and support requirements.
7. It will help in planning migration to new technologies.

What sort of framework is necessary for the IT Architecture?

A comprehensive view of an IT Architecture specifies (1) policies and (2) principles that indicate direction, and (3) services and common solutions, (4) standards and guidelines, and (5) products that detail the means of implementation (see Figure 1).

The framework for the IT Architecture is that of a cube sliced into five sections or layers from back to front. Each section or layer represents a type of architectural specification from the most general IT policy layer at the back of the cube to the most specific product layer at the front of the cube.

Figure 1 Framework

There are relationships between the various layers. For example, many if not all of the services that institutions provide are guided by the man made policies of the institutions in which the services are provided. An institution like the Department will have documented a number of these policies with information technology implications. Those policies are best implemented if some very basic information technology principles are adhered to. Continuing along the specification spectrum, one of the best ways to insure that IT principles are adhered to, is to reach consensus on a set of standards and guidelines so that the products we buy or build will be architecturally consistent.

IT Architecture Repository

A single repository of information regarding the IT Architecture is necessary, so that widely dispersed users of the architecture will have a single place to go for information. This repository must reside on the Department's Intranet. While the IT Architecture is sponsored by the IT Branch, the product is applicable to the entire organization and should be attached outside of Branch organizational lines.

A structure is needed to facilitate architecture development and maintenance. By creating a comprehensive framework of possible subjects, which will:

1. define the bounds on architecture (versus design)
2. make architectural decisions accessible
3. describe what has been done as well as what has not
4. focus the discussions of decision teams
5. find information when needed

In the framework each subject may/will be divided into many subsets or cells, all interrelated. Search tools and cross-references will be used to demonstrate these relationships.

At a given point, a subject subset or cell may be in any of several states:

1. Complete: a decision team has agreed and the decision is recorded
2. Empty: not yet filled, awaiting industry standards and products that comply
3. Review: under study so that a new standard can be decided
4. Obsolete: no longer a standard - has been superseded or rescinded

Each subject subset or cell contains a number of items of information, such as the following:

1. Name of the decision
2. Decision
3. Type of decision (standard, guideline, statement of direction)
4. Rationale for the given choice, alternatives rejected, assumptions, and risks
5. Time frame expected for relevance/applicability.
6. Pointer to documentation on compliance criteria
7. Preferred vendor(s), product(s), version(s)
8. Membership of the decision team
9. Technologists interested and/or expert in this area

To maximize stability and flexibility, a subject subset or cell should contain an open standard (rather than a proprietary standard or protocol) when a standard exists and when products with reasonable price/performance are available to support that standard. However, in some cases, a vendor or product may be the best way to describe a standard (for example, MS-DOS as a desktop operating system standard). In general, the architecture will describe interfaces between systems rather than the content of particular systems.

IT Architecture: A Note on Definition and Methodology

Figure 3 Methodology Model (below) shows some of the components necessary for integration into the complete IT Architecture.

Figure 3 Methodology Model

The IT Architecture is a blueprint for how future technology acquisitions and deployment will take place. It consists of standard, investment decisions, and product selections for hardware, software and communications. The IT Architecture is developed first and foremost based on department direction and business requirements. Additionally, principles are used rigorously to be sure the IT Architecture is consistent with the Department's information technology beliefs. The current (de facto) technical architecture is taken into consideration, as well as relevant industry and technology trends.

January 20, 1997

www.lanset.com/dmcafee

dmcafee@lanset.com