.1. FUNCTIONAL DESCRIPTION

.1.1. GENERAL. The Total Architecture, Plans, and Execution System (TAPES) was conceived to provide a tool to aid the activities outlined in Army Field Manual (FM) 101-5, Staff Organization and Operations. It is a tool to facilitate the work of Executives such as Chiefs of Staff and their subordinates. It could feasibly be extended to serve as the system of record and accounting system for all objects/entities which the Army manages, as well as the relationships between them, allowing existing systems of record and standard systems to be integrated by the TAPES environment.

TAPES, as reflected in this functional description, is a

vehicle by which the Army information architecture (AIA) and the DoD Corporate Information Management (CIM) initiatives can be effectively, efficiently, and responsively implemented and managed. As a result of its use in implementing and managing AIA and CIM, TAPES can be extended for use as the corporate management centerpiece for DoD. Once the information architecture portion of TAPES is operational and deployed, Army-wide reorganization, realignment, contingency and operation planning can be greatly streamlined and expedited.

.1.1.1. Purpose of the Functional Description

This functional description (FD) for the Total Architecture, Plans, and Execution System (TAPES) is written to provide:

a. The system requirements to be satisfied which will serve as a basis for mutual understanding between the TAPES project office, the user, and the system developer.

b. Information on performance requirements, preliminary design considerations, and user impacts including fixed and continuing costs.

c. A basis for development of system tests.

.1.1.2.Project References

