The Architecture portion of TAPES is based on three major components of a technique called Individuated Associative Matrix (IAM).

The first component is a high level data model of a basic organization's seven fundamental entities (object classes), which serves as a comprehensive management model for any endeavor.

The second is use of a numerical-attached-hierarchy code (i.e., a numerical outline code) to individuate each object of the data model, forming the catalog.

The third is a structured relational database technique which combines many of the features of relational, hierarchical, network, and object-oriented database technologies, to associate each individuated object of the organization into a dynamic cross-tabulated matrix (the cross-index).

The combination of the three is the repository. It displays both the composition and distribution of any object in the matrix. A matrix can be built for organizations or functions of any size and then merged to form a single repository for the newly integrated organizations or functions. It has immediate applicability to the DoD goal and objectives of Corporate Information Management (CIM).

The IAM technique has been compared with Very Large Scale Integration (VLSI) circuits in Electrical Engineering. Electrical Engineering transitioned through electronic switch, vacuum tube, transistor, microchip, and then VLSI circuits. The IAM technique provides a method of moving Information Engineering from small scale to very large scale integration of information in a single technological and conceptual step.

An early operational prototype of TAPES was built using a commercial 4GL (Fourth Generation Language) application design and code generation tools (dBase IV, Version 1.1).

NOTE: This specific 4GL source code can be converted to "C" code by several commercial conversion software programs. This "C" code could then be imported into the AT&T ETIP-C (extended terminal interface program - C) used in the Army ISM (installation service module) program. The xBase data and index structures could be converted to SQL structures. The xBase Memo fields could be converted to text files integrated with the SQL tables and the "C" software. Once the software is optimized using ETIP-C, it could be written to Ada source code by the AT&T ETIP-Ada software. In shorthand: 4GL(DB IV 1.1)-> C+SQL+Text-> Ada+SQL+Text = Common Software Units.

The early operational prototype software and data bases are being used to guide the current effort to complete a more capable operational prototype and the Functional Description to complywith Department of Defense documentation standard DOD STD 7935a. After completion of the Functional Description, TAPES is to be developed as a operational system using Open System Environment (OSE) components by a Department of the Army agency with the Director of Information System, Command, Control, Communication and Computers (DISC4) as subject area functional proponent.

TAPES took form over seven years, from 1984. To conceive, analyze, organize, prove, and document TAPES, we took the Army's goal of applying Information Engineering, Data Management, Life Cycle Management, System Documentation, NIST/OSI standards, and System Development concepts and methods to develop its Information Architecture.

We then integrated and incorporated all of the above concepts with our knowledge of Army Resource Management (Planning, Programming, Budgeting and Execution System - PPBES), Force Management, other Army functional areas, and academic and commercial concepts, into a single new comprehensive Enterprise Engineering concept and methodology. USAREUR used this methodology to produce its Information Architecture products that met Army Information Architecture objectives and HQDA suspenses.

An outline of the process of applying the IAM technique during the development of TAPES follows.

1. Defining the high level data model - the fundamental object classes.

1.1. Identify those categories-of-things (i.e., object classes) that an enterprise manages, in a continuum from macro to micro levels of management, which displays composition of objects from the highest to the lowest level of scale. When viewed from the lowest to the highest levels, this same continuum of object classes will show the distribution of objects. These object classes are identified from highest/macro level to lowest/micro level as:

1. location,

2. organization,

3. production unit,

4. function,

5. activity,

6. resource configuration, and

7. specific resource.

Note that object classes 1-4 and 6-7 are are hierarchical structures of things that are managed. Object class 5 is the hierarchical structure of the processes by which all other things are managed, as well as being things to be managed in themselves. This distinction will become clearer as we progress.

1.2. For each object class, define its internal hierarchical structure of objects and its common attributes. Load these object classes into the data table called H1 (Hierarchy 1).

2. Create the Catalog.

2.1. For each object within the hierarchy of an object class, create a unique attached-numerical-outline (a.k.a., a work breakdown structure - WBS) code. This individuates each object, while still keeping that object in the proper linear context with its parent-objects, sibling-objects and descendant-objects. Post this individuated object code to the corresponding object record in H1. The object code serves both as a displayed value and as an interim relational key.

2.2. Create a software module to display all of the object classes as a single linear "Catalog" of objects which may be perused by the system user. This catalog is created by relating a parent object code value to all of it's descendant object codes. This relation can take the form of an H1 "self-join" relation in relational database terms, or in the creation of software to show deeper levels of H1's object class's hierarchy, based on user-selected criteria.

2.3. Create a software module to maintain the H1 catalog's object classes. This entails keeping the object records in proper relationship to each other. This can be through the use of the object coding technique. Alternately, once a proper linear relationship is established between objects, a relational database key field could be generated from non-duplicating random numbers. In this way the object code becomes an attribute of the object and the random number becomes the linking key. In this way, objects will retain the proper relationship, even if they are realigned with respect to their original hierarchy.

