Paul Arveson
The purpose of the technology architecture is to define the major kinds or categories of technologies needed to provide an environment for the applications that are managing data. Spewak refers to these kinds of technologies as platforms that will support the business with a shared data environment. Basically, it is a "list of stuff" that encompasses all the technologies used or being considered in an enterprise.
We are required to produce a Technology Architecture Report that contains a list of the kinds of technologies in current and proposed future use in SC. This report will be used a) to guide developers and designers in their selection of technologies that are approved for use; b) to guide planners in evaluating products; c) to guide planners in predicting changes in technologies for future updates of the report.
Spewak's book provides three examples of Technology Architecture Report outlines, to indicate what should be contained in such a report. Generally, they need to contain a list of all technologies in an organized outline or schema, grouped in some orderly way that allows similar alternatives to be compared.
In updating our Technology Architecture Report and its Technology Positioning Statements (TPS), I made an attempt to identify a TA schema that is authoritative, appropriate to our needs, not arbitrary but standards-based, stable against major change, but open to future innovation. The TA should provide a set of categories that are general enough to be stable, but specific enough to identify commercial products in each category.
It should be noted that there are some potential ambiguities in word usage. Spewak's use of 'platform' is not really in widespread use now.& More importantly, what we (after Spewak) have been calling a Technology Architecture (TA) may now more often be referred to as a technology infrastructure. However, I will adhere to Spewak's usage of TA below.
Here are some sources of TA definitions (lists of kinds of technologies) that were examined, with hyperlinks to their respective web sites:
This is only a preliminary assessment based on a brief examination of the architectures. As Giga's Gene Leganza advises, we should not devote excessive time to deciding on an architecture -- just take one and go with it. However, because of the long term importance of this definition, we would be remiss not to look at some sources of architectures that are readily available. We should not be unaware of them in case someone asks about this.
The categories of technologies listed in our existing TA documents are called "Business Systems Architecture Categories". They include the following:
A reference is not given for the source of this list, although it is similar to those of other government agencies. The following remarks were given about these categories in a SPA document:
Categories of projects. The proposed projects can be categorized according to the types of computing services that they affect. Although 10 technology categories are recognized in the annual SC Technology Architecture Report, the projects below can be grouped more simply into four technology areas: Desktop, Database, Network and OS, and Security. Of course, these areas are not independent of one another, and several projects are certain to offer benefits to more than one area of technology.
The following issues relate to this list of categories:
1. It mixes viewpoints from different levels of the Zachman framework. This can create some confusion in identifying where a product should be placed in the list. For example, what is email? Is it an end-user tool, an Infrastructure Service, or an Enterprise Service, or something else?
2. It does not entail a "picture" or map of our technology architecture. It would be helpful to have such a picture, because this would give users more guidance as to how the TA is structured, and what the relationships are between the categories.
3. It does not derive from other government or widely-used commercial TA categories.
It is difficult to define the TA categories in any case, since technologies are rapidly changing, and standards are diverse and complex. However, this paper will attempt to identify an appropriate map of TA and a list of categories. First, several existing TA's will be surveyed.
Government Technology Architecture Categories
DOE CIO guidance will have to take precedence over non-DOE governmental guidance here in SC. However, where there is no DOE CIO guidance, the other sources may provide it.
DOE's current architecture documents derive from those of NIST, although they are too general for a practical TA. The recent desktop software guidance from the DOE CIO is specific enough, identifying commercial products, but unfortunately on email, browser and operating systems it fails to identify a unique selection.
The DoD has recently revised its architecture definition from the TAFIM, (Technical Architecture for Information Management) to the Technical Reference Model (TRM), which incorporates interface definitions from the SAE Interface Model and the Generic Open Architecture (GOA).
The DoD's mission is different from that of DOE, with the goal of being 'to provide the right information at the right time to the warfighter'. This places a strong emphasis on mobility and device interoperability across languages, locations, etc. The TRM describes everything in terms of a 'service'. Its structure is generalized to the point where a practical service such as email is spread all over the architecture into many services.
The actual technology list is in the DII COE (Defense Information Infrastructure Common Operating Environment). The latest version of this is at http://coeeng.ncr.disa.mil/RELEASE_PAGES/s42NTBL.htm
The USDA documents offer a list of 15 technology domains:
Their environment is similar to DOE's, so this list will be considered for future use, although it seems somewhat arbitrary. Note that security technologies are distributed in several items; and its emphasis on GIS is related to its special focus on agriculture.
Treasury has an architecture document, the Treasury Enterprise Architecture Framework, at http://www.treasury.gov/teaf/ It was just published in July 2000. Since the Treasury CIO, Jim Flyzik, is also the Chairman of the Federal CIO Council, this document has a comprehensive and government-wide significance. In addition to defining an enterprise architecture, it also provides guidance to developing an architecture and compares Treasury's architecture to many of the other government approaches, including the preliminary design of the Federal Enterprise Architecture Framework (FEAF), which relates to the Zachman Framework.
Although it is an excellent resource on architectures, the Treasury document identifies a Technical Infrastructure (rather than architecture), which is too brief and broad to meet the current need for technology category definitions:
Hardware, Software, and telecommunications
GSA has a new web site, Architecture Plus, which offers government information architects to share information and meetings. Many of the federal architects are focused on Spewak and the Zachman framework, as we are. But these are of too high a level for the practical technology architecture definition.
Giga expert Gene Leganza suggested that the State of North Carolina has an excellent example of a technical architecture web site. It is rather comprehensive, but unfortunately it uses a different architectural concept that doesn't fit neatly into ours. It is based instead on META Group, Inc.'s Enterprise Architecture Strategies (EAS). Its Conceptual Architecture forms the foundation for an additional 12 "component architectures":
This list seems too far afield from the other federal architecture frameworks and technology infrastructure definitions. Also, it does not get into sufficient detail to identify particular products or protocols.
Commercial Technology Architecture Category Definitions
There is a standards web site at Microsoft that organizes 150 standards used in Microsoft products. What is of interest here is their organizing outline:
This appears to be a broad and fairly comprehensive list of standards categories. Under each heading, Microsoft has identified the formal standards that apply for many of its products.
Microsoft also identified a high-level, generic outline of four categories of interoperability: network, data, applications, and management (NDAM).
These two categories can be integrated and slightly rearranged to form a comprehensive technology architecture definition. This will be shown at the end of this paper.
A Standards-Based Technology Architecture?
Neither the Spewak nor the Zachman books say much about standards. Since technology is increasingly led by standards, it may be appropriate in the future to include this consideration in our definition of technology categories.
"The problem with standards is that there are so many to choose from." Often in the architecture literature one finds lists of "standards" in an enterprise that are nothing more than an inventory of multiple standards. (Even the DOE CIO's Sept. 2000 newsletter illustrated this).
The problem with using standards as the basis for a technology architecture is that real IT products are complex: they are based on a combination of standards and proprietary specifications. Thus the definition of product categories becomes problematic.
As an example, the Microsoft standards web page conveniently lists Microsoft products linked to 150 different standards. It is a useful source of information about potential interoperability issues, but the complexity of this list illustrates the difficulty of defining categories.
Other technology lists can be found in the literature of library science, and in general catalogs such as that found on Yahoo.com. Their list of software categories, for instance, is:
|
|
This list is very broad, but it clearly includes a lot of categories that are not desired in the SC office environment. It is too informal to be considered a robust, standards-based list.
This work has indicated that there is not a "standard" technology architecture definition that has been adopted or recommended either in the government or private industry. And actually this should not be surprising, since organizations are different, and 'one size does not fit all'. This implies that the TA definition needs to be devised within our own organization.
Another finding of this work is that there is not one list that can cover everything, because we inevitably run into the problem of multiple viewpoints. From the viewpoint of an engineer, standards are appropriate as a list because they are low-level descriptions of technologies, and they are well-defined. But from the viewpoint of an owner or designer, they are relatively meaningless. The don't indicate the actual, practical functions served by technologies. These two viewpoints are totally different, although it is true that the purpose of a product may depend on the implementation of many standards. The appropriate viewpoint depends entirely on the purpose of the list.
Therefore, in order to provide a clearly defined list of categories, it is necessary to focus consistently on one viewpoint.
Which viewpoint should we take? Clearly, for the purposes of this TA definition, it should be the system or product user's viewpoint. This is the main purpose for buying or building IT resources: to meet needs of end users. It makes sense to compare products based on their ability to meet these needs.
From the user's viewpoint, there are basically two kinds of information resources: tools that directly meet the user's needs, and other tools (which we can call 'utilities') that support the tools that meet the user's needs.
This leads to a technology architecture definition that is relatively clear and unambiguous, as well as comprehensive. On another page, the rationale for this definition will be described.