The need for an integrated management repository and life cycle management system was first documented in Sept 1988 through the Army Suggestion Program (US Army Europe #ERAD280055, ERAD280056, ERAD280057, ERAD280058, ERAD290067) and the derived documents titled "Information Engineering: Developing the Information Architecture" 13 Aug 90, as well as the USAREUR ISP study of 1984.

.1.1.3. Terms and Abbreviations. (TBD)

.1.2. SYSTEM SUMMARY

.1.2.1. Background.

The scope, complexity, fragmentation, and fast pace of modern government operations have reduced the ability of government agencies to respond in a fully productive manner, causing high productivity and quality to be the exception, rather than the rule, despite good intentions and committed efforts by government workers.

TAPES implements a technique of applying relatively simple and inexpensive information technology, systems theory, and information resource management concepts in a synergistic new way. This technique can begin to decrease the cost of operating networked organizations while increasing their effectiveness, without decreasing performance levels, all within a period of months.

TAPES allows any "thing" that an organization controls or manages to be uniquely viewed in terms of composition and distribution throughout the organization. TAPES employs concepts no more complex than that of a family tree, a table of contents, a concordance, a parts list for an item, or the plans for a family vacation. However, some complexity does arise within TAPES because of the integration of several simple concepts into a single system.

Every enterprise (business), whether public or private sector, regardless of its size or distribution, can be considered a single system for purposes of information systems planning, data modeling, and information management. Figure 1 depicts the enterprise "Federal Business".

TAPES provides several basic capabilities. Primarily TAPES will provide immediate access to all data about any enterprise resource, within any enterprise structure, at any life cycle management stage, to all authorized persons.

Specifically, TAPES documents the fundamental characteristics of the government enterprise as related information architecture and life cycle management systems. It then integrates them with existing standard MIS (STAMIS) that use the DoD Unit Identification Code (UIC) or a related code for resource accountability. Thus for each UIC, and its associated linkages to standard systems for resource accountability, a baseline is established.

This resulting baseline is then integrated with the information architecture and life-cycle-management system to manage the enterprise's information mission area requirements and assets.

Figure 2 shows the seven enterprise object classes and associated structures. Each object class is explained below.

Object Class 01-Location: The location name, and location coordinates (down to the building level) form the location model of the enterprise.

See figure 3 location structure and figure 3.1 example.

Object Class 02-Organization: Organizations are formed by assembling units that have inter-related and interdependent capabilities. Organizations are formed to achieve various objectives assigned by the enterprise. These objective missions relate to the basic purpose of the enterprise.

See figure 4 organization structure and figure 4.1 example.

Organizations are not necessarily discrete or homogenous. Area support organizations are formed to provide common products and services to all organizations operating within a defined physical region. The geographic boundaries of each area support component define its area of operations. In Europe organizations and units are often physically dispersed across the area of operations while they perform their missions (i.e. installations or communities).

Object Class 03-Units: Organizations are composed of units. Units, with their internal structures, represent standardized assemblages of fixed/limited mission, personnel, materiel, and support relationships that provide a limited self-sustaining capability. Army units have MTOE/tactical (combat, combat support, combat service support) or TDA/BASOPS (installation TDA, mobilization TDA, TDA augmentation to MTOE) missions. A unit is uniquely identified by a unit identification code (UIC).

See figure 5 unit structure and figure 5.1 example.

Object Class 04-Functions: Functions are the structured distribution of responsibilities and authority within units which accomplish the assigned missions of the enterprise.

See figure 6 function structure and figure 6.1 example.

Object Class 05-Business activities: Business activities are what work is done by the enterprise. Activities reflect actions of humans, machines, nature, or combinations of the three within a dynamic man/machine system.

See figure 7 business activity structure and figure 7.1 example.

Object Class 06-Configurations: Configurations are standard and non-standard assemblages of resources into system types. Each configuration may have multiple hierarchies of components or be a single entity in itself.

See figure 8 configuration structure and figure 8.1 example.

Object Class 07-Resources: Resources and the standard information systems to control them form an entity which will be labeled as an enterprise's technical inventory. Resources are real things that are on-hand and have unique identifiers such as serial numbers. Resources must be accounted for and maintained.

See figure 9 resource structure and figure 9.1 example.

Location, organization, unit, function, and business activity, and the relationships among them, will be labeled as the enterprise directory.

Unit, function, business activity, and configuration, and the relationships among them, will be labeled as the authorization document.

Unit, function, business activity, configuration, and resource, and the relationship among them, will be labeled as the accouting system.

Business activities, functions, units, organizations, and locations, and the relationships among them, will be labeled as the management model

Configurations and the technical inventory of resources and the relationship among them, will be labeled as the resource model.

The enterprise repository can then be described as being composed of the management model and resource model (as illustrated in fig 2.)

.1.2.2. Objectives

The purpose of TAPES: Provide a single system by which decision makers may manage the enterprise's information mission and its associated resources. TAPES accomplishes this by providing authorized persons access to data about any combinations of enterprise resources , structures and/or processes.

Provide a method by which recurring, routine business activities within the enterprise may be identified, optimized, standardized, modeled, and automated to the appropriate degree. It provides sufficient quantitative information about the occurrence of those business activities to enable accurate economic analysis of proposed improvements in activity processing or outputs.

Provide an information gathering/processing/storing/distributing tool which takes the seven object classes within an enterprise and relates those objects together into a stable and controlled, but dynamic, baseline model of the enterprise as a whole. Concurrently, provide a fully integrated life cycle management tool to effect the change of that baseline over time, towards the enterprise's prioritized objectives in pursuit of its long-term goals.

.1.2.3. Existing Methods and Procedures

Manual, and some automated, but not integrated with other identified objects.

.1.2.3.1. Organizational and personnel responsibilities.

.1.2.3.2. Equipment being used.

.1.2.3.3. Inputs and outputs including volume and frequency.

.1.2.3.4. Provisions in the system design for operation in degraded modes or at alternate sites in cases of emergency, disaster, or accident.

.1.2.3.5. Deficiencies, including limitations, such as time delays.

.1.2.4. Proposed Methods and Procedures

The TAPES system will consist of an enterprise repository and life cycle management subsystems. The enterprise repository will contain a mapping of the relationships between hierarchies of the seven object classes and as such will serve as a context data model for the enterprise and any subsequent subordinate data models. It will contain an inventory of existing (baseline) resources, predefined standard configurations of resources/systems, and interfaces to existing standard information systems currently used to manage, control, or account for resources. The enterprise repository will document the baseline of existing mission resources, and provide an interface into a comprehensive management system used to manage the entire life cycle of every controlled resource within the enterprise.

TAPES will provide a detailed enterprise "directory of resources". Each resource, to the lowest managed level, would be uniquely identified in the resource model and related to the enterprise by the management model. The directory will contain entries uniquely identifying all enterprise combinations of location, organization, unit, function, business activity, resource type/configuration, and resource quantities. The directory will consist of multiple relational databases. The first database will portray parent/child type relationships of the enterprise structures down to the lowest level of managed detail. When each structure or resource database is displayed, it will take the form of a numerical outline or work-breakdown-structure (WBS).

This directory of resources can be used in conjunction with electronic communication networks to build and then extend the enterprise's X.500 electronic messaging directory. The enterprise directory (fig 4) can serve as a consistent X.400 electronic messaging address (e.g., E-Mail, application to application communication through file transfers and file access, or electronic data interchange), thereby making the enterprise-wide network the core technology of an effective, efficient, responsive, management control application.

When a person or application wants to send electronic messages, it can access the X.500 directory (much like today's DSN NIC @whois feature) and ask for any addresses for an organization, a location, a unit, a function, an business activity, a configuration and/or any or all persons. Each address will contain all this information with the exception of the "any occupant" address, which will go to anyone who matches the organization, location, unit, function, or business activity search.

Life Cycle Management

The LCM system requires the requestor/operator to have a detailed knowledge of a mission deficiency, either functional or technical, and the life cycle stages required to implement the recommended solution for the deficiency. (The flow diagram of the LCM process is shown at fig. 10) The needs-request to implement the solution will be preapred as a requirement statement. This need/requirement must be in the form of removal, upgrade or the addition of a new capability.

The requestor/operator will review the unit information architecture for baseline required/authorized unit configurations (standard and non-standard) and on-hand resources.

From the management model, the requestor will select the organizations, units, functions, and business activities which will apply the requirement/capability. If a mission ability is requested which is pre-defined in the management model as a standard for this UIC, the preparation system validates that portion of the requirement. If not, the requested capability is tagged as non-standard.

From the resource model, the requestor will identify: the configurations and resources currently used to support his existing capability; standard configurations or resources to be added or removed from the unit resource model; and standard configurations required for the new capability. If the requested capability requires a configuration of resources that is currently not in the configuration structure, the requested configuration will be described in detailed text form and tagged as non-standard by the preparation system.

The selected standard configurations will have associated components and costs. The cost associated with the selected configuration will be posted to the requirement statement by the preparation software unit. The identified engineered standard activities that have associated operation costs will also be posted to the requirement statement by the preparation software unit. Non-standard configurations or activities must be separately costed by the requestor, and entered into the preparation software module.

After selecting applicable structures for the need/requirement, the requestor will conduct a qualitative functional analysis, concentrating mainly on impacts of the requested capability (a quanitative analysis will be done later in the LCM system). The requestor will access the financial data from the requirement statement pertaining to activities and configurations and conduct an initial cost/effectiveness analysis. The requestor will identify the increased qualitative effectiveness to be gained by the requested capability, and the estimated total program cost of this capability as stated. This estimated program cost will include the cost from the preparation of the requirement statement through the fiscal year and quarter when the requirement will be fully fielded. The estimated cost for annual operations of the requirement for six years will be calculated and included. In the event that acquisition costs extend out more that eight years from the current date, estimated new acquisition costs (not replacement of earlier acquisitions) will be identified out for 17 years beyond the current date as an extended planning annex. The program costs plus the six years of annual operations costs plus any extended planning annex costs will be identified as capability life cycle costs.

After determining estimated capability life cycle costs, the requirement statement will be finalized by the requestor. At this time the preparation phase of TAPES life cycle management

will be completed.

The Compliance Stage.

Management Model Compliance. Once a requestor has completed a requirement statement, the functional proponent for the requested business activity within the requestor's unit will check the requirement statement for compliance with the management model. The preparation software unit would have already tagged a required structure if it were non-standard for that unit or function. Thus the compliance check is intended to give the functional proponent an opportunity to ascertain whether the requestor really needs to implement the requested capability. If the requested capability is actually necessary for the requestor, as determined by the functional proponent, then the functional proponent will concur with the requirement statement. If the requested capability is not required by the requestor, the functional proponent will non-concur and reject the requirement statement. The functional proponent will document his grounds for rejecting the request. The compliance checking software unit will then notify the requestor of the requirement statement rejection. At this point, the requestor may re-work the requirement statement giving better justification and resubmit, or may cancel the requirement statement. The preparation software unit will delete all cancelled requirement statements one year after cancellation, and all rejected requirement statements after two years of inaction.

.1.2.4.1. Summary of Improvements

The total information architecture can be used to display detailed and/or summary baseline resource data about any organization level and its subordinates. When the information architecture is integrated with the life cycle management system, it will also provide target and objective resource data.

The fully integrated life cycle management system will serve as a single "system decision package" repository which contains all data about the following aspects of a requirement/capability:

Plans

[concept development and justification (system analysis),

compliance checks,

requirement validation],

Resources

[LRAMRP and AC2MP, Extended Planning Annex years, Program Years 7-15;

MODPLAN and TAA, POM years, Program Years 1-6;

Schedule 80 and TOE/MS3, Budget years, Budget Years 1-2;

Financial Appropriations/Allocations/Allotments/ Authorizations and Authorization Documents (MTOE/TDA/CTA/JTA), Execution year, Current Year],

Execution

[system development (system design and software development, with documentation through an interface to the enterprise repository and CASE environment, and materiel development),

acquisition,

deployment,

operation,

maintenance],

Review

[system performance statistics],

Assessment

[performace evaluation]

and direction

[system revalidation,

goals

objectives/projects/requirements].

As such, it will serve as a central repository of information about existing or future capabilities/requirements. This will allow broad reviews of capabilities to identify duplicative, ineffective, inefficient, unresponsive, or inconsistent capabilities, and necessary interrelationships between capabilities.

Integration of the management model's location, organization, unit, function, and business activity structures provides the means to standardize and control organization office symbols for group communication and coordination purposes (e.g., AIG standardization and maintenance) and to standardize staff structures.

Benefit: The principal beneficiaries of TAPES will be analysts, planners, managers, and decision makers in performance of their activities. It will aid thinkers in analyzing and planning on a continuous basis. It will provide the principal tool by which decision makers can achieve the best possible results, in the shortest possible time.

.1.2.4.2. Summary of Impacts

.1.2.4.2.1. User Organizational Impacts

The technique behind TAPES is intended to provide the ability to build a more complete and dynamic information infrastructure for any group of people, whether in a formal or informal organization - to form a "nervous system" for the organization. This is where expert system and neural network technology could be applied.

This technique could serve as a:

Directory,

Registry,

Table of Contents,

Repository,

Encyclopedia,

Catalog,

Cross-Index,

Cross-Reference,

Knowledge Base,

Expert System Model Base, and

Neural Network Model Base

for those things the Army uses, produces, and/or disposes of, displayed in terms of locations, organizations, production units, staff functions, business activities, resource configurations, and specific accountable resources.

By developing and implementing TAPES, the enterprise gives a tool to its executives, managers, and operatives that provides them visibility of and control over their operation.

.1.2.4.2.2.User Operational Impacts

The operator implements specific business activity transactions using defined rules to select limited options. The action officers and/or operators, conduct analyses across one or more resources, structures, or life cycle stages for purposes of planning and control, develop and presents alternative solutions to management problems and missions, and implement decisions. The decision maker states problems or missions and directs that plans be developed for his selection and implementation; determines the pace and direction of organization operations; and directs and evaluates the performance of action officers and operators. Each person within the organization plays a mixture of roles, depending upon the asigned business activity. Each business activity in a unit can have numerous operators, fewer knowledge workers, but only one decision maker. Where a business activity can be highly standardized and automated, the number of operators and subsequent management personnel will decrease contingent on operation tempo (OPTEMPO).

.1.2.4.2.3.User Development Impacts

N/A

.1.2.5.Assumptions and Constraints

N/A

.1.3.DETAILED CHARACTERISTICS

.1.3.1.Specific Performance Requirements

This system must provide, but is not limited to, the following requirements:

a. On-line data bases. Provide users with on-line data bases containing all necessary data to comply with the requirements of TAPES as established in this document.

b. Update Capability. Provide users with on-line update capability of data they have authorization and responsibility to update, using user friendly menus and screens.

c. Inquiry Capability. Provide fast and easy information retrieval using menus to produce predetermined reports and screen displayed information.

d. Edit Capability. Error messages should be provided as data fields are filled. Correction capability should be immediate. Error messages should be direct and precise in a language that the user can understand.

e. Download Capablilty. When required, STAMIS specific data will be downloaded to the appropriate data base in the TAPES structure.

f. Storage Capacity. Have the ability to store and process records necessary to support an installation or community size organization within at least a single Base Support Battalion area of operations.

g. Data base Administration. Provide a menu-driven interface to facilitate day to day management of the TAPES.

.1.3.1.1 Accuracy and Validity.

a. All mathematical calculations throughout TAPES must be accurate to ten significant digits.

b. All data downloaded from an external system for input into the TAPES data bases will be considered valid unless the steward for the data element deems otherwise.

.1.3.2 Functional Area System Functions. TAPES provides the framework for the following functions:

a. The ability to process in a batch mode the requirement statements (RS) from the users.

b. The ability to do an on-line automated validity check by comparing the user request against the management model, resource model, and existing/concurrent requests.

c. The ability to create the Long Range Army Materiel Requirements Plan (LRAMRP) and the IMA Modernization Plan (MODPLAN) for each level of the organization as appropriate.

d. The ability to create all required cost estimate documents (for programming dollars) in support of the IMA planning cycle.

e. The ability to do routine housekeeping functions related to database management.

f. The ability to provide query/display capability for any combination, order or sort sequence of the data attributes of: resources, configurations, business activities, functions, units, organizations, and/or locations, with arithmetic or statistical operations being performed on any intermediate or final results.

Example: display on hand quantities, serial numbers, and CLIN or LIN of specific configurations of equipment by workcenter within selected commands

g. The ability to allow responsible authority to update system tables under security controls appropriate to the level and security requirements of the data.

h. The ability to provide accurate, timely, synchronized, validated, and secure distribution and consolidation of data tables, software unit changes/revisions, and system documentation.

i. The ability to date information, so decision makers can see when critical data was last updated.

.1.3.3 Inputs and Outputs. Inputs will consist of the following data base structures created and maintained by responsible authority; location, organization, unit, function, business activity, configuration, and the resource data structures. In addition, input transactions in the form of requirement statements will create the RS data base which is the start of the life cycle management process. User inputs will consist of typed/selected input/query/output options and values from a multiple-windowed graphical interface. Outputs will be 1) validation check of the requirement against the management model and resource model; 2) the IMA Modernization Plan; 3) the Long Range Army Materiel Requirements Plan (LRAMRP); 4) requirement tables formatted for use in capability request production; 5) cost estimates by unit based on requirements; 6) results of adhoc and standard query capability in the form of formatted reports, lists, text and graphic matrices, graphic tables/charts, and thematic maps against all data and models.

