SECTION 2. SYSTEM SUMMARY

2.1 Background. Each enterprise, whether public or private sector, can be considered as a single dynamical system or entity for purposes of information systems planning and data modeling. See Figure 2.1 for an enterprise-common entity/relationship diagram.

2.1.0.1. The purpose of TAPES is to manage the enterprise's information mission and its associated resources.

2.1.0.2. It accomplishes this by providing an enterprise-wide network application by which existing and future asset management, control, and accounting Automated Information Systems (AIS) may be integrated with a detailed enterprise management model and resource management system, thereby reflecting an enterprise-wide view of information mission data. It accomplishes this by implementing relatively simple modifications and extractions from existing information systems and data, which when integrated by a comprehensive model, provides extremely potent and complex synergistic views of the enterprise as a dynamical system.

2.1.0.3. Specifically, TAPES documents an enterprise's Information Architecture as a related Management Model and Resource Model and then integrates it with those existing standard MIS (STAMIS) which use the DoD Unit Identification Code (UIC) with its associated:

finance Army Management Structure codes;

personnel Unit Processing Codes (UPC);

logistics DODACCs, Document Register numbers, and property book hand receipt/subhand receipt numbers;

force structure SACS, PERSACS, LOGSACS, TOE Standard Requirement Codes (SRC), Manpower Staffing Standard System (MS3) codes, and TAADS MTOE/TDA authorization documents;

facility ARLOC/GELOC codes;

and information mission ARPMIS, MODPLAN, LRAMRP, Budget, and Authorization codes;

which then interfaces with an integrated Life-Cycle-Management system to manage the enterprise's information mission area requirements for financial, information, personnel, materiel, facility, or force structure resources. The Management and Resource Models will consist of a series of "snapshots" of the existing enterprise environment. The first group of snapshots will be the baseline internal system environment (Baseline Configuration) from which longitudinal changes (Current Target Configurations) may be planned to move towards a conceptual vision (Objective Configurations) of the desired future environment.

2.1.0.3.1. As a result, data which is processed and extracted from standard reports of the above STAMIS may be related and displayed in any combination of area, organization, unit, function, activity (subject area, process, work center, task, procedure, product/service, or input), configuration (compliant or non-compliant with standards), and/or resource category.

2.1.0.3.2. The interface to the above STAMIS is created by adding a field to each STAMIS data structure to show the specific UIC/Paragraph/Line, and Function Model code or Activity (Information) Model code to which each recorded requirement, authorization, allocation, or issue record managed by that STAMIS is posted.

2.1.0.4. The system can then be used by authorized personnel at all management levels to provide controlled access to comprehensive and detailed information for enterprise-wide planning, programing, budgeting, execution, development, operations, maintenance, reorganization, review, analysis, revalidation, and disposition purposes. Example uses of TAPES are described at paragraph 2.4.1.

2.1.0.5. TAPES is an assemblage of interrelated initiatives which can be implemented in stages, with each stage providing useful products. The proposed method of implementing TAPES is to use rapid prototyping of software modules using Integrated Computer Aided System Engineering tools with a single development repository, with each software module providing immediate utility to the enterprise. The various software modules can be designed and developed so that they can implement TAPES in a modular, integrated fashion over time.

2.2. Objectives. TAPES provides several basic capabilities.

2.2.1. The Information Architecture provided by TAPES will provide a detailed enterprise "Directory of Resources" with each resource, to the lowest managed level, being uniquely identified in the Resource Model and related to the enterprise by the Management Model.

2.2.1.0.1. This directory of resources can be used in conjunction with electronic communication networks to build and then extend the enterprise X.500 electronic messaging directory. A portion of the Information Architecture code string (i.e., area, organization, unit, function, activity) of the enterprise directory code can serve as a consistent X.400 electronic messaging (e.g., E-Mail, application to application communication through file transfers and file access, or electronic data interchange) address, thereby making the enterprise-wide network the core technology of an effective, efficient, responsive, and secure integrated strategic planning, management control, operation and resource management application.

