Technology Architecture Categorizing Principles

Paul Arveson
Feb. 28, 2001

These principles were developed and used to guide the consistent definition of technology architecture categories.

Principle 1. The scope of technology categories covers digital information technologies, tools, and standards.

The scope does not include processes or procedures or services or locations or techniques; these are not technologies. They are beyond the scope of technology architecture categories, although they may form part of the description of a particular implementation of technologies. Generally, the technologies include software, hardware, and network media.

The scope does not include ALL technologies. In particular, it excludes analog technologies such as POTS (plain old telephone service), public address systems, power supplies and the like. It also excludes most enclosure, cooling, packaging, construction, and other topics that do not directly involve digital information.

Principle 2. Technology categories should be defined based on end usage.

The end user has basically two relationships to information technologies: a) direct usage, in which a person works directly with a tool, such as a word processor; b) indirect usage, in which a person depends on a service but does not interact directly with it, such as the network. In the latter case, the person is using the network to communicate with other persons. The user doesn't have specific requirements; he or she simply needs the basic functionality of "communication" over the network.

The same kind of relationship exists with regard to the desktop computer. The person uses the computer hardware, cables, interfaces etc. indirectly, simply depending on them to perform some function that supports the user's work. That is why these subsidiary functions are sometimes called the platform: they support the user's work indirectly as a foundation, while the work itself is done directly with other tools.

What the user and the owner care most about is that the mission is performed; that users are able to get their job done. They don't care what technology is used, as long as it is reliable. (The corporate owner may care about additional things as cost, reuse, security etc. The network administrator may care about the bandwidth requirements of a device, etc. These factors will play a role in selecting of technology alternatives, but the universe from which to select them is defined based on the end-user function).

Another way of saying this is to consider whether the "end user" of a technology is a person or a machine. There are two kinds of information-sharing technologies: person-to-person and machine-to-machine. The person-to-person technologies are here called "communications"; the machine-to-machine technologies are relegated to servers and networks.

Therefore technology categories should be organized around their function relative to the end user. This maintains a consistent viewpoint of what the categories are. If we attempt to view technologies from other viewpoints, such as "the enterprise" or "security" then we will create an unstable mixture of categories. Also, we do not attempt to organize categories by location, technology or protocols used, etc. We want to be able to group similar functions together, and the underlying technologies that are implemented to meet the functional requirements, whatever they may be. The goal is to make a fair apples-to-apples comparison of solutions (services and/or products) for the end user. The need for making fair comparisons is one of the main reasons for developing these categories.

Principle 3. Technology products naturally separate according to whether they are general-purpose tools for enterprise-wide use, or special-purpose tools for a particular group of users.

General-purpose tools are usually COTS (Commercial off-the-shelf) acquisitions. They are purchased in large volume contracts, so there are strong economic reasons for standardizing these technologies.Special-purpose tools are often custom-made or developed in-house for unique applications. This distinction often implies that the technologies used in the two cases will be somewhat different.

There is usually an alignment between user groups and general/special purpose technologies used. This fact also supports the grouping of technologies by usage category.

Principle 4. Client/server based technologies should be grouped according to their primary function for the end user, not on where the components are located.

This grouping depends on how tightly coupled the client and server are to support a particular function for users. If the client and server products TOGETHER have a distinct function for users, then keep them together.

Example: Citrix Client/Citrix Metaframe server. Classify as a communication service. Remote Access is a communication technology, because its main function for the end user is to facilitate communication. It uses servers and clients, but they should not be separated and placed in either a client or server category, because that breaks the consistent user-oriented focus of the architecture. Separation of parts or locations is irrelevant to the solution this technology provides.

Another example: Microsoft Outlook email client/Exchange server: Classify as an email communication service. Email is classed as a general-purpose communication technology, because its main function for the end user is communication. The technologies and protocols used in email are appropriate for this function, so there is a match of technology to use.

Although it is less clear, the same is true of standards-based email systems based on SMTP servers and POP3 clients, or any other email system. These are email protocols: the client and server protocols are meant to be used together for one specific function.

If the client and server products are more general-purpose, then they could be separated. The 'function' of a general-purpose server is to transmit information; the 'function' of a general-purpose client is to request and receive information for the user. For example: web browser/web sites. Classify as a general-purpose web client and a web server. Example: data form/database server. Classify as a general-purpose client and a data server.

The number and kinds of specialized servers is growing. Since most of these are used with general-purpose clients such as a web browser, this is another indication that these servers should be categorized separately from the client.

Principle 5. Major technology categories should be sorted into a few non-overlapping layers or levels.

Each category or subcategory must be clear, distinct, and unique. All products within each category should be comparable; they should all have some overlap in technologies and standards. They should all be attempts to provide the same solution for the end user.(This principleis analogous to the concept of the OSInetwork layer model).

The general intent in developing thetechnology architecture categories is to try to get a consistent description aligned with the Zachman enterprise architecture framework, which is widely used within the government and is related to the Spewak methodology which is widely adopted for enterprise architecture planning.

Six top-level technology categories were defined:

  1. Authoring and editing tools
  2. Data management tools
  3. Communications services
  4. Client platforms
  5. Servers
  6. Networks

Principle 6. Security services and technologies are pervasive. Therefore each main category of technologies should contain a security subcategory.

In order to indicate the pervasive nature of security technologies, there should be a subcategory for them in every major category of the architecture. All security-related technologies appropriateto the subcategory can be placed there.

Security should not be considered a separate category and described independently. This practice discourages the awareness that security must be pervasive and consistently applied in order to be effective.

Principle 7. The granularity or degree of detail in the categories should be constrained to avoid an excessive number of categories.

This principle depends on the purpose of the category analysis. If the purpose is to create a comprehensive inventory of diverse systems, then a wide and deep array of categories may be necessary. For the definition of TA standards, a moderate level of perhaps 30 categories may be sufficient. Anything more detailed than this creates confusion in the usage of the whole description.

In order to keep the number of categories from becoming too granular, some degree of diversity in products within a category is acceptable; this becomes ultimately a matter of personal judgement. The main point is that each category or subcategory must be clear, distinct, and unique.

If time and funding permits, it may be valuable to develop some of the technology categories down to "excruciating levels of detail." However, this effort should be selective, based on issues and strategies requiring details in these categories.

Principle 8. The main categories and structure should be robust, while still permitting evolution as technology changes.This is done by means of a hierarchical category model.

Because of the amount of effort needed to develop the categories, we do not want to repeat this effort from scratch every year or less. The more stability, the easier it will be to maintain document configuration management.

On the other hand, we must recognize the fact of rapid change in IT, and so the architecture must be open-ended and able to embrace change.

The way to balance these requirements is to establish categories in a hierarchy. The TA major categories should be fairly stable, but subcategories may be added or deleted as new technologies are invented.

The main categories, the "trunk" of the tree, are networks, servers, and client platforms, with which people use special software tools to create or edit information, tools to store and manage the information, and tools with which to communicate. We do not expect these broad technology categories to disappear or be replaced in the forseeable future. On the other hand, the branches under these main categories could change significantly in the near future.

Principle 9. The technology architecture categories should be numbered and ordered.

This is simply a requirement for the proper maintenance of the categories in databases. Since technology changes with time, the numbering of categories (at least at the lowest level) is subject to revision on an annual basis.

Return to index