.1.3.4 Database/Data Bank Characteristics. Data base structures see figures 3 through 9.

.1.3.5 Failure Contingency.

a. Backup. The system to include all data bases should be backed up daily by the servicing O&M office, with backups being kept in the grandfather, father, son method. When a backup medium becomes a great grandfather, it can be reused for backup again. Backup media and frequency may be determined by the servicing O&M office.

.1.4. DESIGN CONSIDERATIONS

.1.4.1. System Description

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

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 element of the data model (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 element of the organization into a dynamic cross-tabulated matrix (the cross-index).

The combination of the three is the corporate repository. It displays both the composition and distribution of any object in the matrix. A matrix can be built for organizations of any size and then merged to form a single repository for the newly integrated organizations or functions.

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) 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 support 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 comply with Department of Defense documentation standard DOD STD 7935a.

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 mangement (planning, programming, budgeting and execution system - PPBES), force management, 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 applying the IAM technique follows.

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

1.4.1.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. unit, 4. function, 5. activity, 6. resource configuration, and 7. specific resource. Note that object classes 1-4 and 6-7 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.4.1.1.2. For each object class, define its internal hierarchical structure and its common attributes. Load these object classes into the data table called H1 (Hierarchy 1).

1.4.1.2. Create the Catalog.

1.4.1.2.1. For each object within the hierarchy of an object class, create an 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 code to the corresponding object record in H1.