2.2.1.0.2. The X.400 address segments can be satisfied by using the Defense Switching Network (DSN) as the first (country) segment for inter-DoD traffic, the TAPES organization structure code plus location code as the second (Administrative Management Domain - ADMD) segment, the TAPES internal unit structure/function/activity code as the third (recipient organization) segment, and the specific person's name or a generic "Any Occupant" code as the fourth (recipient) segment. The third segment is the Private Management Domain (PRMD) (e.g., Email system) for the message.

2.2.1.0.3. When a person or application wants to send messages it can access the X.500 directory (much like today's DSN NIC @whois feature) and ask for any addresses for an organization, an area, a unit, a function, an activity, 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, area, unit, function, or activity search.

2.2.2. The Organization Model integration with the Functional Model of the Information Architecure provides the means to standardize and control organization office symbols for group communication and coordination purposes (e.g., AIG standardization and maintenance).

2.2.3. The Functional Architecture module of the Activity Model, linked to the Configuration Model and Asset Management systems and the Life Cycle Management system, serves as a basis for identifying all or specified resources associated with a given activity across the enterprise. That activity is then reviewed for the optimum methods and standard resource set (e.g., personnel grades/skills, information system services/hardware/software, supplies/equipment, facilities) by the appropriate authorities. That activity's "Solution-Set or Standard-Configuration" is then "Engineered" for optimum performance. This Solution Set will effectively integrate the Manpower Staffing Standards System (MS3), Budget, Facility, Information System, Combat Development, and Logistics planning activities into a single process used to produce standard sets of unit/function/activity capabilities. This integrated planning process can be effectively applied at all levels of the Department of the Army. It can be used manage the Army's participation in the DoD CIM program by facilitating identification and submission of CIM candidate systems.

2.2.4. The Data Architecture module of the Activity Model will display data creation, use, and flow for specific areas, organizations, and units from one activity work center task to the next, along with the volume and frequency of the data transmission between source and destination activities. Data transmission capacity requirements can then be aggregated by activity, unit, organization and area for network planning, budgeting, and operation purposes.

2.2.5. The Data Architecture will also allow those activities (i.e., those tasks which result in information products/reports) to identify the specific standard data elements which correspond to report fields. It will also display the input source and output destination activities for each report, enabling future unattended electronic messaging capabilities. This will facilitate the enterprise data management program.

2.2.6. The Data Architecture, because it documents the data requirements for each activity (subject area, process, work center, task, production procedure, output, input, data field) will define the data/system/network access requirements, with corresponding security controls, for each activity performed, based on the security requirements of those specified data, reports, systems, or networks. This security information can be interfaced to the personnel management systems to provide automated input into the Information Security and Automation Security programs. It will provide a means to automate the process of access determination and control, facilitating supervisory and security officer reviews and requests for information/access.

2.2.7. The integration of the Unit, Function, and Activity models provides the means to establish standard internal unit structure, for consistent TOE/MS3/TDA development, across all types and sizes of units.

2.2.8. The Activity model will serve as a hierarchical "Table of Contents" (i.e., outline) for an enterprise-wide online interactive publication and forms documentation system which can provide artificial-intelligence based mentoring, training, help system, and operations modules for specific task transactions. When a user enters the network, his USERID will inform the system, based on the interface between the personnel management systems and the Functional Architecture, which specific activities he participated as part of his assigned duties. The mentoring system will then automatically select and display only those portions of the enterprise "Table of Contents" that were related to his assigned duties. Accessing other portions of the mentoring "Table" will require supervisory approval.

2.2.9. The total Information Architecture can be used to display detailed and/or summary baseline resource information about any organization level and its subordinates. When the Information Architecture is integrated with the Life Cycle Management System, it would provide target and objective information.

2.2.10. The fully integrated Life Cycle Management system will serve as a single "System Decision Package" for new requirements which contains all system:

concept development and justification (system analysis),

compliance checks,

requirement validation,

resourcing

(LRAMRP-Extended Planning Annex years, Program Years 7-15;

MODPLAN-POM years, Program Years 1-6;

Schedule 80-Budget years, Budget Years 1-2;

Appropriations/Allocations/Allotments/Authorizations- Execution year, Current Year),

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, and

revalidation informtion.

As such, it will serve as a central repository of information about existing or future capability requirement. This will allow broad reviews of capabilities to identify duplicative, ineffective, inefficient, irresponsive, or inconsistent capabilities, and necessary interrealtionships between capabilities.

2.2.11. TAPES, as reflected in this Functional Description, will be an appropriate vehicle by which Army Information Architecture (AIA) and the DoD Corporate Information Management (CIM) initiatives of the defense Director of Information 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 a full corporate management environment 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. TAPES, as described in this Functional Description, will have immediate and full applicability for other Executive Branch and Federal government agencies and State, County and City governments, as well as private enterprises. The higher the level of implementation, the more consistent and stable the resulting system over time, and the greater the economies and efficiencies achieved.

2.3. Existing Methods and Procedures.

2.3.1. Organizational and personnel responsibilities.

2.3.2. Equipment being used.

2.3.3. Inputs and outputs including volume and frequency.

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

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

2.4. Proposed Methods and Procedures. The TAPES system will consist of Information Architecture and Life Cycle Management subsystems. The Information Architecture will contain a mapping of the relationships between seven basic attributes common to every enterprise (See Figure 2.1), 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 systems, and interfaces to existing standard information systems currently used to manage, control, or account for resources. The Information Architecture will document the baseline of existing mission resources, and provide an interface into a comprehensive resource management system used to manage the entire life cycle of every controlled resource within the enterprise.

2.4.0.1. The predominant attributes (e.g., sub-entities) of an enterprise are its assets, its configurations of systems, its activities to create intended products or services, its internal functional (responsibility/authority) structure, its production units (e.g., staffing/materiel structure [a.k.a. force structure] for specific units of mission capability), its aggregate organization structure of production units (e.g., mission organization), and the distribution of aggregate structure across its area of operations.

2.4.0.2. Assets, as configured into predefined standard system configurations, form an entity which will be labeled as an enterprise's Resource Model (i.e., USAREUR defined Technical Architecture). See Figure 2.4a.

2.4.0.3. Activities (i.e., USAREUR defined Information Model), organized by functional area, are assigned to specific production unit subelements. Activities reflect actions of humans, nature, or a combination of the two as actions within a dynamic man/machine system. See Figure 2.4b.

2.4.0.4. The production units, with their internal functional structures, are then organized into mission-derived organizations and are physically dispersed across the area of operations (i.e, USAREUR defined Geographic Model). See Figure 2.4c. (The integration of the above Geographic Models and Technical Architectures will form the equivalent Army Geographic/Technical Architecture).

2.4.0.5. Activities, functions, units, organizations, and areas, and the relationships between then will be labeled as an enterprise's Management Model (i.e., Army Functional and Data Architectures). See Figure 2.4d.

2.4.0.6. The enterprise data model (i.e., USAREUR defined Information Architecture) can then be described as being comprised of the Management Model and Resource Model entities. See Figure 2.4e.

2.4.0.7. The interface of the Management Model and the Resource Model is between the unit subelement, function, or activity, and the specific assets assigned to those entities. The unit subelement, function, or activity has requirements for specific system configurations, and the asset management, control, and accounting systems provide appropriate authorizations and allocations to fill those configurations. See Figure 2.4f.

2.4.0.8. The existing asset management, control, and accounting information systems, which are integrated into the Resource Model and Management Model, will provide the existing baseline of resource requirements, authorizations, and inventory. This is shown, along with the relating key data field, in Figure 2.4g.

2.4.0.9. The Management Model and Resource Model will be reviewed and queried by authorized personnel to provide current and past planning, control and operations information.

2.4.0.10. When planning to improve or add a new requirement capability, the system user will select the applicable areas, organizations, units, functions, and activities from the Management Model. The relationships between these Management Model entities are predefined and controlled by the user's parent organizations. If the user wishes to establish or modify a management relationship, the system will document that new relationship as a non-standard request.

2.4.0.11. He will then select predefined resource configurations, quantities, and fielding schedules by activity, function, unit, organization, or area, as appropriate, from the Resource Model. The predefined resource configurations will have standard resource costs assigned to them by functional experts (configuration architects) at the highest appropriate level of the enterprise. If the user wishes to establish or modify a resource configuration, the system will document that new configuration as a non-standard request.

2.4.0.12. The user's request for the new or improved capability will be forwarded to the unit force structure or SRC manager for review. That manager will assess whether the requested capability duplicates and existing Force Modernization System, whether a pending mission or force structure change affects the requested capability, force structure implications, and whether the requested capabiity can be applied to strategic or theater/tactical forces. The SRC manager will provide his comments to the functional proponent and configuration proponent for incorporation into their subsequent assessments.

2.4.0.13. The user's request for the new or improved capability will then be forwarded to the user's functional proponent within his organization. The functional proponent will concur or non-concur with the requested capability and its application to the predefined Management Model. If the management structure and applicability of the capability was non-standard, then the functional proponent will either reject the request, or concur with the request and forward it, after full validation and compliance checks are completed at that level, through channels to the appropriate level at which the Management Model may be modified to incorporate this new management relationship. If the requested management structure and applicability is not appropriate for the requested capability or is rejected as non-standard, the functional proponent will return the request to the user and assist him in selecting the appropriate management structure and applicability for the capability. Upon approving or receiving an approved requirement statement, the functional proponent takes full responsibility for satisfying the user's requirement. During the process of the functional review, the functional proponent will consider whether the request has broader applicability and/or is covered by a generic CAPR, or can be incorporated into an existing requirement statement. If the request has broader capability across his organization, the functional proponent will adopt the request and apply it across his organization as appropriate, and then forward through channels to his parent organization. The functional proponent will take all resource management actions necessary to implement the system.

2.4.0.14. At the same time that a request is being reviewed by the user's functional proponent, it will be reviewed by the proponents of the requested resource configurations. The configuration proponents will evaluate the request to determine if the requested configurations are appropriate to the requested capability. If any requested configurations are non-standard, the configuration proponent may reject the request, or concur with the request and forward it, after full validation and compliance checks are completed at that level, through channels to the appropriate level at which the Resource Model may be modified to incorporate this new configuration. If the requested configuration is not appropriate for the requested capability or is rejected as non-standard, the configuration proponent will return the request to the user and assist him in selecting the appropriate configurations.

2.4.1. Summary of Improvements.

Required TAPES capabilities. Refer to Figures ERD0-ERD34.

1. General Statement: Any data about the attributes of:

management information systems,

assets,

configurations,

activities [process, work center, task, procedure, product/service, input],

functions,

units,

organizations,

and/or areas

may be queried in any combination or order, sorted in any manner, with arithmetic operations being performed on any intermediate or final results

for approved standards or baseline required, authorized and/or on-hand resources,

and/or requested new standards or resources being acquired through Life Cycle Management.

2. Display on-hand quantities, serial numbers, and CLIN or LIN of specific configurations of equipment (e.g., microcomputer, 80286 CPU) by work center (e.g., office administration). (Asset-Configuration-Activity).

3. Display required, authorized, on-hand, planned (EPA/LRAMRP/MODPLAN), programed (POM), budgeted, committed, and acquired quantities, (with serial numbers, and CLIN or LIN as appropriate) of all equipment by work center (e.g., office administration) by function (S3), as of today's date, within USAREUR, for units scheduled for inactivation in FY 91. (Asset- Configuration-Activity-Function-Unit-Linked to Life Cycle Management System).

4. Display personnel requirement, authorization, and on-hand quantities, in MOS and grade order, for a specific work center (office administration) by function (S3), listing specific Authorization Document (MTOE/TDA) Unit Identification Code (UIC), paragraph, and line. (Asset-Configuration-Activity- Function-Unit).

5. Display quantities, serial numbers, and CLIN or LIN of all authorized and on-hand MTOE, TDA, and CTA equipment, and quantities and NSN for 15 days of deployed supply for the "Tactical Operations Center" work center for the S3 function, listing specific Authorization Document (MTOE/TDA) Unit Identification Code (UIC), paragraph, and line, as appropriate, for all 3rd Armor Division organizations. (Asset-Configuration- Activity-Function-Unit-Organization).

6. Display quantities, serial numbers, and CLIN or LIN of specific equipment (X.25 Gateway, PAD, or Terminal Server) by work center by function, listing specific Authorization Document (MTOE/TDA) Unit Identification Code (UIC), paragraph, and line, as appropriate, for all VII Corps units within the 6th Area Support Group, sorted and summarized by room number, building number, installation number (ARLOC), Area Support Team (AST), Base Support Battalion (BSB), and Area Support Group (ASG). (Asset-Configuration-Activity-Function-Unit-Organization-Area).

7. Display the computer system number, building number and UIC of all registered Wordstar 4.0 software within the Mannheim BSB, summarize the quantity by UIC, multiply that UIC quantity by the item software upgrade cost of $54.00, and then provide grand total quantity and upgrade cost for Mannheim BSB. (Asset- Configuration-Unit-Area)

8. Display the distribution of authorized and on-hand VII Corps 31M E6 enlisted personnel, and summarize at installation, AST, BSB, and ASG levels, providing SSN and DEROS for each record, sorted by earliest DEROS first. (Asset-Configuration- Organization-Area-Linkage to Personnel System)

9. Display a list of publications and forms associated with the Personnel Clerk position in Battalion S1's, and separately display the regulation paragraph and on-screen input form, with interactive instructions/tutorial/help, for the activity task "Change Marital Status. (Configuration-Activity-Linkage to OnLine Documentation/Training System)

10. For use in conducting a business case analysis, display by MACOM, Organization, Unit, Paragraph, Line; with corresponding ASG, BSB, AST, and installation location; the baseline required, authorized, and on-hand quantities (as of today's date) of all resources (in financial, information, personnel, materiel, facilities and force structure order) associated with a single transaction of task "Timekeeping for Civilian Personnel" and summarize total transaction sites, manhours, personnel costs, average manhours, average personnel costs, total supply costs, number of personal computers (MS-DOS) used to implement the transaction, number of manual transactions, and the percentage of total available manhours in a 40 hour workweek for those included personnel. Next display all current target validated requirement and programmed/budgeted authorization quantities, then committed or obligated quantities (e.g., procurements, contracts, active training base, materiel or software development) that have not been fielded to the affected units. (Asset-Configuration-Activity-Unit-Organization-Area-Linked to Life Cycle Management system)

11. Display the automated information systems titles and developers, by MACOM, organization and UIC which have or are developing software modules supporting the Task "Make Local Purchase" within the Work Center "Army Community Services/Family Support" within the Process "Manage the Non-Appropriated Fund" within the Subject Area "Funds" within the Function "Resource Management". (Asset-Activity, Functional Architecture module-Function-Linked to Life Cycle Management System, Development Documentation module)

12. Display the hierarchy of input Report Titles, numbers and preparation dates, with submitting organization, office symbol, DDN address, and STU III telephone number, from intermediate to original data sources, of the management data contained in the CINC's monthly "Critical Maintenance Issues" report which have originating data over 96 hours old for any data field. (Activity, Data Architecture module)

13. Display and assemble as an AIG the E-Mail address of any S4 position within USAREUR or FORSCOM which works with the activity "Convoy Planning". Separately list the location, organization, unit, UIC, MTOE/TDA number, MTOE/TDA paragraph and line number, DSN telephone number, STU III number, fax number, and encumbent name, grade, MOS/Specialty, and DEROS for each address.