2.4. Create a software module to display the object class common detail data attributes. These attributes should be in separate data tables from the catalog H1 table. There should be a separate detail table for each object class because the detail data attributes will differ between object classes. Name the detail tables D1 through D7 respectively, to correspond to the object class.

2.5. Create a software module link between the basic catalog, which shows a list of objects in hierarchical order, and the detail file.

2.6. Create a screen and report format for each catalog/detail-table linkage.

2.7. Provide a software toggle function (T1) for moving between the catalog's list of objects and the object's detail form/report.

3. For object class 5 (and/or its subclasses) create or identify the appropriate functional or activity software unit(s) that controls that specific activity object. This would normally be an information system that deals with the process of management, not the management of resources themselves.

3.1. For each other object class (and/or its subclasses) create or identify the appropriate software unit(s) that controls that specific object class. This would normally be an information system which specifically controls a resource, such as an operational accounting or distribution system, not a management system. One such software unit could be a comprehensive repository-based life-cycle-management LCM system for all repository objects. This is the case for TAPES. Each stage of the LCM process is defined in the activity model as a separate object in an activity object subclass called appropriately, Life Cycle Management. A separate software unit would then be created for each LCM object. Some of these software units would be: a requirement statement, a procurement plan, a purchase request, DoD 7935a Documentation, AIS Milestone I-V, etc. The LCM software would be integrated with the repository so that the LCM data would be accessed as object class 07 (Resource) objects within the catalog and cross-index.

3.2. For each of the above software unit(s) that controls that object (sub)class, identify and then optimize that one software unit (SU) which most accurately implements the most effective organization of that object's control. Provide each software unit with an object code from the activity object subclass .06.2.2.4. - software units.

3.3. Modify or develop a software module linkage between the catalog/detail file software module of paragraph 2.7 above and the optimized control software unit for each object from paragraph 3.2 above.

3.4. Create a software toggle function (T2) for moving between each object's detail form and the object's control software unit. Impose additional access controls at this point. This linkage can take the form of a communication software script into an existing host or LAN based software unit, or execution of a software unit on the local processor, as appropriate.

3.5. At some point the catalog and its interface to the controlling software units should have a reconciliation conducted so that each object in the control system is also in the catalog, and vice versa. At this point the catalog should be designated as the system of record (or accounting system) of the object itself, while the control software unit is the system of record for the object specific attributes and any transactions on that object.

4. For each object within the catalog, there are probably many other objects which have some relationship to it. These relatioships will normally fall into two categories of association: a selected object (base object) either contains an associated object as an organic component, or the base object is provided support by an external associated object of the same object class. The data table that contains these associated pairs of objects is the Cross-Index (H2) table.

4.1. The organic component category can be seen from two perspectives: distribution or composition. This gives us three separate views of each object: distribution, organic composition, and support.

4.2. By selecting a specific base object (e.g. an object from object class 05 - Activity), we can view the distribution of the 05 object across related 04,03,02, and 01 objects.

4.3. By reversing the direction of association we can view its composition by identifying all of the associated objects of a lower level object class (06, 07) that are organic to it.

4.4. The software function to flip between these associative cross-index views is Toggle T3. The software function to switch between the cross-index and catalog displays is Toggle T4.

4.5. The cross-index view will display two levels of object composition/distribution at one time. When using the composition view, the object code values will display the macro level object class (e.g. 05) on the left, with a lower micro level (i.e., 06 and/or 07) on the right. When in the distribution view, this will be reversed, with the micro level object class (e.g., 05) on the left, and a macro level (i.e., 04, 03, 02, and/or 01) on the right. Each view would also display those objects that provide support to the base object. These support objects would be in the right hand column of both cross-index displays.

4.6. The capability to shift the base object (i.e., to browse the cross-index) from a macro to a micro level is achieved by software function S1 (e.g., from an 03 object to an 06 object). This allows the user to drill-down into the specific composition of an object.

4.7. To shift the base object from a micro to a macro level within the cross-index would be provided by software function S2 (e.g., to shift the base object from an 05 object to an 03 object). This allows the user to get the big picture of the object's distribution.

4.8. A software module must be created to create and maintain the cross-index (H2) table by selecting a base object from the catalog, and then subsequently selecting associated objects from the catalog. The results of that selection would be appended into the H2 table.

4.9. An additional software module must be created to allow reports and output cross-tabulated tables of cross-indexed objects (e.g., a corporate directory).

5. It is perceived that all of the data tables and all of the TAPES software unit will operate in a distributed environment. In addition, all of the data tables must be split in a distributed data environment based on the individual record classification level. This could imply operation of the repository using a multilevel secure data base management system. The TAPES software unit would require strong access-control techniques to insure need-to-know access is limited to the functional requirements of each user. Each user's system USER-ID will consist of an extraction of his UIC, UIC Paragraph, Paragraph Multiplier, Paragraph Line Number, and Line Position Number (probably 11 digits). Each user's "need to know" information and transaction requirements are defined in H2 by the activity-object associations with each position-object in the unit object class. From this the repository software unit will identify his access requirements from the initial log-on. Variation from this access will require a transaction from the higher authority that has permission to change that access.