1.4.1.2.2. Create software 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's individuated code to all of its descendant objects' individuated 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.

1.4.1.2.3. Create software 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 individuated 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 individuated 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 and individuated code.

1.4.1.2.4. Create software 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 codes.

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

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

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

1.4.1.3. For object class 5 (and/or its subclasses) create or identify the appropriate 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.

1.4.1.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 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 object software units would be: a requirement statement, a procurement plan, a purchase request, DoD 7935a documentation, LCM Milestone I-V, etc. In this sense 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.

1.4.1.3.2. For each of the above software unit(s) that controls an 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 individuated code from the activity object subclass .06.2.2.4. (software units)

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

1.4.1.3.4. Create a 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.

1.4.1.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.

1.4.1.4. For each object within the catalog, there are probably many other objects that have some relationship to it. These relationships will normally fall into two categories of association: the 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.

1.4.1.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.

1.4.1.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.

1.4.1.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.

1.4.1.4.4. The software unit to flip between these associative cross-index views is toggle T3. The software unit to switch between the cross-index and catalog displays is toggle T4.

1.4.1.4.5. The cross-index view will display two levels of object composition/distribution at one time. When using the composition view, the object numbers 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 objects that provide support to the base object. These support objects would be in the right hand column of both displays.

1.4.1.4.6. The capability to move the base object (i.e., to browse the cross-index) from a macro to a micro level is achieved by software unit 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.

