| Document Notes |
| This document was extracted from a world wide web document titled Overview of Information Technology Architecture (ITA) by Vance Vaugh from the University of California at Berkeley . The document was modified to better fit our organization. Some reformatting may have been done to better fit the Web site look and feel |
Creation of an information technology architecture (ITA) for the Department is a organization wide activity led by Information Technology Branch (ITB). Establishing the ITA is a key to the ITB mission:
Insert Branch mission here
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 inter-operable 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.
Within ITB, the Architects are responsible for leading and coordinating a organization-wide activity to create, promote, and maintain the ITA. The architect can be reached by EMail:
Work on our ITA began in earnest in 1995 and 1996 with Enterprise Network Strategic plan (ENSP) where ITB worked with various constituencies, formulating processes, etc. This white paper describes our thinking and progress to date.
The notion of an ITA is relatively new, very different things are referred to as ITA's, and the potential scope of an ITA is very large. Our ITA is documented on a WEB site insert web site address here. The diagram 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. The product and process are described in subsequent sections. One helpful hint: the ITA is analogous to a building code, not to a design for a building.
Insert web map here
The primary product is documentation, which can be described in four major categories:
Expositions covering various topics as the need arises. (This document is an example.) Contributions are welcome.
We intend that the ITA WEB site should provide a general reference
to any technology-related material. We are assembling:
It is the responsibility of ITB, via the Architects, to create, promote, and maintain the organizations ITA. However, the ITA cannot be the work (or pronouncements) of any one person or group. Creation of the ITA will involve some difficult analysis, trade-offs, and decisions in many areas. We will need to engage the "organization brain" to get the best result. Our ITA will only be successful to the extent that people are aware of it and find that it helps them.
The ITA is a large (perhaps unbounded?), complex, multi-dimensional undertaking. The Insert review group here determines how we apply our decidedly finite resources to this large task by prioritizing the issues. The INSERT CONTROL GROUP HERE process is roughly this:
The supporting process is being developed in the initial stages of the ITA :
There are many groups in the organization whose responsibilities and activities relate to the ITA work. A list of these groups and their roles is being assembled on the ITA WEB site. As custodian of most of the campus' core administrative data and applications, ITB has a special role in the architecture arena. Internal organizations within ITB are contributing documentation of current practices (the "invisible de-facto architecture") and highlighting ITA areas of particular concern and ones needing quick attention.
Our ITA is NOT a system design. Not for systems in general or any particular system. (It is a building code, not a building plan.)
Our ITA is NOT a Vision for organization computing. Perhaps some White Papers will address vision, but the core components are like nuts and bolts - useful in the construction of the vision.
Our ITA is NOT a plan for layout of administrative data - what sorts of information are provided by what campus 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 you from buying some particular thing or interfere with your research or experimentation. If you reach some decision which conflicts with the ITA, bring it to our attention - you may have overlooked something or we may need to update the ITA!