1.4.1.4.7. The capability to move the base object from a micro to a macro level within the cross-index would be provided by software unit 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.

1.4.1.4.8. A software unit 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.

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

1.4.1.5. It is perceived that all of the data tables and all of the software units 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 software units would require strong access-control techniques to insure need-to-know access is limited to the functional requirements of each user. 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. Since each user's system USER-ID will consist of his UIC, UIC paragraph, paragraph multiplier, paragraph line number, and line position number (probably 11 digits), the repository software 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.

1.4.2 System Functions

1.4.3 Flexibility (TBD)

1.4.4 System Data

Every product/service (output) produced by executing a specific transformation operation (procedure) results in data being created or modified by the use of resources (input). The data may be the output itself, or the data may be attribute values of the procedure performance, input, or output. All data is a resource.

Every procedure, output, or input has data attributes which will be displayed as data fields in a data base management system. This data structure will also contain data fields for the input source and output destination activities for each report, enabling future unattended electronic messaging capabilities. When the flow of data from each business activity to the next, along with data about the volume and frequency of data flow between source and destination locations and configurations is known, then data transmission capacity requirements can be aggregated by configuration, business activity, unit, organization and location for network planning, budgeting, and operation purposes.

When critical information is required at a management level, then all of the input data fields, back to the creating procedure level will be given a "date/time changed" attribute to show currency of the critical information, along with its originator and intermediate locations.

.1.5.ENVIRONMENT (TBD)

.1.5.1.Equipment Environment

.1.5.2.Support Software Environment

.1.5.3.Communications Requirements

.1.5.3.1.Graphic Overview

.1.5.3.2.Hardware

.1.5.3.3.Software

.1.5.4.Interfaces

.1.5.5.Summary of Impacts

.1.5.5.1.ADP Organizational Impacts

.1.5.5.2.ADP Operational Impacts

.1.5.5.3.ADP Development Impacts

.1.5.6.Failure Contingencies

.1.5.7.Assumptions and Constraints

.1.6.SECURITY (TBD)

.1.6.1.Background Information

.1.6.2.Control Points, Vulnerabilities, and Safeguards

.1.6.2.1.Control Points

.1.6.2.2.Vulnerabilities

.1.6.2.3.Safeguards

.1.6.3.System Monitoring and Auditing

.1.6.3.1.Journalizing

.1.6.3.2.Audit Trail

.1.7.SYSTEM DEVELOPMENT PLAN (TBD)

.1.8.COST FACTORS (TBD)