NATO CALS HANDBOOK

March 1, 2000

EXECUTIVE SUMMARY
The NATO CALS Office (NCO) published Draft 2 of the NATO CALS Handbook in
January 1996. That product has been circulated around the world and has been translated by
other nations into their native language. This in itself shows the interest and desire by nations
and associated industry to learn and use the CALS concept.
This product is Draft 3. It is intended to service as an extension and update Draft 2 and is
being circulated for comments and recommendations. It is our intention to finalize this
document by June 2000. However, the NCO views this handbook as a living document. To
meet that objective, the NCO will make this a Web-based product to be continuously
updated, as new information becomes available.
A summary of the contents of the NATO CALS Handbook Draft 3 follows.
SECTION ONE: INTRODUCTION
This section sets the stage. It begins with a succinct definition and background for CALS and
looks at the challenges faced by decision-makers. The military, industry, and multinational
program perspective for CALS is addressed next.
A basic tenet of CALS is that information is an asset. From the Defense System (DS)
perspective, technical information is a vital asset required to support the DS across its
lifecycle. Accordingly, this section closes with an overview of the Staged Process for
Through Life Information Management (TLIM), which is the central theme for the remainder
of the handbook.
SECTION TWO: STAGE 1: DEVELOPING A THROUGH LIFE INFORMATION
MANAGEMENT STRATEGY
This section describes the process for developing a Through Life Information Management
(TLIM) Strategy. A careful examination of the business and IT environment in which the
program will operate is conducted and an assessment of the options for adding value from a
Shared Data Environment (SDE) is made. Alternative options are then examined in relation
to their ability to contribute to achieving business goals and using cost/benefit and risk
management techniques. The culmination of this process is the strategy for designing,
developing and implementing TLIM within an organization.
SECTION THREE: STAGE 2: DEVELOPING A THROUGH LIFE INFORMATION
MANAGEMENT PLAN
The goal of this section is to provide the tools needed to build an Information Management
Plan (IMP). The IMP is a comprehensive document used to support the intended program
business strategy as developed in Stage 1. The IMP should address both government and
industrial requirements and be under program management control throughout the life-cycle.
All parties (NATO, nations, armed services, contractors, etc.) must agree to the IMP. The
methodology and content of the IMP is fully developed in this section.
SECTION FOUR: STAGE 3: IMPLEMENTING A SHARED DATA ENVIRONMENT
After the IMP is developed it is time to get physical. Today, most of the DS technical
information required to support program operations is created and managed within the
industrial infrastructure.
In addition, a NATO/Multi-national infrastructure is needed to

ES-i

manage this information throughout NATO and nations. TLIM using a Shared Data
Environment (SDE) concept is designed to help address these problems.
Implementation of a SDE or the best alternative is accomplished through the execution of the
program IMP described in the previous section. This section is intended to provide the
project manager with an understanding of what makes up an SDE and give him the
information needed to implement an SDE.
SECTION FIVE: STAGE 4: MANAGING INFORMATION THROUGH LIFE
This section addresses the role and responsibilities associated with managing DS information.
The goal is to provide correct information to the right user, when it is needed, where it is
needed, and in the form it is needed.
The program manager (PM) will need to assign information management responsibilities
within the program office. The PM can assign information management to one or more
program office members as an "other duty as assigned" or recruit a dedicated Information
Manager (IM) to the team. Information management, like configuration, security and change
management, is the responsibility of program management and is an integral part of the IMP.
SECTION SIX: MODELS
This section presents three different concepts (NATO CALS Through Life Business Model
(TLBM), NATO CALS Data Model (NCDM) and Life-Cycle Cost (LCC)) designed to help
implement the NATO CALS concept.
The TLBM is a tool to help decision-makers manage change. It presents a vision of how
NATO can improve its acquisition and logistics process for multinational programs by
making best use of information technology over the life-cycle of a DS.
The NCDM is a formal description of the data required to support the logistics process for the
acquisition and support of major systems.
LCC looks at the total cost of ownership of a process, system, or piece of equipment. For
installation of new equipment, a LCC analysis can assist in deciding which options add the
most economic benefits to the program.
SECTION SEVEN: TOOLS
This section provides an overview of the selection of user tools. Acquiring proper tools is as
important as designing and implementing the Shared Data Environment. These tools are an
integral part for providing connectivity with a common basis for sharing DS information in
ready-to-use formats. It is important to note that data stored within the SDE is useless unless
it can be extracted, analyzed, manipulated, updated, formatted, and presented in a user
friendly manner by the appropriate software application tool.
In parallel with the analysis used to determine the SDE requirements, tool selection must be
considered within the SDE context. The ideal situation is to provide an environment that
separates information from applications and is based on open system standards. This will
help ensure future flexibility in upgrading to new software solutions as technology evolves.

ES-ii

SECTION EIGHT: TECHNIQUES

This section provides a series of techniques to be used as aids when implementing CALS. It
begins with a discussion on performing a "Through Life Business Case Analysis." It then
leads to a discussion on other CALS techniques such as Change Management (CM),
developing a NATO/Government CALS Concept of Operations (NCoO), the relationship of
the NCoO to a contractor and The Contractor Integrated Technical Information System
(CITIS).
In addition, this section addresses applying CALS to the acquisition logistics and operational
logistics processes, the management of technical information in the form of technical data
packages and acquiring and managing technical manuals.
SECTION NINE: SECURITY
This section covers the very sensitive and critical issue of Information security in a modern
electronic world. Organizations, which are connected to extensive networks and global
communications, are realizing that achieving enterprise-wide information security is a
complex but necessary task. Users have become critically dependent on information, and on
the systems and networks used to provide access to this information. As this dependency
grows, the need for increased connectivity and inter-connectivity amongst the many diverse
government and private sector systems becomes ever more important. User organizations are
concerned about protecting classified and sensitive information, about ensuring the integrity
and authenticity of the information, and about controlling access to the information and to the
systems and networks that process and transport this information.
Within this environment, this section develops two broad security areas; those security
measures defined within the requirements of a particular contract and defined by the
acquiring organization and its sponsoring governmental entity and those actions taken by
organizations to achieve routine information assurance.
SECTION TEN: CONTRACTING
This section provides sample generic CALS Statement of Work (SOW) language and CALS
source selection criteria to assist the acquisition manager in the implementation of CALS for
a Project.
This CALS-related language should be used in developing the functional
requirements within each applicable section of the Request for Proposal (RFP).
SECTION ELEVEN: CALS STANDARDS OVERVIEW
This section presents a brief summary of CALS standards. It is NATO CALS Policy to
promote the use of International, technology, and vendor independent standards and to
harmonize, wherever possible, standards and their application.
SECTION TWELVE: EXAMPLES AND LESSONS LEARNED
This section provides an overview of CALS programs that have implemented the CALS
strategy. It is intended to provide the reader with some real life examples of the thinking
behind bringing about change and the processes used to implement that change.

ES-iii

TABLE OF CONTENTS
EXECUTIVE SUMMARY ........................................................................................................ES-i
LIST OF FIGURES ...................................................................................................................... xvi
LIST OF TABLES....................................................................................................................... xviii
1.0 INTRODUCTION .................................................................................................................... 1
1.1 Background ................................................................................................................... 1
1.1.1 Continuous Acquisition and Life -cycle Support ............................................ 1
1.1.2 The Challenge to Decision Makers................................................................ 1
1.1.3 Industry Perspective ....................................................................................... 2
1.1.4 Military Perspective ....................................................................................... 2
1.1.5 The Multi-National Program Perspective ...................................................... 2
1.1.6 NATO Perspective ......................................................................................... 3
1.1.7 NATO CALS .................................................................................................4
1.1.7.1 Going Digital Now .......................................................................... 5
1.1.7.1.1 Through Life Management .............................................. 5
1.1.7.1.2 Through Life Information Management .......................... 5
1.1.7.1.3 Shared Data Environment ................................................ 6
1.2 Managing the Life-cycle Process .................................................................................. 7
1.2.1 NATO CALS Environment ........................................................................... 7
1.2.2 Program Management Issues ......................................................................... 9
1.2.2.1 Relationship Management .............................................................. 9
1.2.2.2 Continuous Review and Approval.................................................. 9
1.2.2.3 Contract Management..................................................................... 9
1.2.2.4 Financial Management .................................................................... 9
1.2.3 Technical Information Management Issues .................................................10
1.2.3.1 Requirement Management ............................................................10
1.2.3.2 Configuration Management ..........................................................10
1.2.3.3 Quality Assurance .........................................................................10
1.2.3.4 Information Management ..............................................................10
1.2.4 The Staged Process for Through Life Information Management ................11
1.3 Purpose of the NATO CALS Handbook ....................................................................12
2.0 STAGE 1: DEVELOPING A THROUGH LIFE INFORMATION MANAGEMENT
STRATEGY..........................................................................................................................13
2.1 Develop Improvement Targets....................................................................................13
2.2 Analyze Environment and Options .............................................................................14
2.2.1 Business Environment and Options .............................................................14
2.2.1.1 External Environment...................................................................14
2.2.1.2 DS Program Process Improvement Tool ......................................14
2.2.1.3 DS Program Process Improvement Tool Tailoring ......................15
2.2.1.4 DS Program Forecasting...............................................................16
2.2.1.5 Content of Program Strategy for TLIM ........................................16
2.2.2 IT Environment and Options .......................................................................18
2.3 Analyze Cost and Benefits..........................................................................................19
2.4 Decide Through Life Information Management Strategy ..........................................23
3.0 STAGE 2: DEVELOP A THROUGH LIFE IN FORMATION MANAGEMENT PLAN...24
3.1 Analyze User Requirements........................................................................................27
3.2 Define Information Requirements ..............................................................................27
3.3 Define Infrastructure Requirements............................................................................27
3.4 Develop Information Management Plan.....................................................................28

3.5 Develop a Business Case for Through Life Information Management ......................29
3.5.1 Business Case Need .....................................................................................29
3.5.2 Why Do We Need It Now?..........................................................................29
3.5.3 Benefit Determination..................................................................................30
3.5.3.1 Benefit Indication..........................................................................30
3.5.3.2 Benefit Classification ....................................................................30
3.5.4 Cost Determination ......................................................................................32
3.5.4.1 Unit Costs ......................................................................................32
3.5.4.2 When Costs Are Accrued..............................................................32
3.5.5 The Analysis ................................................................................................32
3.5.5.1 Rollout Model...............................................................................32
3.5.6 The Financial Model....................................................................................33
3.5.7 Sensitivity Analysis .....................................................................................33
3.5.8 Project Specific Aspects...............................................................................33
4.0 STAGE 3: IMPLEMENTING A SHARED DATA ENVIRONMENT ................................34
4.1 Develop the Statement of Work..................................................................................34
4.2 Place CALS on Contract.............................................................................................35
4.3 Implement the Information Technology .....................................................................35
4.4 Implement Data Models ..............................................................................................36
5.0 STAGE 4: MANAGING INFORMATION THROUGH LIFE ............................................37
5.1 General Considerations...............................................................................................37
5.1.1 Information Manager ...................................................................................37
5.1.2 Contractor Involvement ...............................................................................37
5.1.3 Data Management Scheme...........................................................................38
5.2 Input Information ........................................................................................................39
5.3 Update Information .....................................................................................................39
5.4 Access/Distribute Information ....................................................................................39
5.5 Store Information ........................................................................................................39
6.0 MODELS ................................................................................................................................41
6.1 The Through Life Business Model .............................................................................41
6.1.1 Purpose of a Through Life Business Model ................................................41
6.1.2 Developing a TLBM ....................................................................................43
6.1.2.1 TLBM Definition..........................................................................43
6.1.2.2 TLBM Scope .................................................................................43
6.1.2.3 Purpose..........................................................................................43
6.1.2.4 TLBM Viewpoint..........................................................................44
6.1.2.5 Manage a Defense System Through Life......................................44
6.1.2.5.1 Defense System..............................................................45
6.1.2.5.2 TLBM Principles ...........................................................45
6.1.2.5.2.1 Concurrent Engineering Approach .................46
6.1.2.5.2.2 Life-cycle Integration......................................46
6.1.2.5.2.3 The Use of a Shared Data Environment .........46
6.1.2.5.2.4 Multi- Disciplinary Groups .............................46
6.1.2.5.3 Information as an Asset .................................................47
6.1.2.5.4 Organizational Interfaces ...............................................47
6.1.2.5.4.1 NATO CALS Handbook.................................47
6.1.2.5.4.2 NATO CALS Data Model ..............................47
6.1.2.6 Manage a Defense System Through Life - First Level
Breakdown....................................................................................47

ii

6.1.2.6.1 Establish and Control Defense System Program

Through Life..................................................................49
6.1.2.6.1.1 Develop Life-cycle Strategies and Policy.......51
6.1.2.6.1.2 Establish and Run the Defense System
Organization ...................................................52
6.1.2.6.1.2.1 Place and Manage Contracts ............54
6.1.2.6.1.2.2 Manage Defense System
Information......................................54
6.1.2.6.2 Obtain Defense System..................................................55
6.1.2.6.2.1 Develop Defense System ................................57
6.1.2.6.3 Support the Use of the Defense System.........................58
6.1.2.6.4 TLBM Activity Definitions ...........................................60
6.2 NATO CALS Data Model ..........................................................................................60
6.2.1 Introduction..................................................................................................60
6.2.1.1 Motivation .....................................................................................60
6.2.1.2 Information Modeling...................................................................60
6.2.1.3 How to Use the NCDM.................................................................61
6.2.1.3.1 Specifying Information Requirements...........................61
6.2.1.3.2 Def ining a Common Vocabulary...................................62
6.2.1.3.3 Implementing an Integrated Product Database ..............63
6.2.1.3.3.1 In the Industry .................................................64
6.2.1.3.3.2 In NATO Armed Forces .................................66
6.2.1.4 How to Implement the NCDM in a Program ................................66
6.2.1.5 How to Achieve Interoperability ..................................................67
6.2.2 The NATO CALS Data Model....................................................................68
6.2.2.1 What is the NATO CALS Data Model? .......................................68
6.2.2.2 Business Drivers ...........................................................................68
6.2.2.3 The High Level Model..................................................................69
6.2.2.4 Model Organization ......................................................................71
6.2.3 The Core Model (CoreModel) .....................................................................71
6.2.3.1 Overview .......................................................................................71
6.2.3.2 Description ....................................................................................71
6.2.3.2.1 Product Structure for Design and Manufacture .............72
6.2.3.2.2 Product Structure for Logistic Breakdown ....................74
6.2.3.2.3 Crossing Between Breakdowns and Product Structure .77
6.2.3.3 EXPRESS G Diagrams .................................................................77
6.2.4 Failure Analysis (Anomaly) .........................................................................77
6.2.4.1 Overview .......................................................................................77
6.2.4.2 Description ....................................................................................78
6.2.4.2.1 Effects ............................................................................78
6.2.4.2.2 Causal Relationships......................................................78
6.2.4.3 EXPRESS G Diagrams .................................................................79
6.2.5 Task Descriptions (Task) .............................................................................80
6.2.5.1 Overview .......................................................................................80
6.2.5.2 Description ....................................................................................80
6.2.5.2.1 What to Do.....................................................................80
6.2.5.2.2 What is Used to Do the Job............................................82
6.2.5.3 EXPRESS G Diagrams .................................................................83
6.2.6 Technical Documentation (InfoObj) ............................................................83
6.2.6.1 Overview .......................................................................................83

iii

6.2.6.2 Description ....................................................................................83

6.2.6.3 EXPRESS G Diagrams .................................................................85
6.2.7 Logistic Support Analysis ............................................................................85
6.2.7.1 Overview .......................................................................................85
6.2.7.2 Description ....................................................................................86
6.2.7.2.1 Scenario and Role ..........................................................86
6.2.7.2.2 Characteristics ................................................................86
6.2.7.3 EXPRESS G Diagrams .................................................................87
6.3 Developing a Life-cycle Cost Model..........................................................................87
6.3.1 Life-cycle Cost Models ................................................................................88
6.3.1.1 Background...................................................................................88
6.3.1.2 A Summary of Design-to-LCC and Life-cycle Cost Models ....88
6.3.1.3 Life-cycle Cost Model Characteristics ..........................................89
7.0 TOOLS....................................................................................................................................91
7.1 Tools ............................................................................................................................91
7.1.1 Desktop User Applications ..........................................................................91
7.1.2 Tool Sets ......................................................................................................92
7.1.3 Areas for Tool Consideration.......................................................................92
7.1.4 Configuration Management .........................................................................94
7.1.4.1 NATO and Contractor Roles in the CM Process ..........................96
7.1. 4.2 CM Benefits, Risks, and Cost Impact...........................................98
7.1.5 Interchange Specifications ...........................................................................99
7.1.5.1 Introduction...................................................................................99
7.1.5.2 Background................................................................................. 100
7.1.5.3 NATO CALS Data Architecture................................................. 101
7.1.5.4 Through Life Business Model Analysis ..................................... 103
7.1.5.5 Architectural Core....................................................................... 106
7.1.5.6 Product ID ................................................................................... 106
7.1.5.7 Organization................................................................................ 106
7.1.5.8 Configuration .............................................................................. 107
7.1.5.9 State............................................................................................. 107
7.1.5.10 Effectivity.................................................................................. 107
7.1.5.11 Linking and Referencing........................................................... 108
7.1.5.12 Product Life -cycle Support (Logistics)..................................... 108
7.1.5.13 Within the NATO Context ........................................................ 108
7.1.5.14 Information Sharing and Exchange .......................................... 109
7.1.5.14.1 Bulk Data Transfer..................................................... 110
7.1.5.14.2 Data Lists ................................................................... 110
7.1.5.14.3 Tables......................................................................... 110
7.1.5.14.4 Reports ....................................................................... 110
7.1.5.14.5 Direct Access ............................................................. 111
7.1.5.14.6 Dynamic Link ............................................................ 111
7.1.5.14.7 Through Life Interchange/Interface Specifications ... 111
7.1.5.15 Methodology............................................................................. 111
7.1.5.15.1 Define Scenario .......................................................... 113
7.1.5.15.2 Apply the Scenario to the TLBM............................... 113
7.1.5.15.3 Define Government/Industry Interface ...................... 113
7.1.5.15.4 Determine TLIS Purpose ........................................... 113
7.1.5.15.5 Select Type/Style of Exchange .................................. 113
7.1.5.15.6 Determine Nature of the TLIS ................................... 114

iv

7.1.5.15.7 Define Content of TLIS ............................................. 114

7.1.5.15.8 Develop STEP Part 21 Definition .............................. 114
7.1.5.16 Use of EXPRESS...................................................................... 115
7.1.5.17 EXPRESS Import Fac ilities ...................................................... 115
7.1.5.17.1 EXPRESS Rules ........................................................ 117
7.1.5.17.2 Use of ISO 10303-21 ................................................. 118
7.1.5.18 Common Conventions for all Interchange Specifications ........ 120
7.1.5.18.1 Example of Conventions ............................................ 120
7.1.5.19 An Example Interchange Specification..................................... 121
7.1.5.19.1 Objective .................................................................... 121
7.1.5.19.2 Activity Overview ...................................................... 121
7.1.5.19.3 Activity Description ................................................... 121
7.1.5.19.4 Activity Methodology................................................ 122
7.1.5.19.5 Ma pping of Required Data into the NCDM.............. 122
7.1.5.19.6 The Use Study Interface Specification Schema ......... 123
7.1.6 Product Data Management......................................................................... 124
7.1.7 Enterprise Resource Management ............................................................. 125
8.0 TECHNIQUES ..................................................................................................................... 128
8.1 Through Life Business Case Analysis ...................................................................... 128
8.1.1 Background................................................................................................ 128
8.1.2 Introduction................................................................................................ 129
8.1.3 Purpose of this Section............................................................................... 129
8.1.4 Business Case Modeling Fundamentals..................................................... 130
8.1.4.1 What is a Business Case?............................................................ 130
8.1.4.2 What is the Role of Business Case Modeling in Logistics
Reengineering? ........................................................................... 131
8.1.4.3 When Should I Prepare a Business Case? ................................... 131
8.1.4.4 How Do I Get Started?................................................................ 132
8.1.4.5 What Should My Model Include? ............................................... 132
8.1.4.6 Who Should Prepare a Business Case and What Should They
Know? ....................................................................................... 133
8.1.4.7 What Should the Decision-Maker Know? .................................. 133
8.1.4.8 What Else Should I Know?......................................................... 134
8.1.5 Business Case Model Minimum Report Requirements:
A Simple
Structure ............................................................................................................... 134
8.1.5.1 Executive Summary.................................................................... 135
8.1.5.2 Boundaries of the Business Case - Goals and Vision................. 136
8.1.5.3 Boundaries of the Business Case - Context and Perspective ...... 136
8.1.5.4 Boundaries of the Business Case - Functional Performance and
Metrics........................................................................................ 137
8.1.5.5 Boundaries of the Business Case - Initiatives Considered.......... 138
8.1.5.6 Boundaries of the Business Case - Alternatives Considered ...... 139
8.1.5.7 Boundaries of the Business Case - Key Assumptions ................ 140
8.1.5.8 Boundaries of the Business Case - AS-IS Activity Model......... 140
8.1.5.9 D iscussion of Alternatives - Functional Process Description..... 141
8.1.5.10 Discussion of Alternatives - Performance Impact and Metrics 141
8.1.5.11 Discussion of Alternatives - Technical Architecture
(Optional) ................................................................................ 141
8.1.5.12 Discussion of Alternatives - Cost Projections (Economic
Analysis) .................................................................................. 142

8.1.5.13 Discussion of Alternatives - Cost Projections - Investments.... 143

8.1.5.14 Discussion of Alternatives - Cost Projections - Operational .... 144
8.1.5.15 Discussion of Alternatives - Risk Assessment.......................... 144
8.1.5.16 Comparison of Alternatives - Functional.................................. 145
8.1.5.17 Comparison of Alternatives - Performance .............................. 145
8.1.5.18 Comparison of Alternatives - Costs .......................................... 146
8.1.5.19 Comparison of Alternatives - Investment Costs ....................... 146
8.1.5.20 Comparison of Alternatives - Operational Cost Savings .......... 147
8.1.5.21 Conclusions, Recommendations, and Issues ............................ 147
8.2 CALS Techniques..................................................................................................... 147
8.2.1 Approach to Implementation - Change Management ................................ 147
8.2.1.1 General........................................................................................ 147
8.2.1.1.1 CALS ........................................................................... 147
8.2.1.1.2 PMview ........................................................................ 147
8.2.1.1.3 Techniques ................................................................... 148
8.2.1.2 Step 1 - Motivate to Change ....................................................... 148
8.2.1.2.1 Top Level Management ............................................... 148
8.2.1.2.1.1 Vision Statement ........................................... 148
8.2.1.2.1.2 Understanding ............................................... 149
8.2.1.2.2 Why Change................................................................. 149
8.2.1.2.2.1 Current Environment .................................... 149
8.2.1.2.2.2 Change Drivers ............................................. 149
8.2.1.2.2.2.1 Fear of Failure................................ 149
8.2.1.2.2.2.2 Critical Assumption Analysis ........ 149
8.2.1.2.2.2.3 Need for Structural Evolution........ 150
8.2.1.2.2.2.4 Agility ............................................ 151
8.2.1.3 Step 2 - Develop Change Plan.................................................... 151
8.2.1.3.1 Develop an Organizational Structure ........................... 151
8.2.1.3.2 Identify Customer Needs ............................................. 152
8.2.1.3.2.1.1 Customer - Things We Know ........ 152
8.2.1.3.2.1.2 What is a Customer? ...................... 153
8.2.1.3.2.1.3 Select Organizations ...................... 153
8.2.1.3.2.1.4 Determine Resources ..................... 153
8.2.1.4 Step 3 - Conduct Training ........................................................... 154
8.2.1.5 Step 4 - Identify Goals and Performance Measures .................... 154
8.2.1.5.1 Business Case Analysis ................................................ 155
8.2.1.5.2 Performance Measures................................................. 155
8.2.1.5.2.1.1 Cycle Time ..................................... 156
8.2.1.5.2.1.2 Cost ................................................ 156
8.2.1.5.2.1.3 Quality............................................ 156
8.2.1.5.2.1.4 Asset Utilization............................. 156
8.2.1.5.2.1.5 Revenue Generated........................ 157
8.2.1.5.3 Goal Prioritization........................................................ 157
8.2.1.6 Step 5 - Document, Plan, and Sell .............................................. 157
8.2.1.7 Step 6 - Create Tiger Teams ....................................................... 157
8.2.1.8 Step 7 - Implement ...................................................................... 158
8.2.1.8.1 People ........................................................................... 159
8.2.1.8.2 Business ....................................................................... 159
8.2.1.8.3 Processes ...................................................................... 159
8.2.1.8.4 Information................................................................... 159

vi

8.2.1.8.5 Technology................................................................... 159

8.2.1.9 Step 8 - Monitor .......................................................................... 160
8.2.1.9.1 Evaluate Results ........................................................... 160
8.2.1.9.2 Recognize Success ....................................................... 161
8.2.1.9.3 Adjust ........................................................................... 162
8.2.1.10 Change Tools ............................................................................ 162
8.2.1.10.1 Success Stories ........................................................... 162
8.2.1.10.2 Compendium - Business Technologies...................... 162
8.2.1.10.3 Total Cost of Ownership-Models............................... 162
8.2.1.10.4 Business Process Modeling Tools ............................. 162
8.2.1.10.4.1.1 To-Be Business Models ............... 163
8.2.1.10.4.1.2 Why? ............................................ 163
8.2.2 Guide for Developing a NATO/Government CALS Concept of
Operation ................................................................................................... 163
8.2.2.1 Section Summary........................................................................ 163
8.2.2.1.1 Purpose/Scope .............................................................. 163
8.2.2.1.2 How to Use This Section ............................................. 164
8.2.2.2 CALS Implementation Strategy.................................................. 164
8.2.2.3 Relationship of the NCoO to Contracting Process ..................... 165
8.2.2.3.1 Pre-Request For Proposal/Request For Quotation
Activities and RFP/RFQ Release ................................ 166
8.2.2.3.2 Contractor Proposal..................................................... 167
8.2.2.3.3 Proposal Evaluation ..................................................... 167
8.2.2.3.4 Negotiation ................................................................... 167
8.2.2.3.5 Contract Award............................................................ 168
8.2.2.4 Bac kground Information for NCOO Development .................... 168
8.2.2.4.1 Identify Data Type Deliverables .................................. 169
8.2.2.4.2 Data Users.................................................................... 170
8.2.2.4.3 Identify Data Use/Processing ....................................... 170
8.2.2.4.4 Identify Data User Infrastructure ................................. 171
8.2.2.4.5 Identify Type of Data Deliverable ............................... 172
8.2.2.4.6 Determine Data Format................................................ 172
8.2.2.4.7 Determine Data Interchange Standards ........................ 173
8.2.2.4.8 Determine Data Delivery and Access Media ............... 173
8.2.2.4.8.1 Physical Media .............................................. 173
8.2.2.4.8.2 Telecommunications ..................................... 173
8.2.2.5 Data Acquisition Requirements Method..................................... 174
8.2.2.5.1 Identify Data Type Requirements................................ 174
8.2.2.5.2 Identify Data Users ...................................................... 175
8.2.2.5.3 Identify Data Use/Processing ....................................... 176
8.2.2.5.4 Identify Data User Infrastructure ................................. 176
8.2.2.5.5 Identify Type of Data Deliverable ............................... 176
8.2.2.5.6 Identify Data Format Required.................................... 177
8.2.2.5.7 Identify Data Interchange Standards ............................ 178
8.2.2.5.8 Identify Data Delivery and Access Media ................... 178
8.2.3 Concurrent Engineering............................................................................. 179
8.2.3.1 The Key to Concurrent EngineeringShared Data ..................... 180
8.2.3.2 Example Use of an Integrated Database ..................................... 181
8.2.3.2.1 Design Process ............................................................. 181
8.2.3.2.2 Maintenance Analysis .................................................. 181

vii

8.2.3.2.3 Design for Manufacturing Analysis ............................. 181

8.2.3.2.4 Detailed Design............................................................ 182
8.2.3.2.5 Assembly Analysis....................................................... 182
8.2.3.2.6 Re-design ..................................................................... 182
8.2.3.2.7 Release ......................................................................... 182
8.2.4 CITIS - Implementation of Contractor Integrated Technical Information
Service ....................................................................................................... 183
8.2.4.1 Introduction................................................................................. 183
8.2.4.1.1 The Primary Advantages of Using CITIS.................... 183
8.2.4.2 The Decision to Acquire CITIS .................................................. 184
8.2.4.2.1 Preliminary Data Collection ........................................ 185
8.2.4.2.2 Number of Data Reviewers and Users......................... 185
8.2.4.2.3 Recommended CITIS Deliverables ............................. 185
8.2.4.2.4 Infrastructure Upgrades and Contractor Compatibility 186
8.2.4.2.5 Reviewer Locations ...................................................... 187
8.2.4.2.6 Data Currency .............................................................. 187
8.2.4.2.7 Existing Electronic Communication Capabilities........ 187
8.2.4.2.8 Data Revision Frequency............................................. 188
8.2.4.2.9 Program Considerations ............................................... 188
8.2.4.2.10 CITIS Functional Requirements Determination ........ 188
8.2.4.3 CITIS Functionality .................................................................... 188
8.2.4.3.1 CITIS Services and Functions ..................................... 188
8.2.4.3.2 Printing Capabilities..................................................... 192
8.2.4.4 Contracting for CITIS ................................................................. 193
8.2.4.4.1 NATO/NATO Nations Concept of Operations ............ 193
8.2.4.4.2 Solicitation ................................................................... 193
8.2.4.4.3 CITIS Contract Line Item Number .............................. 194
8.2.4.4.4 Sample CITIS Statement of Work ............................... 194
8.2.4.4.4.1 Scope ............................................................. 195
8.2.4.4.4.2 Applicable Documents .................................. 195
8.2.4.4.4.3 Specific Requirements .................................. 195
8.2.4.4.4.4 CALSIP......................................................... 195
8.2.4.4.4.5 CITIS Site Implementation Priorities ........... 196
8.2.4.4.4.6 CITIS Period of Performance ....................... 196
8.2.4.4.4.7 CITIS Installation.......................................... 196
8.2.4.4.4.8 CITIS Data Residency and Storage .............. 196
8.2.4.4.4.9 Data Classification........................................ 197
8.2.4.4.4.10 Functions and Services ............................... 197
8.2.4.4.4.11 Availability and Accessibility..................... 197
8.2.4.4.4.12 User Furnished Information........................ 197
8.2.4.4.4.13 Multi-user Access ....................................... 198
8.2.4.4.4.14 Interface Compatibility ............................... 198
8.2.4.4.4.15 Communication Protocols........................... 198
8.2.4.4.4.16 Training Support......................................... 198
8.2.4.4.4.17 Telephone Support ...................................... 198
8.2.4.4.4.18 Data Configuration Management................ 198
8.2.4.4.4.19 Security ....................................................... 199
8.2.4.4.4.20 Core Functions ............................................ 199
8.2.4.4.4.21 Tailorable Functions ................................... 199
8.2.4.4.4.22 Archive........................................................ 199

viii

8.2.4.4.4.23 Download.................................................... 200

8.2.4.4.4.24 User Groups ................................................ 200
8.2.4.4.4.25 Printing Capabilities .................................... 200
8.2.4.4.4.26 L icensing..................................................... 200
8.2.4.4.4.27 Subcontractor Data ...................................... 200
8.2.4.4.4.28 Program Data Repository............................ 201
8.2.4.4.4.29 Equipment and Telecommunications.......... 201
8.2.4.4.4.30 CITIS Acceptance and Testing ................... 201
8.2.4.4.4.31 Final Disposition of Data ............................ 202
8.2.4.4.5 Deliverables ................................................................. 202
8.2.4.5 CITIS Development .................................................................... 202
8.2.4.5.1 CITIS Strategy ............................................................. 203
8.2.4.5.1.1 CITIS Program-Specific Working Data
Repositories .................................................. 203
8.2.4.5.1.2 CITIS and Suppliers/Subcontractors............. 204
8.2.4.5.1.3 Data Availability Factors .............................. 205
8.2.4.5.1.4 Acceptance of Data Delivered via CITIS ..... 205
8.2.4.5.2 Hardware, Software, and Networks ............................. 205
8.2.4.5.2.1 Operating System Considerations ................. 205
8.2.4.5.2.2 File Format Considerations ........................... 206
8.2.4.5.2.3 Neutral Data File Options ............................. 206
8.2.4.5.2.4 Hardware and Telecommunications Options 207
8.2.4.5.2.5 Infrastructure Changes .................................. 208
8.2.4.6 CITIS Issues................................................................................ 208
8.2.4.6.1 Legal Issues.................................................................. 209
8.2.4.6.1.1 Proprietary Data Rights................................. 209
8.2.4.6.1.2 Software Rights/Licensing............................ 209
8.2.4.6.2 Warranties and Liabilities ............................................ 209
8.2.4.6.3 International Data Exchange ........................................ 210
8.2.5 Applying CALS to the Acquisition Logistics and Operational Logistics
Processes .................................................................................................... 210
8.2.5.1 Acquisition Logistics and Operational Logistics........................ 210
8.2.5.2 ILS, LSA, and LSAR Introduction ............................................. 211
8.2.5.2.1 The Integrated Logistics Support................................. 211
8.2.5.2.2 Logistics Support Analysis .......................................... 212
8.2.5.2.3 Logistics Support Analysis Record.............................. 212
8.2.5.2.4 ILS Summary ............................................................... 213
8.2.5.2.5 LSA Summary............................................................. 213
8.2.5.2.6 LSAR Summary........................................................... 214
8.2.5.2.7 MIL -STD-1388-2B Summary..................................... 214
8.2.5.2.8 AECMA SPEC 2000M Summary ............................... 215
8.2.5.2.9 AECMA SPEC 1000D Summary................................ 215
8.2.5.3 LSA DATA Activities ................................................................ 215
8.2.5.3.1 LSA Data Creation Activities ...................................... 215
8.2.5.3.2 Follow -on LSA Data Modification .............................. 216
8.2.5.3.3 LSA Data Management ................................................ 216
8.2.5.3.4 LSA Data Uses During the Acquisition Process.......... 216
8.2.5.3.5 LSA Data Uses During the Operational Phase ............ 217
8.2.5.3.6 CALS-Related Questions............................................. 218
8.2.5.4 LSA Process in a CALS Environment ........................................ 218

ix

8.2.5.4.1 Potential Sources of LSA Data .................................... 219

8.2.5.4.2 Managing/Maintaining LSA Data ................................ 219
8.2.5.4.3 Using LSA Data in the CALS Environment ................ 219
8.2.5.4.4 CALS Effects on LSAR Report Requirements............ 219
8.2.5.4.5 Interaction of LSA Data with Concurrent
Engineering/Integrated Design.................................... 220
8.2.5.4.6 Specific CALS Considerations Affecting Data
Acquisition .................................................................. 220
8.2.5.4.7 Migration of LSA Data into ILS Element Products..... 220
8.2.5.5 Sample CALS and LSA Tasks Statement of Work.................... 221
8.2.5.5.1 MIL -STD-1388-1A 100 Series Tasks.......................... 221
8.2.5.5.2 MIL -STD-1388-1A 200 Series Tasks.......................... 221
8.2.5.5.3 MIL -STD-1388-1A 300 Series Tasks.......................... 222
8.2.5.5.4 MIL -STD-1388-1A 400 Series Tasks.......................... 222
8.2.5.5.5 MIL -STD-1388-1A 500 Series Tasks.......................... 223
8.2.5.6 Future Considerations for the LSA Process in a CALS
Environment ............................................................................... 223
8.2.5.6.1 Integrated Weapon Systems Database ......................... 223
8.2.5.6.1.1 Future Trends ................................................ 223
8.2.5.6.1.2 Effects on LSA Data and LSAR Databases .. 223
8.2.5.6.2 Contractor Integrated Technical Information Service . 224
8.2.5.6.2.1 Future Trends ................................................ 224
8.2.5.6.2.1 Effects on LSA .............................................. 224
8.2.5.6.2.2 Effects on LSA Databases ............................ 224
8.2.5.6.3 NATO CALS Efforts ................................................... 225
8.2.5.6.3.1 Acquisition Workshop .................................. 225
8.2.5.6.3.1.1 Objectives ....................................... 225
8.2.5.6.3.1.2 Workshop Results .......................... 225
8.2.5.6.3.2 Operational Logistics Workshop .................. 226
8.2.5.6.3.2.1 Objectives ....................................... 226
8.2.5.6.3.2.2 Workshop Results .......................... 226
8.2.5.7 Summary and Conclusions ......................................................... 227
8.2.6 Applying CALS to the Creation, Management, and Use of Technical
Data Packages .......................................................................................... 227
8.2. 6.1 Introduction................................................................................. 227
8.2.6.1.1 Scope ............................................................................ 228
8.2.6.1.2 Purpose......................................................................... 228
8.2.6.2 General Considerations ............................................................... 229
8.2.6.2.1 TDP Data...................................................................... 229
8.2.6.2.1.1 Engineering Drawings and Integral Parts
Lists............................................................. 229
8.2.6.2.1.2 Illustrated Text Documentation .................... 230
8.2.6.2.1.3 Product Description ...................................... 230
8.2.6.2.2 TDPs in the CALS Environment ................................. 231
8.2.6.2.2.1 Paper, Mylar Hardcopy................................. 231
8.2.6.2.3 Digital Data Deliverables............................................. 232
8.2.6.2.4 Life-cycle Considerations ............................................ 232
8.2.6.2.5 Infrastructure Development ......................................... 233
8.2.6.2.6 Data Uses ..................................................................... 233
8.2.6.3 Specific Considerations .............................................................. 234

8.2.6.3.1 TDP Delivery ............................................................... 234

8.2.6.3.2 Potential TDP Delivery Options .................................. 234
8.2.6.3.3 Raster ........................................................................... 235
8.2.6.3.4 Processable Data Files ................................................. 235
8.2.6.3.4.1 Drawing and Product Description Data Files 235
8.2.6.3.4.2 Illustrated Text D ata Files............................. 236
8.2.6.3.4.3 Text Formats ................................................. 236
8.2.6.3.4.3.1 Graphics and Illustration Formats.. 237
8.2.6.3.4.3.2 Standard Page Description
Language ....................................... 237
8.2.6.3.4.3.3 Neutral Data Files .......................... 238
8.2.6.4 Decision Guidelines .................................................................... 238
8.2.6.4.1 Maintenance and Control of the TDP .......................... 238
8.2.6.4.2 Competitive Reprocurement ........................................ 238
8.2.6.4.3 TDP Modification/Revision Determination................. 238
8.2.6.4.4 Digital System/Environment........................................ 239
8.2.6.4.5 System/Environment Compatibility............................. 239
8.2.6.5 Sample CDRLs ........................................................................... 239
8.2.6.5.1 Raster Delivery Option ................................................ 239
8.2.6.5.2 Product Data File Delivery Option .............................. 240
8.2.6.5.3 Native CAD/CAE Data File Delivery Option ............. 240
8.2.6.5.4 Product Data File Delivery Option (IGES Format) ..... 241
8.2.6.6 Advantages and Disadvantages of Delivery Options.................. 241
8.2.6.7 Contract Validation..................................................................... 242
8.2.6.7.1 Contractor Validation................................................... 242
8.2.6.7.1.1 Validation by Contractor Physical
Configuration Audit or Verification
Reviews ....................................................... 243
8.2.6.7.1.2 TDP Validation Report ................................. 243
8.2. 6.7.2 Government Verification ............................................. 243
8.2.6.7.2.1 Digital Data Product Acceptance .................. 243
8.2.6.7.2.2 CITIS Acceptance......................................... 243
8.2.6.7.2.3 CALSIP Acceptance ..................................... 244
8.2.7 Applying CALS to the Creation, Management, and Use of Technical
Manuals.................................................................................................... 244
8.2.7.1 General Consideration................................................................. 244
8.2.7.1.1 Identify/Establish the Requirements for the TM ......... 245
8.2.7.1.2 Identifying the TM Users Requirements .................... 246
8.2.7.1.2.1 Infrastructure Development .......................... 246
8.2.7.1.2.2 Data Uses ...................................................... 247
8.2.7.1.3 TMs in the CALS Environment ................................... 248
8.2.7.1.4 Non Digital Data Deliverables..................................... 248
8.2.7.1.4.1 Paper.............................................................. 248
8.2.7.1.4.2 Microfiche/Microfilm ................................... 248
8.2.7.1.4.3 Digital Data Deliverables.............................. 249
8.2.7.1.4.3.1 Data Formats .................................. 249
8.2.7.1.4.3.2 Media ............................................. 249
8.2.7.1.4.4 Life-cycle Considerations ............................. 249
8.2.7.1.4.5 TM Contract Requirements........................... 250
8.2.7.2 Specific Considerations .............................................................. 250

xi

8.2.7.2.1 TM Delivery Format Selection .................................... 250

8.2.7.2.1.1 Raster ............................................................ 250
8.2.7.2.1.2 Illustrated Text Data Files............................. 251
8.2.7.2.1.3 Text Format................................................... 251
8.2.7.2.1.4 Graphics and Illustration Formats................. 252
8.2.7.2.1.5 Page Description Language .......................... 253
8.2.7.2.1.6 Neutral Data Files ......................................... 253
8.2.7.2.2 Interactive Electronic Technical Manual..................... 253
8.2.7.2.3 IETM Viability............................................................. 254
8.2.7.2.4 IETM Development ..................................................... 255
8.2.7.3 TM Development ........................................................................ 255
8.2.7.3.1 TM Availability ........................................................... 255
8.2.7.3.1.1 TM Development .......................................... 255
8.2.7.3.1.2 TM Permanent Change Page Development.. 256
8.2.7.3.1.3 TM Update Revision Development .............. 256
8.2.7.3.2 New Technical Manual or Complete Revision............ 256
8.2.7.3.2.1 Source and Legacy Data Considerations ...... 256
8.2.7.3.2.2 Defense System Configuration
Considerations .............................................. 257
8.2.7.3.2.3 Program Life-Cycle Considerations ............. 257
8.2.7.3.2.4 Additional TM Update Revision Decisions .. 257
8.2.7.3.2.5 Conversion of Illustrations ............................ 257
8.2.7.4 Decision Guidelines .................................................................... 258
8.2.7.4.1 Decision #1: Deliverable Options................................ 258
8.2.7.4.1.1 Destination System Constraints on Form ..... 258
8.2.7.4.1.2 Interim Dual Deliverables............................. 258
8.2.7.4.2 Decision #2: Forms Options ........................................ 259
8.2.7.4.2.1 Composed Documents .................................. 259
8.2.7.4.2.2 Processable Files ........................................... 259
8.2.7.4.2.3 CITIS Interactive Access .............................. 259
8.2.7.4.3 Decision #3: Specification and Standard Options ...... 259
8.2.7.4.3.1 Composed Documents .................................. 259
8.2.7.4.3.2 Specifications and Standards for Graphics ... 260
8.2.7.4.3.3 Specifications for Vector Graphics ............... 260
8.2.7.4.3.4 Processable Text ........................................... 261
8.2.7.4.4 Decision #4: Digital delivery mode options ............... 261
8.2.7.4.4.1 Magnetic Tape ............................................... 261
8.2.7.4.4.2 Floppy Disk................................................... 261
8.2.7.4.4.3 Optical Disk .................................................. 261
8.2.7.4.5 Digital Deliverable Summary ...................................... 262
8.2.7.4.5.1 Example - Delivery of Digital Data as
Processable Files .......................................... 262
8.2.7.5 Validation and Verification......................................................... 262
8.2.7.5.1 Contractor Validation................................................... 262
8.2.7.5.2 NATO/NATO Nations Verification ............................ 262
8.2.7.5.2.1 Digital Data Acceptance ............................... 262
9.0 SECURITY........................................................................................................................... 264
9.1 What is Information Security.................................................................................... 264
9.1.1 The Environment ........................................................................................ 264
9.1.2 Types of Security ....................................................................................... 264

xii

9.1.2.1 Regulatory Requirements ............................................................ 264

9.1.2.2 Information Assurance................................................................ 264
9.2 What Needs to be Considered? ................................................................................. 265
9.2.1 System Security Methodology ................................................................... 265
9.2.2 Technical Security Countermeasures......................................................... 265
9.2.2.1 Fundamental Security Services ................................................... 265
9.2.2.2 Security Technologies................................................................. 265
9.2. 2.3 Robustness Strategy.................................................................... 265
9.2.2.4 Interoperability Framework........................................................ 266
9.2.2.5 Security Management Infrastructure Considerations.................. 266
9.2.3 Security Solutions Framework................................................................... 266
9.2.3.1 Requirement Category Guidance................................................ 266
9.2.3.2 Security Management Infrastructure Considerations.................. 266
9.2.3.3 Aggregated Solution ................................................................... 266
9.2.4 Technology Characterization..................................................................... 267
10.0 CONTRACTING................................................................................................................ 268
10.1 Introduction............................................................................................................. 268
10.2 How to contract for CALS - Sample Statement of Work Language and Source
Selection Criteria ................................................................................................... 268
10.3 Statement of Work Language ................................................................................. 268
10.3.1 Scope ........................................................................................................ 268
10.3.2 Specific Requirements ............................................................................. 268
10.3.3 CALS Implementation Plan..................................................................... 268
10.3.4 CALS Approach....................................................................................... 269
10.3.5 Database Architecture/System Tradeoffs................................................. 269
10.3. 6 CALS Standards Conformance Test ........................................................ 270
10.3.7 Security .................................................................................................... 270
10.3.8 Program Assessment and Control ............................................................ 271
10.3.9 Post Award CALS Program Orientation Conference .............................. 271
10.3.10 Government Furnished Information ...................................................... 271
10.3.11 Contractor Integrated Technical Information Services .......................... 271
10.3.12 Data Element Dictionary [If CITIS is required.] ................................... 272
10.3.13 Engineering Data (Graphic and Text Files) ........................................... 272
10.3.14 Automation and Functional Integration................................................. 272
10.3.15 Reliability and Maintainability Automation .......................................... 272
10.3.16 R&M-Logistic Support Analysis Record Integration............................ 273
10.3.17 LSAR Data Automation......................................................................... 273
10.3.18 Reliability Centered Maintenance and Age Exploration Automation ... 273
10.3.19 Level of Repair Analysis ....................................................................... 274
10.3.20 Diagnostics............................................................................................. 274
10.3.21 Management Information Tools ............................................................ 274
10.3.22 Technical Manuals ................................................................................. 274
10.3.23 Supply Support....................................................................................... 275
10.3.24 Facilities Data ........................................................................................ 275
10.3.25 Training .................................................................................................. 275
10.4 Source Selection Criteria ........................................................................................ 275
10.4.1 Source Selection for CALS...................................................................... 275
10.5 Guidelines and Sample Clauses for Electronic Data Interchange .......................... 276
10.5.1 Introduction .............................................................................................. 276
10.5.2 Agreement First Page ............................................................................... 277

xiii

10.5.3
10.5.4
10.5.5
10.5.6

Object and Scope ..................................................................................... 277

Definitions ................................................................................................ 278
Authenticity of Messages......................................................................... 279
Validity and Formation of Contract......................................................... 280
10.5.6.1 Validity of the Contract............................................................ 280
10.5.6.2 Formation of the Contract......................................................... 281
10.5.7 Admissibility in Evidence of EDI Messages ........................................... 281
10.5.7.1 Processing and Acknowledgement of Receipt.......................... 282
10.5.7.2 Processing of Electronic Data Interchange Messages .............. 282
10.5.7.3 Acknowledgement of EDI Messages........................................ 282
10.5.7.4 Time Limit and Acknowledgement of Receipt Transmission .. 283
10.5.7.5 Failure of Receipt of an Acknowledgement ............................. 283
10.5.7.6 Inability to Send Messages ....................................................... 284
10.5.8 Security and Protection of EDI Messages ............................................... 285
10.5.8.1 Obligations of Parties................................................................ 285
10.5.8.2 NATO Classified Information .................................................. 285
10.5.8.3 Security Procedures and Measures ........................................... 285
10.5.8.4 Failure and Security Procedures ............................................... 285
10.5.8.5 Encryption................................................................................. 286
10.5.9 Confidentiality ......................................................................................... 286
10.5.10 Data-Log: Recording, Storage, and Reconciliation of EDI Messages.. 287
10.5.10.1 Storage Procedures and Time Limits ...................................... 287
10.5.10.2 Format of Storage ................................................................... 288
10.5.11 Operational Requirements for EDI........................................................ 289
10.5.11.1 Operational Environment ........................................................ 289
10.5.11.2 Operational Equipment ........................................................... 290
10.5.11.3 Means of Communications ..................................................... 290
10.5.11.4 EDI Message Standards .......................................................... 290
10.5.11.5 Codes ....................................................................................... 290
10.5.12 Technical Specifications and Requirements .......................................... 291
10.5.12.1 User Manual............................................................................ 291
10.5.12.2 Test and Trial Procedures ....................................................... 292
10.5.13 Liability.................................................................................................. 293
10.5.13.1 Exclusion of Liability ............................................................. 294
10.5.13.2 Force Majeure ......................................................................... 294
10.5.13.3 Intermediaries Liability ........................................................... 294
10.5.13.4 Supplier Contracts................................................................... 294
10.5.14 Dispute Resolution................................................................................. 295
10.5.14.1 Options.................................................................................... 295
10.5.14.2 Arbitration Clause ................................................................... 295
10.5.14.3 Court of Law ........................................................................... 296
10.5.14.4 0ption C................................................................................... 296
10.5.15 Applicable Law ...................................................................................... 296
10.5.16 Effect, Modification, Term, and Severability ........................................ 297
10.5.16.1 Effect ....................................................................................... 297
10.5.16.2 Modification............................................................................ 297
10.5.16.3 Termination............................................................................. 297
10.5.16.4 Severability ............................................................................. 297
10.5.17 Signature Page........................................................................................ 298
11.0 CALS STANDARDS OVERVIEW................................................................................... 299

xiv

11.1 NATO CALS Standards Policy .............................................................................. 299

11.1. 1 ISO Standards .......................................................................................... 299
11.1.2 Multi-national or National Standards ....................................................... 299
11.1.3 Standardization Agreements/Military Profiles ........................................ 299
11.1.4 Limitations of Standards .......................................................................... 299
11.1.5 NATO User Groups ................................................................................. 300
11.2 NATO CALS Standards ......................................................................................... 300
11.2.1 Temporary Standard [ T ]......................................................................... 300
11.2.2 Emerging Standard [ E ]........................................................................... 300
11.2.3 Recommended Standard [ R ] .................................................................. 300
11.2.4 Not Recommended Standard [ N ] ........................................................... 300
11.2.5 Undetermined Status [ ] ........................................................................... 300
12.0 EXAMPLES AND LESSONS LEARNED........................................................................ 301
12.1 The Viking Submarine............................................................................................ 301
12.2 The Crusader (US Howits)...................................................................................... 302
12.2.1 Statement of the Situation........................................................................ 303
12.2.2 CALS Technologies, Philosophies, and Standards Implemented............ 304
12.2.3 Team Members ........................................................................................ 305
12.2.4 Results Achieved ..................................................................................... 306
12.3 U.S. ARMY PMCMS ............................................................................................. 307

xv

LIST OF FIGURES
Figure 1-1 NATO Multi-National Environment.......................................................................3
Figure 1-2 Managing the Weapon System over Its Life-cycle ..................................................6
Figure 1-3 Representative Shared Data Environment ...............................................................7
Figure 1-4 NATO "Should Be" CALS DS Environment ..........................................................8
Figure 1-5 NATO CALS Four Stage Process .......................................................................... 11
Figure 3-1 Through Life Information Management Plan Steps .............................................. 24
Figure 3-2 Develop an Information Management Plan (IMP)................................................ 27
Figure 3-3 Strength of Benefits............................................................................................... 31
Figure 4-1 Implement a Shared Data Environment................................................................. 34
Figure 5-1 Manage the Information......................................................................................... 39
Figure 6-1 Weapon System Information Sharing .................................................................... 41
Figure 6-2 (Top Level Diagram) .............................................................................................. 45
Figure 6-3 (Diagram A0) ......................................................................................................... 48
Figure 6-4 (Diagram A1) ......................................................................................................... 50
Figure 6-5 (Diagram A12) ....................................................................................................... 51
Figure 6-6 (Diagram A13) ....................................................................................................... 53
Figure 6-7 (Diagram A133) ..................................................................................................... 54
Figure 6-8 (Diagram A136) ..................................................................................................... 55
Figure 6-9 (Diagram A2) ......................................................................................................... 56
Figure 6-10 (Diagram A21) ..................................................................................................... 58
Figure 6-11 (Diagram A3) ....................................................................................................... 59
Figure 6-12 Number of Interfaces without a Common Vocabulary........................................ 63
Figure 6-13 Number of Interfaces Using the NCDM as a Common Vocabulary ................... 63
Figure 6-14 Integrated Product Database Data Sources .......................................................... 65
Figure 6-15 Building an IT System Around the NCDM ......................................................... 67
Figure 6-16 Abstract view of NCDM...................................................................................... 69
Figure 6-17 Extended Abstract View of NCDM..................................................................... 70
Figure 6-18 The NCDM High Level Planning Model............................................................. 70
Figure 6-19 The Product Entities............................................................................................. 72
Figure 6-20 EXPRESS-G of product_structure ....................................................................... 73
Figure 6-21 Product structure presented as a tree.................................................................... 73
Figure 6-22 An Instance of a Product Structure ...................................................................... 74
Figure 6-23 EXPRESS-G of Breakdown................................................................................. 75
Figure 6-24 One Anomaly Caused by 2 Others ....................................................................... 78
Figure 6-25 Example of Failure Roll-up.................................................................................. 79
Figure 6-26 Task Method Sequence ........................................................................................ 81
Figure 6-27 ICOM Notations ................................................................................................... 84
Figure 6-28 General Form of Characteristic ............................................................................ 86
Figure 6-29 Characteristic Assignment ................................................................................... 87
Figure 7-1 Development Steps for Information Management Capability ............................... 92
Figure 7-2 Configuration Management Process Model - Overview........................................ 95
Figure 7-3 NATO CALS Data Architecture...........................................................................103
Figure 7-4 Recursive Approach ..............................................................................................112
Figure 7-5 NATO CALS Standardization Architecture .........................................................115
Figure 8-1 The CALS NCoO in the Contracting Process.......................................................166
Figure 8-2 NCoO Development Process.................................................................................169
Figure 8-3 Refinement............................................................................................................180
Figure 8-4 CITIS Implementation ..........................................................................................186
xvi

Figure 8-5 Acquire Defense System .......................................................................................210

Figure 8-6 LSA/LSAR Relationship.......................................................................................213
Figure 8-7 LSA Documentation..............................................................................................214
Figure 12-1 Crusader Home Page ...........................................................................................302
Figure 12-2 Crusader Integrated Data Environment Web Page .............................................303

xvii

LIST OF TABLES
Table 2-1 Cost Benefit Life-cycle Matrix................................................................................ 21
Table 2-2 Cost Benefit Risk Assessment................................................................................. 22
Table 3-1 Major System Life-cycle Phases and Information Management Activities............ 25
Table 3-2 IT Infrastructure Analysis ........................................................................................ 28
Table 3-3 Information Management Plan (IMP) Content ........................................................ 29
Table 7-1 Typical NATO and Contractor CM Roles and Responsibilities ............................. 98
Table 7-2 TLBM Version 4.0 Data Assemblies by DA Categories .......................................105
Table 8-1 Typical Data Type Deliverables .............................................................................169
Table 8-2 Data User Infrastructure and Capabilities ..............................................................172
Table 8-3 Data Users ...............................................................................................................175
Table 8-4 Data Types ..............................................................................................................176
Table 8-5 CITIS Decision Scorecard......................................................................................184
Table 8-6 CITIS Services and Functions - Supplemental Details ..........................................189
Table 8-7 Digital Data Deliverables .......................................................................................232
Table 8-8 Advantages and Disadvantages of Delivery Options .............................................242

xviii

1.0 INTRODUCTION
1.1 Background
1.1.1 Continuous Acquisition and Life -cycle Support
The United States Department of Defense launched the Continuous Acquisition and Lifecycle Support (CALS) initiative in 1985 to accelerate the use of digital product information in
acquiring and supporting defense systems.
So, what exactly is CALS? CALS is a joint government/ industry strategy focused on
reengineering existing business processes into highly automated and integrated defense
system life-cycle management process.
Life-cycle in this context covers concept,
design/develop, build, maintain, and dispose of a defense system (DS).
The purpose of CALS is to reduce defense system time to market, reduce total ownership
cost, and improve quality, across the life-cycle. Information Technology (IT) is an enabler
used to support the adoption and use of a shared data environment based on international
standards to manage the DS technical information. Embedded in the CALS philosophy is the
adoption of a rational approach to manage the production, access, management, maintenance
and distribution of digital technical information. This will enable more effective creation,
exchange, and use of defense system and equipment technical information over the life-cycle.
In this context, information is of vital importance and must be treated as a valuable asset.
The CALS strategy integrates information technology, business process re-engineering
(BPR), concurrent engineering (CE), multi-disciplinary work groups (MDG) and electronic
commerce/electronic data interchange (EC/EDI) to achieve very specific governmentindustry business objectives.
CALS addresses the total life-cycle of a DS. The Continuous Acquisition side of CALS
means optimizing customer-contractor processes during the concept, design/develop and
build phases. It is necessary to understand that these phases are continuous throughout the
life of the program because DSs last for up to 50 years and are constantly being modified due
to technology and emerging threats. Life-cycle support addresses the maintenance, repair,
and modification of DSs. Life-cycle support begins at the onset of the DS program where a
heavy emphasis is placed on the maintenance and in-service support processes during the
design and manufacture stages. Huge reductions in total ownership cost can be realized by
considering the maintenance and support processes at the onset of the program while they are
still malleable. Therefore, one of the primary business precepts of CALS is to make adequate
up-front investment to achieve long term savings for the end-customer while providing
operational excellence in the event of military operations.
1.1.2 The Challenge to Decision Makers
Throughout the world, information and communications technologies are generating a new
industrial revolution already as significant and extensive as those of the past. It is a
revolution based on information. Technological progress now enables us to process, store,
retrieve, and communicate information in whatever form it may take - oral, written, or visual
- unconstrained by distance, time and volume. This revolution adds huge new capabilities
and is a resource that is going to change the way we work together and the way we do

business together. Yet, nothing will happen automatically. The ability to participate, to
adapt, and to exploit the new technologies and the opportunities they create is the challenge
facing decision-makers both in Industry and Government. Those who fail to meet the
challenge, and make use of the opportunities presented, will not succeed in the changed
environment.
1.1.3 Industry Perspective
Individual Companies all over the world are investing heavily in Information Technology
(IT). They are applying Business Process Re-engineering (BPR) to refine internal process,
Concurrent Engineering (CE) practices to build multi-disciplinary teams, Electronic Data
Interchange (EDI) technology to exchange information in digital form. They make these
investments more or less independently, at each companys own pace and as its finances
permit. The motivation for each company is very straightforward - it is to optimize internal
efficiency, maximize profit, and maintain a competitive edge in the market.
Those
companies that make early investment in IT technologies will reap the greatest rewards. By
contrast, companies that temporize, or favor half-hearted solutions, could, face disastrous
declines in the market in a few years. Transition to digital processes and technologies is a
matter of survival in the industrial arena. For those manufacturing companies which supply
Defense systems to NATO and national MoD/DoD customers, the desire to improve
customer support, increase operational reliability, and to reduce costs is sometimes
challenged by the customers cultural and infrastructure weakness in dealing with new
technologies.
1.1.4 Military Perspective
The military has long perceived that advanced computer technology and telecommunications
capabilities could greatly reduce the lead times and costs associated with acquisition and
support of defense systems, while improving their quality. The paper flow between industry
and MoDs/DoDs today includes a massive volume of technical data: engineering drawings,
technical manuals illustrated part list, etc. Processes based on such paper documents are
error-prone, labor-intensive and do not provide the needed levels of operational readiness and
reliability. The necessity to migrate to lean and fast processes, based on digital data, is felt
with more and more urgency within the military, and MoD/DoD have started developing and
implementing their own organizations to address the problem.
1.1.5 The Multi-National Program Perspective
Multi national defense system programs operate in an environment of extra-ordinary
complexity. This is illustrated below:

NATO MULTI-NATIONAL INFRASTRUCTURE

N
A
T
O
M
I
S
S
I
O
N
S

BE
CA
DK
FR
GE
GR
IC
IT
LU
NL
NO
PO
SP
TU
UK
US

M
O
D

Supplier

Air Force
Navy

M
O
D

Army

PROJECT

P
R
I
M
E

M
O
D

C
O
N
T
R
A
C
T
O
R

Sub
Contr

Supplier

Supplier

Supplier

Supplier
Sub
Contr

Supplier

THROUGH-LIFE
INFORMATION MANAGEMENT

SHARED DATA ENVIRONMENT

Figure 1-1 NATO Multi-National Environment

On the government side of a defense system, separate national offices, within contributing
nations typically support an international project office, which manages the relationship with
industry. The defense system itself is likely to be operated by several Armed forces, of
different nationality, each with their own logistic infrastructures.
Within the NATO
structure, relations may have to be established with the NATO Maintenance and Supply
Agency (NAMSA), the NATO Command, Control and Communication Agency (NC3A), the
International Staff, the International Military Staff and the NATO Military Commanders.
The System may also be deployed as part of a Multi-National Combined Joint Task Force, ot
operate anywhere in the world, with forces from non-NATO countries.
On the industrial side, the program is likely to be supported by one or more prime
contractors, formed by parent companies, often from different nations.
These Prime
Contractors will have to communicate with an extended chain of sub-contractors and
suppliers, many of which will be supplying the same or similar equipment to other Armed
Forces and to commercial customers.
Many of the business processes necessary to acquire and support the defense system require
the sharing or exchange of data across this extensive supply chain. Data created by a supplier
early in the project life-cycle may be needed by the operational unit, at a different location,
many years later. Making information easily available, at least cost over the life-cycle, to all
that require it, presents a significant management challenge. As the quality and timeliness of
program decisions depends on the quality of the underlying data, action to improve
information is likely to yield direct and immediate improvements in the quality of the
program itself.
1.1.6 NATO Perspective
From the NATO perspective the question to address is whether this will be a strategic
creation for the whole Organization, or a more fragmented and much less effective amalgam
of individual initiatives by member nations. NATO also recognizes that it no longer makes
sense for defense systems and equipment to be designed, manufactured, and operated by a
3

single nation. It is extremely expensive to manufacture and maintain these complex systems
in isolation. There is a need for intense cooperation and extensive multinational information
exchange throughout the customer, prime contractor, and sub contractors, supplier chain.
The CNAD, the NATO decision makers in the field of armaments, gave a clear signal of their
commitment to exploit CALS new technologies by establishing the NATO CALS
Organization in 1994.
1.1.7 NATO CALS
In 1989, the Conference of National Armaments Directors (CNAD) took the lead on all
NATO CALS issues by establishing a CALS working group under Allied Committee 301
(Standardization of Material and Engineering Practices) subgroup D. In 1993, the CNAD
endorsed the creation of the NATO CALS Organization responsible for the overall direction
of al CALS activities within NATO. The NATO CALS objective is to improve readiness,
increase quality, shorten time to market, and reduce total life-cycle costs.
NATO CALS is a co-operative activity, funded by 11 of the 19 NATO Nations, to improve
NATOs ability to exploit information and communications technology, in the acquisition
and life-cycle support of complex DSs. The NATO CALS Mission is:
1. To: increase interoperability, decrease defense equipment life-cycle costs, ensure the
readiness of NATO forces and decrease acquisition lead times,
2. By: facilitating continuous improvement of business processes,
3. Through: the use of international standards and practices, application of advanced
tools and technologies, and increased co-operation with industry,
4. Thereby: creating an opportunity for NATO industry to enhance its global
competitiveness.
NATO CALS has three main components:
1. The NATO CALS Management Board (NCMB) which meets 3 times per year, to
control the work program Strategic Plan. The NCMB is comprised of senior level
national representatives tasked to provide and maintain the NATO CALS Strategy,
Goals, and Objectives needed to meet the CNAD mission for CALS. This mission is
executed by the NATO CALS Office .
2. The NATO CALS Office (NCO) was established in 1994, under the leadership of the
NCMB, to implement CALS within NATO. The NCO has a -full-time staff located at
NATO Headquarters. The NCO consists of nine national CALS experts from BE, FR,
GE, IT, NO, SP, TU, UK and US with DK and NL contributing financially. Hungary,
Poland, Finland, and Sweden collaborate with the NCO and, the NCO has extensive
contacts within NATO, nations, and industry.
3. And the NATO Industrial CALS Group (NICG) who provide industrial advice and
assistance.
The NCO, with extensive industrial participation provided through the NATO Industrial
Advisory Group (NIAG), began its work by sponsoring a series of studies, workshops, and
development projects. A major outcome of these efforts was the development of the NATO
CALS Policy and Strategy.

The Strategic Plan offers both a short term and long term approach. The short-term approach
encourages the maximum use of available commercial tools across the government/industry
boundary for new NATO DS programs. The long-term approach proposes the development
of new information standards for product life-cycle support data to improve the ability to
share technical data across the whole DS environment.
A more detailed discussion of NATO CALS is included in Appendix A.
1.1.7.1 Going Digital Now
NATO CALS advocates going digital now (e.g., get out of paper), by using COTS and
industry solutions, and by adopting international standards where possible. Programs should
also adopt a through life management (TLM) approach to program management and view
information as an asset utilizing a through life information management (TLIM) philosophy
implemented through a Shared Data Environment.
1.1.7.1.1 Through Life Management
Through Life Management (TLM) is a business strategy for optimizing the overall success of
a program by focusing on the life-cycle return for major DS programs. Return in this
instance can be measured in many different ways, e.g., reduced time to market, reduced
acquisition cost, reduced support cost, improved performance, improved maintenance
turnaround time etc. The objective here is to make it faster, better and cheaper.
1.1.7.1.2 Through Life Information Management
TLIM focuses on how to define and communicate the technical information needed by users
to acquire, plan and execute support for complex, long life defense assets. Because products
are growing more complex, it is becoming ever more difficult to keep the technical
information required for maintenance in line with the changing product. The volume of
information needed to conduct maintenance is also growing. This information is created at
the beginning of the DS life-cycle and needs to be managed across the life-cycle,
e.g., Configuration data, diagnostic data, failure modes, connection diagrams, assembly
drawings, special tools and test equipment data, spares details, test requirements, etc. The
absence of any of this information may stop the work in progress. Improved feedback is also
needed to track maintenance costs and eliminate the causes of downtime. (Depicted in
Figure 1 -2)

Business Processes
Design/Develop
Acquire
Maintain
User
Feedback

Archive
Archive
Data
Data

Dispose

SATISFY
The Shared Data Environment

Supply Chain
Support
Management
Engineering
Core Product Data

Concepts & Referencing

CM/Change
Control

Maintenance

Managing
The
Weapon System
Over Its
Lifecycle
CALS
CALS OBJECTIVES
OBJECTIVES
Improve
Interoperability
Interoperability
Lower Life
Life Cycle
Cycle Costs
Costs
Reduce Acquisition
Lead
Lead Time
Time
Ensure NATO
Weapons System
Readiness
Improve Quality
Quality

Business
Business Processes
Processes Linked to Through Life Information Management (The
Shared Data Environment and International Standards) Operating in an
Electronic Environment Satisfy the NATO CALS Objectives

Figure 1-2 Managing the Weapon System over Its Life -cycle
1.1.7.1.3 Shared Data Environment
The DS Program Shared Data Environment (SDE) will help programs establish the
foundation for the new ways of working. Ideally, it will provide an information infrastructure
which supports digital communication and allows data to be controlled, accessed, and shared
electronically between all industrial and governmental participants through-out a programs
lifetime. To achieve this, the Program SDE must operate with, and may indeed be part of, a
wider national or NATO infrastructure for defense system logistic support.
In practice, it is neither sensible nor cost effective for NATO to develop a single, integrated
system to meet the needs of all parties associated with a DS over its life-cycle. NATO CALS
has developed a strategy to improve the capability to share information across the Alliance by
encouraging new programs to develop program SDEs that can bridge the
government/industry based on the latest commercial software. A Program SDE should cover
the widest possible range of functions, and the largest number of participants that the
Program can afford to connect. SDEs will vary from Program to Program. Integration with
the existing logistic systems and with the rest of the supply chain will be achieved
progressively, partly by tailored interfaces, and partly by the progressive development of new
information standards. Initially, these standards will address the requirements of product lifecycle support.
The Program SDE must be available at all stages of the life-cycle. During development,
multi-disciplinary groups use the SDE to accelerate and improve the design and development
processes. In operations, the SDE provides rapid controlled access to the defense system
technical information needed to ensure combat readiness. The Program SDE also helps DS

support managers maximize availability and reduce support costs by providing the necessary
operating history and feedback for in-service maintenance and support.
The SDE should be established at the beginning of the program, be accessible to all
participants, and evolve continuously through the life-cycle to exploit the latest IT deemed to
be of value. In a multi-national environment such as NATO, turning this SDE vision into
reality presents some significant problems, in particular, at the boundaries between
government and industry, and between the many logistic infrastructure systems that support
national and NATO operations.
CRITICAL DS
INFORMATION
REQUIREMENTS

Government

SDE Data Architecture

Industry

LOGISTICS

NATO Forces
Data Access

PERSONNEL
COMMON SUPPORT APPS

FINANCE

Data & Object

Management

INFRASTRUCTURE SERVICES

CONFIGURATION
MANAGEMENT

KERNEL

Security System
Management
Database

ACQUISITION
DRAWINGS
(CAD/CAM)
HISTORICAL
FILES

Figure 1-3 Representative Shared Data Environment

1.2 Managing the Life -cycle Process
Exhaustive studies conclude that the cost of defense system (DS) ownership typically exceeds
that of system acquisition by two or three times. Furthermore, the biggest potential to impact
life-cycle savings occurs at the beginning of the DS program when the design, manufacture
and support concepts are flexible. Put another way,, there is a narrow window of opportunity
to influence life-cycle cost that diminishes rapidly over time. This creates a powerful
incentive to address life-cycle issues at the earliest possible point in the DS life-cycle. Lifecycle information management is a critical element in this formula because most of the
information needed to sustain the system throughout its life is created during
design/development. Moreover, the quality and availability of the technical information has a
profound impact on the systems performance and life-cycle cost.
1.2.1 NATO CALS Environment
The NATO CALS Environment was first described during a business process re-engineering
analysis conducted during the NATO CALS Acquisition Workshop in 1994. The participants
in the workshop developed a view of how a program that had taken full advantage of CALS
would operate over its life-cycle. This vision was further developed by the NATO CALS

FRAMEWORK project. The vision is presented in more detail in the NATO CALS Through
Life Business Model (TLBM).
In the NATO Should Be CALS DS Environment (Figure 1-4), certain key functions must
be managed consistently over the life-cycle. If a through life perspective is not adopted at the
outset, then the myriad of system changes that iterate across the life-cycle process become
impossible to manage. However, if a life-cycle management approach is applied from the
outset, significant cost savings and major quality improvements can be achieved. These in
part result from minimizing the errors, delays, and disruptions occurring at organizational
boundaries and at major transition points. A good example of this is system hand over which
transpires between the acquisition project office and the operational service.

System Life Cycle Processes

in the Should Be CALS Environment
Life Cycle Management Functions
Manage
Project

Manage
Inform. Services

Manage
Quality Assurance

Manage
Configuration

Continuous Processes
Programmatic Development /Deployment Disciplines
Need Definition
and Analysis

Feasibility
Study

System
Definition

Design and
Development

Production

Deployment

Operation /
Support

Disposal

Multidisciplinary Development Teams

Technology / Tools
Data Management
Security

SHARED DATA ENVIRONMENT

Workflow
Standards

Figure 1-4 NATO "Should Be" CALS DS Environment

The pressure for NATO to adopt consistent life-cycle management practices is being driven
by several important factors. These include the increasing complexity of DSs, the growing
industrial involvement in DS support, the increasing use of international Combined Joint
Task Forces, Co-operative Logistic initiatives, and the increasing reliance upon digital
environments.
Strongly associated with improved program management practices is a life-cycle approach to
managing the DS technical information.
This includes requirement management,
configuration management, quality assurance, and information management.

1.2.2 Program Management Issues

1.2.2.1 Relationship Management
Establishing who will own, operate, and manage the DS over its life-cycle is essential. This
is usually defined by contract. Management of any transition responsibility procedures must
be developed for both the system and its support. Ownership and control of the DS Shared
Data Environment (SDE) and the information it contains, are also critical life-cycle issues.
1.2.2.2 Continuous Review and Approval
The current acquisition process, as presented in the NATO Phased Armament Procurement
System (PAPS), relies on a strict sequence of project phases, separated by major reviews.
This procedure does not support modern practices being used within industry. Implementing
an electronic SDE allows immediate controlled access to information. This concept provides
an opportunity to reduce development time and costs significantly by adopting a strategy of
continuous review and approval, in an overlapping sequence of events. For example, the
maintenance and support processes can be developed concurrently with the design and
development activities of the DS. Furthermore, strict reliance on phased reviews becomes
impractical when product functionality is geographically dispersed and delivered
incrementally as part of concurrent engineering activities performed by multi-disciplinary
work groups (MDG).
The CALS concept changes the conditions applicable to DS programs. External controls are
defined when the approval to proceed with the program is granted. The validity of DS
program requirements is continuously validated and sustained using continuous review and
approval practices. This constant monitoring enables any actual or forecast deviation from
requirements to be detected and reported immediately.
The work continues without
interruption unless critical predetermined conditions are breached. This improved program
visibility, provided by the SDE, supports continuous monitoring and enables additional
external reviews to be conducted at any time, ether at specified intervals, or on demand. This
iterative approach renders the strictly serial phased review obsolete.
1.2.2.3 Contract Management
The terms of the acquisition contract(s) have a major impact on the DS system across its lifecycle. Before acquisition contracts are placed, careful thought needs to be given as to how
they will end and what arrangements will follow. For example, the role of the prime
contractor, in ongoing support and operations, deserves close attention because it will have a
major impact on the information required by the government and the approach taken to the
SDE.
1.2.2.4 Financial Management
The key change within financial management is the requirement to give much greater
attention to the DS life-cycle cost. Credible life-cycle cost models must be established from
the program outset. The DS program manager must confirm affordability, and provide a
framework for rational decisions such as the scale of the Integrated Logistics Support (ILS)
program and the level of expenditure on the proposed SDE. Close attention must also be paid
to measuring in-service costs, for comparison with early predictions, as a guide to managing
upgrades and reliability improvement initiatives. Short-term budget pressures will inevitably

play their part, but a rational DS life-cycle management approach is impossible without a
view of the total DS life-cycle cost.
1.2.3 Technical Information Management Issues
1.2.3.1 Requirement Management
The requirement for the DS starts with the statement of mission need. This drives all of the
life-cycle processes. From the outset, the requirement statement should be written in a form
that facilitates a continuous through life comparison of actual to specified performance.
Other elements that need to be included in the requirement are DS capability, availability, and
cost. These also need to be stated in a manner that facilitates the comparison between actual
and specified performance.
The requirement should be maintained in a current and
authorized form, over the whole life-cycle, which is readily available to all program
participants needing to check their performance. This process can be facilitated through the
implementation and use of a shared data environment (SDE).
1.2.3.2 Configuration Management
Product identification and configuration control is essential to product control and logistics
operations, and must be managed through life. Configuration Management (CM) must begin
by establishing control of the requirement statement. CM must be applied to the DS contract
documentation, design, manufacture, product use, technical information, and the support
equipment needed to operate and maintain the product in service.
A Shared Data Environment, incorporating an electronic CM module, makes it much easier
to apply CM by providing a central authoritative source of secure and integrated data directly
associated with the end item. This makes system changes easier and cheaper to manage and
maintain; thus, significantly reducing DS life-cycle costs. (If I know what it is, I know what
to buy, and how to support it).
1.2.3.3 Quality Assurance
In the Should be CALS Environment (Figure 1-4), quality assurance is achieved primarily
through self regulating processes, in which the people responsible for doing the work have
access to the information they need to assess their own performance. The SDE not only
makes this possible, but also makes it easy to achieve, and the approach is entirely consistent
with the use of Concurrent Engineering.
In cases like DS safety, where external inspect or audit is still required, the SDE adds value
by providing a consistent mechanism for recording and storing quality assurance records,
linked by identifier, to the appropriate part. The Should Be CALS Environment improves
quality directly by providing maintainers and operators with ready access to design or
manufacturing data, which is relevant to the product in their hand. The quality of in-service
feedback is improved by capturing information automatically, as work is done, rather than the
error prone process of filling in forms after the event.
1.2.3.4 Information Management
The NATO CALS goal of electronic DS life-cycle information management is to ensure the
accuracy, integrity, and availability of the DS technical information throughout its life.
10

Managing information in an SDE, with multiple users, requires significant planning and
control.
Security, property rights, controlled user access, system administration and
information quality control is as complex as the configuration management and control of the
product itself. In the NATO CALS Environment, the Information Management activity is
very complex. DS technical information crosses enterprise and national boundaries, and
involves several heterogeneous infrastructures.
The informations form and
inter-relationships is also very complex and must be preserved as the information is created,
accessed, shared, transported, and delivered to the end user. For these reasons, in the NATO
CALS Environment, information is treated as an asset, to be managed over the DS life-cycle.
1.2.4 The Staged Process for Through Life Information Management
TLIM encompasses several basic steps, or activities, that should be conducted in conjunction
with the program and systems development life-cycle to yield the maximum benefit. At a
high level the activities are:
1. Determine the targets for the program and develop a Program Strategy;
2. Determine through life data and Information Technology (IT) requirements and
develop an Information Management Plan (IMP) that supports the Program Strategy;
3. Contract for and implement shared data capabilities based upon the Information
Management Plan;
4. Manage the information based upon the terms in the contract.
The four-stage process is illustrated in Figure 1-5:

Management
Vision

Develop Program
Strategy for
CALS

Program
Strategy
for CALS
Develop
Through-Life
Data and IT
Requirements

CALS Information
Management Plan
Implement
Shared Data
Capabilities

Shared Data
Environment

Manage
Information

Archive
Data

User Feedback

Figure 1 -5 NATO CALS Four Stage Process

The practical application of TLIM is likely to require repeated iteration between these various
phases as a growing understanding of the issues allows the approach to be refined.

11

1.3 Purpose of the NATO CALS Handbook

This handbook is a guide for program managers interested in implementing the NATO CALS
concepts of TLM and TLIM within a DS program. A major goal of this handbook is to help
the DS Information Manager accomplish the following objectives:

Develop a Through Life Information Management Strategy (a program strategy for

CALS)
Develop a Through Life Information Management Plan (IMP)
Implement a Shared Data Environment (SDE)
Manage the Information Through Life

12

2.0 STAGE 1: DEVELOPING A THROUGH LIFE INFORMATION

MANAGEMENT STRATEGY
Once the decision has been taken to explore shared data, the program will need to develop a
Through Life Information Management (TLIM) Strategy. The process for achieving this is
shown in Figure 1-5. Throughout this staged process all investment of resources must be
driven by, and add value to, the business goals of the program.
The first task in the development of the TLIM Strategy is to translate the management vision
of how the digital environment can bring benefit, into specific, measurable improvement
objectives for the program over its life-cycle. This should be followed by a careful
examination of the business and IT environment in which the program will operate, and an
assessment of the options for adding value from an SDE. Alternative options are then
examined in relation to their ability to contribute to achievement of business goals, using
cost/benefit and risk management techniques.
The output from Stage 1 is a decision on which Through Life Information Management
improvement opportunities the specific program should adopt, and an outline concept of the
Program SDE.
These activities should be undertaken in parallel, with progressive
improvement of earlier analysis based on findings from subsequent work.
2.1 Develop Improvement Targets
No single program can realistically hope to pursue all of the possible improvement
opportunities arising from modern IT. The selection of improvement targets, expressed in
quantifiable and measurable terms, is the first key milestone in the NATO CALS Handbook
process.
Some programs will already have a clear management vision of those aspects of performance
they most wish to improve. This vision should direct their CALS activities. For others,
development of this vision and identification of the improvement targets will require a wider
analysis of options and the CALS environment, before selecting and quantifying targets.
Improvement targets should be expressed in simple, plain language that all program team
members understand. Examples might include:

Cut development time scale from release of Staff Target to first operational use by
30% from last similar project.
Reduce cost of providing technical information needed to conduct level 1 and 2
maintenance by 40%, from the average of the last four programs.
Reduce the number of QA deficiencies, found on final inspection to less than one a
week.

Opportunities for improvement are numerous. A limited listing of improvement targets and
opportunities, based on current best practice, is presented below. These are described in a
generic form, and are intended to act as a starting point for selecting the specific
improvement target that the DS program will seek to pursue. Ideally, selection of targets
should be based on a full analysis of through life cost, risks and benefit applicable to the
program in question. In practice, some intuitive judgment will be needed to select a limited
range of options for analysis in further detail.
13

Likely areas for improvement include:

Faster, cheaper development through improved communications and decision support.

Reduced through-life costs through improved Configuration Management
Optimization of Maintenance Time, Cost and Quality
Just-In-Time Access and Delivery of Technical Information
Improved feedback of in-service experience.
Real Time Access to NATO/Multi-national Logistic Information

2.2 Analyze Environment and Options

Selection of improvement opportunities, and the design of the program SDE, are major
decisions that will effect defense system cost and performance over the whole life-cycle.
This section explains how to analyze the business and information technology options, to
provide a background for rational choices.
2.2.1 Business Environment and Options
To develop a DS program "Through Life Information Management Strategy," it is necessary
to understand and document those aspects of the program business environment that have
relevance to information management. It is hoped that most of the necessary information will
already have been identified and documented in existing strategies and plans.
2.2.1.1 External Environment
The business environment analysis starts by exploring the requirements and constraints
placed on the program by external authorities, which the Program Manager is unable to
change. Examples may include the requirements derived from the Validated Mission Need
(e.g., required capability and availability), current policies, decisions already taken, and the
requirement for international co-operation. This analysis establishes the boundaries within
which improvements are possible.
2.2.1.2 DS Program Process Improvement Tool
After addressing the external environment, attention can then be focused on the opportunities
for process improvement within the program itself. A Through Life Business Model (TLBM)
provides a useful tool for describing and understanding the defense system program
environment. The TLBM can be used to investigate alternative approaches:

To structuring and managing program activities;

To the extent of contractor support and the roles and responsibilities of contractors,
during and after acquisition;
To the relationship, and split of work between the defense system project and the
Armed Forces who will operate and may support the system;
To the information requirements and flows that need to be managed over the lifecycle.

14

A generic defense system TLBM has been developed by NATO CALS to illustrate the
improved business processes for through life management, enabled by a Shared Data
Environment. (See Chapter 6)
2.2.1.3 DS Program Process Improvement Tool Tailoring
The NATO CALS TLBM defines a new approach to defense system management, showing
how integrated product and support data contained in one single source could improve the
process for acquiring, operating, supporting, and disposing of a defense system. It reflects
many new ideas and improved ways of working, not all of which will be achievable on any
single program. By tailoring this model to reflect the specific program, it is possible to
explore and to illustrate how the digital environment can be exploited on the program in
question.
Tailoring the NATO TLBM should be based on:

The actual business environment in which the program will operate.

Specific opportunities for improvement that the program wishes to explore.

By studying each activity box in the generic TLBM, it is possible to understand whether
particular activities apply to the program in question, who is likely to perform them, and what
improvements might be possible from an SDE. The use of a TLBM will also function as a
question generator to identify issues deserving attention within the CALS Strategy and for
the rest of the program. The NATO CALS TLBM is a guide, not a standard. Each Program
Manager must decide which improvements to implement, and how to apply them in his
context.
This tailoring and analysis process will also be of benefit to programs buying an existing
system, whether military or commercial-off-the-shelf (COTS). The use of a TLBM will help
clarify the strategy for supporting the system through life, the level of dependence on the
intended supplier over the life-cycle and the opportunities for exploiting IT.
DS Program Analysis Key Questions
The TLBM should be used to analyze, in sufficient detail, the nature of the information
required to support the intended way of working. The following are examples of questions
that the model may help to resolve:
Program Management (See Chapter 6)
How will key resources (money, people, and information) be managed?
What are the roles, responsibilities of the many participants who will perform the
various activities over the life-cycle?
How might these change over time? How will such changes be managed?
How are requirements kept current over the life-cycle?
What kind of incentive arrangements would be most appropriate between the
government and industrial prime contractor?
What teaming concepts are to be used?
How will program changes be managed?
How will the program be controlled?
Quality Assurance (See Chapter 6)
15

How will baseline requirements be captured and managed?

How will in-service effectiveness and feedback be managed?
How will reliable historic records be maintained over the life-cycle?

Information Management (See Chapter 6)

What information is to be managed?
What form is it to be in?
Who owns/manages/uses the information?
What information should be shared, exchanged or integrated?
Configuration Management (See Chapter 6)
How will product change be controlled (and linked to changes to the support)?
How will changes to the product be related to requirements?
How will (required/actual) product configurations be identified?
How will current configuration data be provided to those who need it?
How will configuration anomalie s be reported and resolved?
Concurrent Engineering (See Chapter 6)
What engineering methodology will be used (e.g., waterfall, spiral)?
How will technical information be defined and kept current with product
information?
How will Integrated Logistics Support be implemented?
Multi-Disciplinary Work Groups (See Chapter 6)
How are skills and resources from different organizations brought together to
solve problems efficiently by joint inter-active working (physically/face to face
meetings/virtual environment through SDE)/who will be the members?
2.2.1.4 DS Program Forecasting
During the early stages of the program life-cycle, it is difficult to forecast the long-term DS
future with confidence. However, it is important from the program outset to consider the
whole life-cycle. Failure to do so will close off or greatly increase the cost of significant
future options for sustaining the defense system efficiently over the rest of its life. Nowhere
is this more important than with defense system product information. In this area, there are
huge opportunities for reducing life-cycle costs, by taking sensible and low -cost precautions
from the program outset. This will ensure that later in the life-cycle, defense system support
managers have the flexibility needed to manage their business efficiently in the face of a
changing environment (e.g., the opportunity to re-compete for particular goods and services).
A final output from the business environment analysis should be the identification of options
for future improvements or changes in responsibility that the program needs to protect.
A summary of the information that needs to be recorded (or referenced) from the Business
Environment analysis that lists the expected contents of the Program Strategy for CALS is
presented below:
2.2.1.5 Content of Program Strategy for TLIM
Management Vision for exploiting the digital environment:

16

Brief description of desired future working style

Evidence of top management commitment

Selected improvement Targets:

Specific Business Improvements that CALS is required to deliver on this program:
Intended metrics and method of measurement.
Description of the Program Business Environment and Options:
Program goals and priorities.
Project policies, decisions taken, and time scale
Roles and Relationships through life:
PMO and Prime Contractor
PMO and Operational and Support agencies
Industry involvement through life
Multinational bodies NAMSA, Co-operative Logistic Initiatives
Intentions for in-service Support: extent of contractor involvement.
Management of Updates
Competition vs. co-operation
IPR
Warrantees and Incentive mechanisms
Options to be maintained
Agreed description of the DS life-cycle, presented as a TLBM
Issues requiring attention in NCOPS Stage 2
IT Environment Assessment
Extent of digital working
Relevant legacy systems
Relevant IT trends
IT policies and plans
experience of other programs
available software tools (now and future).
SDE Options for the Program
(Consider 3 options - maximum, best, minimum)
Extent of SDE,
Expected Capabilities,
Who will have access
Boundaries and Interfaces
Ownership
Control
Impact on Processes
Impact on People
Evolution over time
Assessment of Options: Costs, Benefits, and Risks
Program life-cycle cost model (need to assess options)
Value added by target improvements

17

Costs of SDE (do not forget people, software, maintenance, etc )

Risks: Technical, Cultural, process Change etc. How much change can we
manage?
Evolution vs. revolution
Outline risk management plan

Program Intentions for CALS (Decisions)

Intentions for digital working
SDE options for further development
Intangible Benefits
Top program management is aware of the opportunities presented by digital
data
Everyone in the program knows what is intended for CALS, and what it is
expected to deliver
Program staff begin to understand life-cycle management
Program staff starts to view information as an asset, to be manage over time.
2.2.2 IT Environment and Options
The second activity within Stage 1 is an assessment of the external CALS environment,
relevant to the particular program. This should include consideration of:

Relevant legacy systems industry, government, Armed Forces

Relevant IT trends
Government IT policies and plans
Recent experience of other programs
Available software tools, now and in the future.

An area of particular importance is the existing and planned DS program Information

Technology (IT) capabilities for both governmental and industrial partners. Even though
these change over time and are moving targets, when developing a CALS Strategy for a
specific program the following key areas should be assessed:

Availability of terminals, now and in future

Level of experience with digital working
Telecommunications capabilities
Interoperability requirements
Current and proposed future standards
Security
Legal/contractual aspects
Intellectual Property Rights (IPR)

This analysis, enhanced by the business analysis, may be used to develop a steadily
improving picture of the intended extent of digital working to be applied to the program.
This, in turn, begins to define a set of options for the scale, extent, and capability of the
Shared Data Environment that the program will seek to deploy. Areas to be addressed
include, but are not limit to the following:

18

What information is required, by whom and when over the life-cycle?

What will they do with it?
How much of the data will be generated, accessed and manipulated in digital form?
To what degree will business still be conducted on paper?
To what extent does an SDE already exist for the program?
What are the options for improving or extending this?
Who will have controlled access to the new SDE?
Who owns and operates the SDE, during the acquisition phase and subsequently?
How will the SDE be financed?
How will the SDE be managed?

Specific attention should be given to the boundaries of the SDE. Complete and free access to
program data, as assumed by the TLBM, is some years away from reality due to industry
proprietary, data and security issues. In practice, no single program SDE will encompass all
of the program participants. Limitations must be set on the extent of shared information
access. Every boundary drawn for the SDE will create a border across which information
will need to be exchanged. DS Program SDE chosen boundaries determine the information
exchange requirements with the rest of the world.
In exploring the CALS environment, and the possible SDE options, particular attention
should be paid to the recent experience of other relevant programs. The NATO CALS Office
provides a natural focal point for such learning through its attendance at international
conferences and contacts with participating nations. The Internet is also a valuable CALS
information source through the various home pages maintained by the national CALS offices.
Several relevant periodicals and other publications are also starting to appear, some free of
charge.
Although these documentary sources are of significant value, programs developing a CALS
Strategy are encouraged to visit other program offices and/or industrial sites that have recent
relevant experience.
The contractual aspects of alternatives developed through analysis and tailoring of the TLBM
and the CALS Environment for the program should be considered at the earliest possible time
given the complexities of international contracting and through life support of NATO/Multinational armament programs. A more complete discussion of contracting issues is covered in
Chapters 4 and 10.
2.3 Analyze Cost and Benefits
Defense Program Managers are under enormous pressure to reduce program costs. They are
also expected, at the same time, to raise productivity and product quality by improving
business processes. The Information Technology (IT) revolution offers a significant potential
for improvement. However, demonstrating the potential gains is difficult for several reasons:

The cost of current activities is often poorly understood, or not available,

There is limited experience with advanced technology, and,
In the past, many programs made significant progress through CALS, but did not
formally document their improvements or their costs.

19

Fortunately, the IT revolution is now sufficiently mature to provide many examples of

worldwide successful implementations in the defense industry and beyond. As a result, it is
now possible to develop a realistic business case for specific CALS investments based on
practical experience.
By far, the most important criteria for pursuing the implementation of the CALS
Environment are the tangible benefits derived from the investment required to implement and
use it. Many of these benefits are not realized in the beginning of a program and are accrued
over the DS life-cycle. The risks associated with the CALS Environment must also be
considered on a through life basis and mitigated through appropriate risk management. There
is no standard prescriptive model for predicting the costs, benefits and risk management for
the application of a CALS Environment to a NATO/Multi-national program due to the
uniqueness of each program and the IT Infrastructures available for the program.
Tables 2-1 and 2-2 provide an overview on the general categories of cost, benefits, and risks
associated with the application of the CALS Environment and concepts to a program.
Further specific details are provided in Appendix H, List of Possible CALS Improvement
Targets.
The tailoring of the TLBM and the application of the CALS environment to the program
needs will be based on what is available and affordable and, therefore, on the results of the
Cost and Benefit analyzes for the program. The method of measuring and confirming the
required improvements should also be addressed. With suitable planning, the SDE itself can
be used to collect the data needed by the assessment criteria by capturing the actual program
costs and performance improvements on an ongoing basis. This information may be used to
modify the CALS Environment over the life-cycle and to justify any subsequent investment
required for further improvement. Such data would also provide valuable feedback to NATO
and the nations by contributing to the growing pool of knowledge.

20

Table 2-1 Cost Benefit Life -cycle Matrix

COST BENEFIT LIFE CYCLE MATRIX
Feasibility

Define/Design/test
(tested sol ution)

Production
(products,
processes and services)

Deployment

Operations

Disposal

Concurrent Eng/ILS

+ Need more people

+ Need more people

0 Same amount of work

Shared
Environment

- Electronic form and digital

data (if it exists) saves money
here

- Information sharing

- Supplier Chain management,

production driven by digital
data

Program
Management (PM)

- Phase review and approval

compression in new CALS PM
acquisition environment saves
time, people and money

- Phase review and approval

compression in new CALS PM
acquisition environment saves
time, people and money

- Data maintenance/mgt is
"immediate,"
technical
workers are alleviated from
being knowledge clerks
0

Multi-Disciplinary
Groups (acquisition)

+ More people, more difficult

to manage

Phase review and

approval compression in
new
CALS
PM
acquisition environment
saves time, people and
money
- Solution sooner

- Data is digital and on

time (JIT?) integrated for
use, maintenance and
training. Requirements
0

- Disposal is engineered
into technical solution
+
Easier and more
accurate
identification
of data holdings for
disposal
0

Produceability inherent in
design

Quality
(QA)

0 Quality is built in
from start, so fewer
design
changes,
no
savings from QA yet

- Meets requirements, testable

and fewer rejects/failures

- It works as specified,
more frequently

0
Start CM is a CE
environment but not much gain

+ Started earlier, MDG

in
control,
baseline
management is more
complex

0
Shop floor not impacted
positively or negatively but
integrated CM

- Integrated incremental
rollout

Meets
specified
supportability requirements,
and
operability
requirements.
more
frequently
Manage configuration
items for improved support
and change mgt.

Data

Assurance

Configuration
Management (CM)

21

+ An MDG for disposal

would have to be
formed
0 No additional savings
identified
against
continuous QA

- Find disposable items

and corresponding data
easier

Table 2-2 Cost Benefit Risk Assessment

Objectives
SDE

MDT

CM

PM

Risks (of doing CALS)

Electronic form
Timeliness
Transaction cost
Electronic processing, exchange and storing

System security
Legacy data
Systems incompatibility
Communications capability

A fully integrated technical solution

Sooner, reduced cost, higher quality

Baseline control
Fleet management
Engineering change
Real-time configuration control

Vastly improved product management throughout the lifecycle

Takes longer
Costs more
Culture change does not happen (internal
MDT comms. and PM)
Location
Volatility of changes and baseline,
complexity of new systems
(incremental functional delivery)

CE Supportability
(ILS) War fighting capability

QA

Benefits

Version Control
Accessibility
Quality
Data management

Initial investment
prod=0
JIT - Maintenance, Training, Ops plus IP and
supportability (Delivery?)
Ops: Reliability, maintainability and operability
= war fighting capability and reduced cost of
infrastructure
Continuous
quality
measurement,
cost/performance trade-offs

Schedule compliance, cost compliance, quality,

CDRL approval/reviews

Risk Management
Security is still and issue - manage it: firewalls,
encryption, minimize conversion, standardize
data formats (esp. new data)
Initial cost of integration and information
architecture w/sustaining cost
Flexible communications strategy allowing for
technological upgrades
Schedule management
Cost management
Team training/team building
Collocation
SDE, change management, change tracking from
common
database
managing
end
item
relationships

Dependency with ILS

Initial investment does not achieve cost
results,
diminished
war
fighting
capability

MDT ILS/CM integration

Information engineering done at same time of
h/w and s/w engineering in a SDE using multidisciplinary groups

Fewer rejects/failures and therefore less rework costs

CALS got it there sooner for it to fail

more frequently
Spent more time/money and people and
did not achieve expected quality payoff

QA/PM dependency for requirements tracking

and management. PM responsible for pulling it
all together

Accelerated, incremental approvals

Empowered MDGs and contractual

aspects too complex to manage

PM representation on MDTs and management

training

Reduced defects
Incremental delivery
Improved:

change management

maintainability

reliability

supportability

operability

22

2.4 De cide Through Life Information Management Strategy

Once the various cost, benefit and risk analyzes have been conducted for each of the alternative
business and IT solutions, the Program Manager can complete the Through Life Information
Management Strategy by defining the program intentions for using digital data. The contents of
the TLIM Strategy are defined in Section 2.2.1.6, Content of a Program Strategy for TLIM,
and summarized briefly below:

Program Management Vision

Improvement targets for the program and assessment metrics
Business Environment and Options
IT Environment Assessment and SDE Capabilities and Options
Cost and Benefit Analysis
Risk Assessment and outline Risk Management Plan
Program Intentions for CALS (Decisions).

The TLIM Strategy in this section describes the CALS Environment the program intends to
develop and implement for use throughout the DS life-cycle. A properly developed TLIM
Strategy will lay a firm foundation for Stage 2 The Development of a Through Life
Information Management Plan.
This in turn will provide the basis for establishing the
contractual requirement for information to support the intended ways of working over the rest of
the DS life-cycle.

23

3.0 STAGE 2: DEVELOP A THROUGH LIFE INFORMATION MANAGEMENT

PLAN

Analyse User
Requirements
Define
Information
Management
Plan

Define
Information
Requirements

Define
Infrastructure
Requirements
Figure 3-1 Through Life Information Management Plan Steps
The mechanism for developing and supporting this Shared Data Environment is a Through Life
Information Management Plan. This TLIM Plan is necessary to provide an orderly transition of
information and data requirements throughout the life-cycle of a defense system. There are a
number of different owners of the data throughout the evolution of a defense system. The ability
to transition in an orderly manner from one owner to another is key to providing life-cycle
support to a defense system.
This SDE will support the systems engineering process through which technical data can be
collected, managed, and used to support concurrent engineering, continuous design and program
reviews, and can be continued into the operational phase of a defense systems life-cycle.
Even if an SDE cannot be created for this specific program, a TLIM Plan will be needed to
address the orderly management of information. In such case, the TLIM Plan should address the
specifics of data exchange and Interchange Specifications.
Similar to selecting the logistics support concept early in a programs life-cycle, the SDE
concept must be established as early as possible. The activities of the information management
group closely parallel those of all other groups, i.e., design, logistics, and production engineers.
The information management group must be given equal status with other DS program groups
such as design, logistics, and production. The products of the information systems engineers
must fully support, and be used by, the other traditional engineering disciplines. The means for

24

achieving this is through an Information Management Plan and the concurrent development of
data, software, and hardware infrastructures to support program management, engineering, and
logistics data needs. Early buy-in of this concept is essential for the successful implementation
of an integrated CALS-supported environment.
By achieving this Shared Data Environment, the other benefits of concurrent engineering,
continuous review and approval processes, and better configuration management can be attained.
The SDE provides the structure and the mechanism on which the defense systems technical and
operational data will reside.
Table 3-1 shows the relationships of each phase in a product life-cycle to its associated
information management planning function and activity.
Table 3-1 Major System Life -cycle Phases and Information Management Activities
Program Phase
Pre-concept

Advance planning and conceptual design

[Concept]

Advance development and preliminary

system design
[Demonstration and Validation]

Detail design and development

[Full Scale Development]

25

Major Program Functions

No major information management
planning requirements.
Capture structure requirements,
Education and commitment for
through life data capture and use by
project planning team,
Development of through life
information management planning
documentation.
Evaluation of information
management concepts,
Development of a through life
business model for the program or
project, and
Development of a Concept of
Operations
Development of information
management planning specifications
Development of data specifications
and data architecture
Development of information
architecture to support through life
operational data support
Implement information management
plans
Initiate production and capture of
technical product data
Initiate implementation of
information architecture

Program Phase
Production and/or construction
[Production]
System use and life-cycle
(consumer)
[Deployment and Operations]

support

System retirement
[Disposal]

Major Program Functions

Use information infrastructure to
capture and distribute product and
manufacturing data (as required)
Implement interfaces with
operational support activities
Capture, analyze and distribute
logistics operational effectiveness
data
Analyze operational data for design
updates
Update information management
plan (as required)
Archive information management
planning documentation
Archive data architecture and
technical data
Retire and/or dispose of information
infrastructure (as required)

The scope of the information covered by the TLIM Plan is up to the individual program.
However, to clearly identify and standardize all of the information on a program is too complex
an effort and not necessary from a NATO perspective. The NATO CALS focus is on throughlife product identification and in-service logistics support. In particular, NATO is focused on
keeping the product related technical information to support these business functions in
synchronization with the changing product.
NATO is developing a NATO CALS Data Model to support the following product related
technical data and information:

Product Identification (including NATO Stock Number)

Configuration Identification
Logistic Support Information
Provisioning Data
Technical Documentation in Support of Maintenance

Figure 3-2 depicts the scope for the NATO TLIM Plan.
development of the TLIM Plan for an individual program.

26

The activities listed support

Program
Strategy

Analyse User
Requirements

Develop an Information Management Plan

User
Requirements
Define
Information
Requirements

Information
Requirements
Define
Infrastructure
Requirements

Infrastructure
Requirements
Develop
Information
Management
Plan

Information
Management
Plan

Figure 3-2 Develop an Information Management Plan (IMP)

3.1 Analyze User Requirements
The IMP needs to detail the following:

What information is needed?

Who needs it?
When it is needed?
What it is needed for?
What form is it needed in?
What are the delivery mechanisms ?

3.2 Define Information Requirements

From user requirements the following information requirements can be determined:

Definitions of information needed

Envisioned use of information
Anticipated life-cycle of the information
Form(s) of the information
Management of the DS requirements and associated information

3.3 Define Infrastructure Requirements

To implement a CALS Environment effectively in a program, the existing and planned
information technology capabilities of both the government and industrial team members must
be analyzed. It is important to understand that the organizations team responsibilities and IT
capabilities supporting a program and its end product will change during the program and
27

product life-cycle. Therefore, a major advantage of implementing a CALS Environment is to

plan for and manage these changes from program inception.
Detailed information on
infrastructure requirements for the creation, management, and use of digital data may be found in
Appendix I.
An important decision on IT infrastructure is the level of investment within the program. The
DS Program Manager must determine what to request from offerors in the pre-procurement
phase to ensure the industrial and governmental infrastructures are interoperable and satisfy the
CALS goals and objectives of the program. The goal of this activity is to create a Shared Data
Environment that supports the program goals utilizing the NATO CALS Products throughout the
full life-cycle of the DS program. The following categories shown in Table 3-2 should be
examined when analyzing the existing and planned IT infrastructure.
Table 3-2 IT Infrastructure Analysis

IT Infrastructure Analyses

Telecommunications

Policies
Network Architecture
Protocols
Bandwidth
Security
Internet

Information Standards

Software

NATO CALS Data Dictionary

NATO CALS Data Model
NATO Stock Numbering
CALS Standards
IETM
Express/STEP
EDIFACT
Bar Coding

Operating System
Database
Workflow
CAD/CAM
Product Data Management
Documentation
LSA
GroupWare
EDI
Internet
Email
Bulletin Board

Hardware

Computer architecture
System Back-up
Physical Media
Output Devices
Computer Graphics and Monitors
Input Devices

3.4 Develop Information Management Plan

The Information Management Plan (IMP) is a comprehensive document to support the intended
program business strategy as developed in Stage 1. The IMP should address both government
and industrial requirements and is under program management control throughout the life-cycle.
All parties (NATO, nations, armed services, contractors, etc.) must agree to the IMP. The
following content shown in Table 3-3 is recommended for the IMP.

28

Table 3-3 Information Management Plan (IMP) Content

Information Management Plan (IMP) Content

Requirements

Implementation Plan

Functions

Hardware

User

Software

Information

Services

Infrastructure

Test and Evaluation

Data Management

Schedule

Contractual
Legal
Financial

Program
IMP

Risk Management

Responsibilities

Technical risk

Governmental

Commercial risk

Industrial

3.5 Develop a Business Case for Through Life Information Management

The DS information requirements, either in the realm of Electronic Document Management
(EDM) or Product Data Management (PDM), will require substantial expenditures of manpower
and financial resources. The Business Case demonstrates to management the financial viability
of the project, and is often the key activity in obtaining funds for the project.
3.5.1 Business Case Need
EDM/PDM projects are often implemented to improve the efficiency of an existing business
process, possibly in conjunction with a business process re-engineering effort. In other cases, the
Project is part of a larger program, (e.g., weapon system modernization, new weapon system
production, new product introduction) and the Project costs are simply part of the larger program
budget. Both the costs and benefits must be considered when making the financial analysis.
3.5.2 Why Do We Need It Now?
It can be argued that the costs cannot be accurately determined until after the Vendor Selection
phase is complete. That is a true but not very useful answer. Experience in information
technology (IT) projects has taught that funding a major IT initiative is a process, rather than an
event. As such, it is usually necessary to set cost expectations early, and then refine the cost
information as the Project progresses.

29

An organization needs time to overcome the "sticker shock" that is usually associated with these
Projects. If one waits until after Vendor Selection to determine and publish cost information, the
project will likely be on hold while the cost/benefit information is scrutinized and validated.
Meanwhile, the project has lost momentum and the team will become demoralized or be
disbanded. That is why it is important to complete the Business Case right after the scope is
determined in the Initial Requirements Study.
Newcomers to this technology usually have a difficult time in determining the costs; vendors can
help in setting product costs, while consultants can aid in determining overall project costs.
Of course, the cost estimates will evolve as the Project matures through the Requirements phase.
Now there is a cost model that can be used to assess the impact of decisions made during the
Requirements phase.
A more complete discussion of this topic with a sample outline of "how to" may be found in
Section 8.1.4 of this handbook.
3.5.3 Benefit Determination
3.5.3.1 Benefit Indication
The benefits of an EDM or PDM implementation are numerous. Many individual benefits that
can be determined by brainstorming, interviewing, research in industry publications, engaging
consultants, etc.
3.5.3.2 Benefit Classification
A business case presentation is an exercise undertaken to answer one question in the mind of the
approver(s): "Convince me that this investment is financially sound." Therefore, the validity of a
given benefit is primarily a perception of the listener and only secondarily an inherent property
of the benefit. Benefits therefore must be classified into what are perceived as "strong" and
"weak" arguments. Obviously, the "strong" benefits are emphasized while the "weak" benefits
are de-emphasized or eliminated.
Figure 3-3 shows benefits classified in terms of specificity and technique. A "broad brush"
analysis is usually stated in very general wording. For instance, "Engineers spend XX% of their
time looking for information. With EDM system, we will save some portion, say 50%, of that
time." This is much less convincing than an analysis of a specific situation. Specific situations
may include shop floor drawing retrieval, ISO quality manual management and distribution,
supplier drawing review and approval.

30

Specificity

Situational

Broad
Brush

Interesting

Convincing

Very
Convincing

Totally
Unconvincing

Interesting

Somewhat
Convincing

Conjecture

Statistical

Deterministic

Analysis Technique
Figure 3-3 Strength of Benefits
The analysis technique also impacts how the benefit argument is perceived. Here is an example
of such an argument based on conjecture. A Sales Executive says, "If we managed our
documents better when we are preparing bids for our customers, we would win about 10% more
of the work that we compete for." This argument, while it might be correct, is difficult to
substantiate, so it is only compelling to the extent that the Executive is respected in the
organization. It will only work when he is personally promoting it.
A statistical analysis is stronger than guessing, for example, using this method in analyzing how
the frequency of scrap and rework events related to the timing of drawing availability, in a fast
track design/construction environment.
In this case, detailed information was available
regarding the timing and frequency of events associated with drawing transmittal. In addition,
detailed information was available which related scrap events to drawing errors that could have
been avoideda necessity since not all scrap can be avoided by implementing EDM. Statistical
arguments are difficult to convey because of the complexity of the mathematics involvedif you
use them, you must pay close attention to how the data is presented. A prime benefit of EDM is
cycle time reduction, often demonstrated using a statistical analysis.
A deterministic analysis is the most compelling. This involves a detailed analysis of a specific
business process. Consider: "A person in the plant requires about 30 minutes to walk to the
drawing vault, identify the drawing needed, and get a print. This happens 7,300 times a year.
This time would be reduced to, say, 3 minutes per transaction, with EDM on the shop floor."
This type of analysis can be applied to any business process that is observable and can be
measured in real time.

31

3.5.4 Cost Determination

There are two significant aspects of costs: what the costs are and when they are accrued.
3.5.4.1 Unit Costs
Cost data must be collected for estimating the cost of each project alternative. Six traditional
sources of data are historical organization experience, current system costs, market research,
publications, analyst judgment, and special studies. This step is the preparation for the actually
estimating costs.
Special studies include parametric modeling, function cost analysis, or
engineering analysis.
Many factors must be considered during the process of estimating the costs associated with
competing alternatives. All costs for the full system life-cycle for each competing alternative
must be included. The following factors must be addressed: Activities and Resources, Cost
Categories, Personnel Costs, Direct and Indirect Costs (Overhead), Depreciation, and Annual
Costs. It is critical that all costs of ownership be ascertained. These costs include, but are not
limited to: labor, materials, components, software, hardware, maintenance costs, and engineering
change costs.
3.5.4.2 When Costs Are Accrued
Costs can be accrued at three different "times:"

Initial costs: when the system is first installed

Incremental costs: whenever the system is extended in any way. See "Rollout" below.
Annual costs: upgrades and annual maintenance costs.

Costs are, in fact, a time serieshardware, software and service cost events usually occur
repeatedly.
3.5.5 The Analysis
Unit costs and unit benefits are necessary, but do not provide sufficient information to determine
the viability of a project. We must know when these cost and benefit events occur, and this is
determined in the Rollout Model.
3.5.5.1 Rollout Model
In larger systems, e.g., large, multi-discipline engineering organization, weapons production and
deployment, manufacturing company, the entire system is not installed on day 1. In practice, an
"initial system" is installed, and then deployed or "rolled out" elsewhere. The dimensions of the
rollout include adding:

Users
Concurrent users
32

New applications
New functions
Departments
Buildings and special facilities
Remote sites

3.5.6 The Financial Model

Each rollout increment adds costs (determined from the unit costs) immediately, and adds
benefits thereafter. Typically, a mathematical model of the organization is created, and costs are
parameterized for the number of users, concurrent users, applications, departments, etc. This
organizational model is then the basis for aggregating the costs and benefits in the financial
model.
The financial model is constructed to determine the Net Present Value, "NPV, Internal Rate of
Return, "IRR, and the Payback Period. Expected values of IRRs of 25% to 35% and Payback
Periods of 1.5 to 2.5 years would be typical of EDM/PDM projects in the $1 million range.
3.5.7 Sensitivity Analys is
When the business case is presented, it is likely that assumptions will be questioned. To prepare
for this eventuality, it is possible to adjust the assumptions/parameters in the financial model to
determine the "sensitivity" of the NPV and IRR to changes in the assumptions. Obviously, if the
NPV or IRR is very sensitive to a particular assumption, a strong reason must be made for why
the specific value was chosen. For example, one project showed an IRR of 0% if the system life
was assumed to be two years, 44% if the system life was five years, and 60% if the system life
was seven years. Assumptions are important and should not be taken lightly.
3.5.8 Project Specific Aspects
Projects differ in how certain aspects of a financial analysis are calculated. Projects should
validate their calculation technique with NATO standards before presenting results. Areas of
greatest variation include the treatment of:

Depreciation
Leasing
Maintenance costs
Manpower costs
Capitalization of services
Infrastructure costs (e.g., networks)

33

4.0 STAGE 3: IMPLEMENTING A SHARED DATA ENVIRONMENT

The implementation of the Shared Data Environment, or the best available alternative to an SDE,
is accomplished through the execution of the program IMP. Most of the DS related technical
information required to support program operations is created and managed within the industrial
infrastructure. The NATO/Multi-national infrastructure has the additional task of managing that
information throughout NATO and nations. Put in the context of changing roles and scenarios
over significant periods, CALS becomes a powerful performance and management tool. For
these reasons it is critical that each contract contain requirements for CALS and the NATO
adopted standards supporting NATO CALS. This important aspect is part of the implementation
activities as depicted in Figure 4-1.

CALS
Information
Management
Plan

Develop
SOW

Implement a Shared Data Environment

Statement of
Work (SOW)
CALS on
Contract

Contract

Implement IT

IT
Infrastructure

Implement
Data
Models

Shared
Data
Environment

Figure 4-1 Implement a Shared Data Environment

4.1 Develop the Statement of Work
Language for CALS should be placed in the solicitation package as part of the acquisition
process for the DS program Statement of Work. The Statement Of Work (SOW) should be
directly based on the TLIM Plan and be as detailed as possible. In that way, offerors can respond
effectively to achieve the DS program goals. The TLIM activity should be an integral part of the
acquisition process from the beginning. Evaluation criteria should be developed based upon the
cost, benefit and risk analyzes performed as part of the TLIM process to analyze the offers. The
offerors should be requested to address these areas specifically and propose how they will use
their approach to CALS to impact cost, schedule, and quality. The solicitation language should
be developed such that the cost, benefit, and risk criteria can be evaluated in the offers received.

34

The SOW should specify all requirements that the offeror must propose and adhere to once the
contract is awarded. In many cases, the offeror will be required to provide services in support of
the SDE. This is called a Contractor Integrated Technical Information Service (CITIS). When
industry is requested to provide an on-line information service, a Service Level Agreement
should be required. A Service Level Agreement specifies the following:
Service Level Agreement
Description of On-line Services
Interoperability and Integration
Systems Administration
Access and Availability
Data Rights and Protection
Security
User Training and Support
Charges and Fees
Licensing
Upgrade and Migration
Rights and Warrantees
CITIS reference and SOW information is located in Section 8 of this Handbook
It is recommended that the offeror submit a CALS Implementation Plan (CALSIP) as a separate
cohesive item in the offer. This serves the purposes of isolating the CALS requirements so they
can be specified, evaluated, priced, measured, and modified.
Reference information on developing a SOW and sample SOW language for a CALSIP is
located in Section 10 of this Handbook
4.2 Place CALS on Contract
In selecting an offer, significant value should be placed upon the CALS response. The following
is a prioritized list of general areas to be examined for cost, benefit, and risk:

Impact of CALS Environment on the Product

Impact of CALS Environment on the Program
Level of Services Offered
Availability and Portability of Proposed CALS Environment
Support for Standards

4.3 Implement the Information Technology

Typically, there is a significant amount of time that elapses between the solicitation and award of
a contract for a program. During this time, the IT environment will most likely have changed,
and the IMP should have the flexibility to support this change.

35

The solicitation should not prescribe a specific system solution for this reason, and the industrial
implementation may be phased at the start of the contract to accommodate the following:

Installation of hardware and software if required

Integration with government infrastructures
Integration of supplier base
Implementation of security
User Training
User Support Capability
Test, Evaluation and Acceptance

4.4 Implement Data Models

The CITIS concept has been in existence and use for some time. Originally, it was thought that a
system could be specified. It was learned that this approach was not flexible and too costly. The
concept was again refined to reflect a standard set of generalized services. While the flexibility
and cost issues were resolved, the implementations varied by individual program, causing
inconsistencies that are difficult to manage when the product becomes operational, when
multiple programs must be supported, or if a change of supplier is made.
Several NATO nations are investing heavily in major infrastructure programs to provide logistic
support for their armed forces. It is not feasible to seek a specific hardware or software solution
that all the various parties would be required to adopt and integrate with their existing
infrastructure systems.
A basic CALS premise is that data definitions and digital languages (e.g., SGML, Express,
EDI) can be standardized. These two are used in combination to form an "information
architecture" that conveys meaning such as a document, product model or financial transaction.
The NATO CALS Data Model (NCDM) and its included Dictionary (NCDD) use standardized
data definitions and the Express data modeling language to achieve consistency of interfaces at
the information level without requiring standardization of hardware or software. The NATO
CALS Data Model is a powerful tool that supports an integrated approach to through life product
identification, configuration and logistics support requirements (maintenance, technical
documentation and provisioning).
It is used to integrate logistics information with product
information into an SDE. This enables the processes supported by that information to operate
efficiently by providing relevant information when it is needed, where it is needed, and in the
form it is needed.
A major value of the NATO CALS Data Model and Dictionary is that together they can serve as
an interface specification. When this interface specification is implemented, it can support
remote access by any application that can operate with the NCDM and Dictionary. The potential
for this is significant in that it can support interoperability without standardizing systems, and
eliminates the need for much of the physical data exchange and transfers that occurs today. This
is the foundation of a NATO-wide CALS Shared Data Environment.

36

5.0 STAGE 4: MANAGING INFORMATION THROUGH LIFE

The goal of managing DS information is to provide the correct information to the right user when
it is needed, where it is needed, and in the form it is needed. Data management, like
configuration management, is the responsibility of program management and is an integral part
of the IMP where security and change management are also very important.
5.1 General Considerations
5.1.1 Information Manager
The program manager (PM) will need to assign information management responsibilities. The
PM can assign information management to one or more program office members as an "other
duty as assigned" or recruit a dedicated Information Manager (IM) to the team. In making this
choice, the PM should remember that timely and accurate information sharing among the
program office members will be a major factor in the success of the program. Program size and
acquisition strategy may, at times, require assignment of information management
responsibilities as a collateral duty. The PM should, however, seriously consider the advantages
that a dedicated, professional information manager can offer to the defense system program.
A very small program or one that will acquire a COTS item may not justify a full-time IM. In
that case, it may be most appropriate to assign information management duties to one of the
other program office members or to share a professional IM with one or more other programs.
The designated IM must, in either case, have either sufficient experience or training in
information management procedures and in information technology to plan and execute an
effective information management.
A large program or one with complex interactions (typically a developmental program with high
technical or other risk) will justify a full-time, professional IM. The IM must have both training
and experience in establishing a digital, Shared Information Environment in support of MDG
operations.
An effective IM will be skilled in using traditional information management
principles and procedures, digital data acquisition techniques and exchange standards, and the
capabilities of information technology.
5.1.2 Contractor Involvement
Increasingly, contractors will not physically deliver data to defense system data repositories; they
will deliver data "in-place" at contractor sites and make it available electronically to the defense
system users. This will make defense contractors an integral part of the SDE. defense system
management will become increasingly dependent on contractor data sources and contractors will
find increasing requirements for data support services that extend well past delivery of the
defense system. The level of data support services differs between programs; therefore there
cannot be given a general guideline on how best to accommodate this trend other then that from
a information management point of view this is just another source of information that needs to
be integrated.

37

5.1.3 Data Management Scheme

An information architecture should be developed that will be in place for its full life-cycle. The
information architecture captures the data definitions, the relationships between and among
them, and the functions that are supported by the information architecture. The information
management scheme is used to manage the use of the information architecture. With regard to
the state of the information, four levels should be incorporated into the information management
scheme:
1. Working: Information in draft form that has not been submitted for approval.
2. Submitted: Information that has been formally submitted to the appropriate organization
(e.g., change control board, government program office).
3. Accepted: Information that has been received. It is typically time-stamped and validated
as being in the proper form. This level of information management is usually a contract
requirement.
4. Approved: Information that has been formally approved as being correct and in the
proper form(s).
Furthermore, information should be accompanied by indications of intellectual property rights
(IPR) (e.g., user rights with this information) and security marking (e.g., security level of the
information contained).
The information manager must take care about processing the
information according to the applicable rules.
Product Information Management and Workflow Management software may be used to provide
the control processes necessary to manage the information in the SDE. The information
management activities that need to be governed are shown in Figure 5 -1 .

38

Shared Data
Environment

Manage the Information

Input
Information

New
Information
Update
Information

Updated
Information
Access/Distribute
Information

Current
Information
Archive
Data
Store
Information
Feedback

Figure 5-1 Manage the Information

5.2 Input Information
The information management scheme must identify and control who creates data and the
acceptance criteria and processes.
5.3 Update Information
The information management scheme must identify who controls requests to update information
and how that request is controlled and approved.
5.4 Access/Distribute Information
The controlled access and distribution of information should address the following areas:

Type of Access (ad-hoc query, transfer, report)

Format(s) (ASCII, image, video, IETM, etc.)
Type of distribution (distribution, subscription, on-demand)
Media (telecommunications, magnetic, optical)

5.5 Store Information

The systems, media and format for the information storage should be an integral part of the
information management scheme.
The approach to information storage should include
considerations of the following:

39

Centralized control or centralized storage

Distributed database control
Replication
Archival
Media

40

6.0 MODELS
6.1 The Through Life Business Model
6.1.1 Purpose of a Through Life Business Model
The Through Life Business Model (TLBM) is a tool designed to help defense system programs
manage change. It presents a vision of how NATO can improve its acquisition and logistic
processes for multi-national programs by making best use of information technology over the
DSs life-cycle.
Information is going digital. This is changing the way work is done. DS programs have a
growing requirement to share information across boundaries. See Figure 6-1.

NATO

Armed
Forces

Program
Office

Sub
Contractor

Prime
Contractor

Figure 6-1 Weapon System Information Sharing

A DS Program Office, Contractor, or Logistic Agency can use the TLBM in several ways to
explore opportunities for allocating responsibility, improving communications and reducing
costs:

A Baseline Description of the Life -cycle: The TLBM provides a common, agreed
description of the major life-cycle activities and information flows that a program will
need to address.

A Benchmark: The integrated, through life approach, illustrated by TLBM provides a

benchmark of best practice across NATO. Program managers can use TLBM to assess
how far their program has progressed in taking full advantage of modern IT and business
practices.

41

Exploring Boundaries: the TLBM can be used to explore the allocation of roles and
responsibility across organizational boundaries. Marking TLBM activities to show the
responsible organization(s) can provide a deeper understanding of:

Current responsibilities
Information exchange requirements
Opportunities for Change

Implementing Change: For maximum benefits the TLBM should be used, and further
developed, as one active component in a program of business change.

Most change programs have an IT component. The TLBM is one of a series of tools developed
by NATO to help managers make best use of IT. The others are:

The NATO CALS Handbook (Chapters 1-5);

And the NATO CALS DATA MODEL (NCDM) (Section 6.2).

DS programs embarking on change can use the TLBM, in conjunction with other NATO CALS
products, as a starting point for modeling their future processes and as a tool for developing their
information requirements. The TLBM illustrates the improvements that are possible when
information is fully exploited. The TLBM provides:
Enablers:
A Concurrent Engineering approach.
Multi Disciplinary Groups, or Integrated Project Teams,
Electronic interaction between participants, based on a Shared Data Environment,
maintained for the life of the program.
Techniques:
Improved requirements management, sustained through life.
Consistent life-cycle Strategies for managing risk, quality, configuration, acquisition
(and re-supply), support, and program information.
Project Optimization over the life-cycle.
Early through life cost modeling, and improved cost awareness.
Trade-off studies: capability, supportability, cost, risk, and in-service date are treated
as independent variables.
Continuous review and approval of predicted or measured performance against the
current requirement.
Optimization of the supply chain for acquisition and for support.
Optimization of support management based on feedback of in-service performance.
life-cycle management of roles and relationships giving a flexible boundary with
industry.
Information is managed as an asset.

42

An outcome:
Faster and cheaper acquisition.
Improved system availability.
Cheaper in-service support.
Safer disposal or re-use.
6.1.2 Developing a TLBM
6.1.2.1 TLBM Definition
A model to illustrate NATOs improved business processes for the through life management of a
defense system (DS) as enabled by a Shared Data Environment.
6.1.2.2 TLBM Scope
The model illustrates the core activities that are required to respond successfully to the Validated
Mission Need and Business Directives for the specific defense system program over its full lifecycle. Integration of the DS into any wider organizational or business context (e.g., armed force
or industrial company) is assumed to occur outside the model and is reflected by the acronym of
Input, Control, Output, Mechanism (ICOM) crossing the TLBM boundary, as shown in the
context diagram.
The TLBM model does not define the order in which these activities are to be performed, or the
organization/activity that may undertake them. In using the TLBM, DS programs will need to
tailor the model to reflect their specific relationships with Armed Forces and Industry. The
TLBM can be used to identify information exchanges between organizations by selecting the
activities (boxes) each organization will perform and noting the arrows that cross the
organizational boundary, as shown within the TLBM or at its boundary.
DSs will vary in the degree to which their support is integrated with the support of other DSs
operated by the relevant Armed Forces. The model includes all activities required to provide
support for a specific DS. Information required by others to support the integration of support
for the specific DS with the support of others DSs is reflected by ICOMs crossing the TLBM
boundary. The model reflects several activities that could be performed under contract. It does
not attempt to define relationships or interfaces into the industrial supply chain beyond the Prime
Contractor.
6.1.2.3 Purpose
Provide an illustration of SDE enabled improved business processes for DS through life
management.
The TLBM should be used as follows:

By DS program managers and their staff to develop a DS Program Strategy for

CALS. In this context the model must:

43

Provide a top level over view of the main activities through the DS life-cycle, as
enabled by an SDE.
- Draw attention to certain key activities that need to be managed in a consistent
manner through all life-cycle phases (CM, QA, ILS, IM).
- Illustrate, at a high level, the major information flows within the DS program lifecycle, so that the program management can see the totality of information to be
managed through life.
Support discussions and decisions of the likely impact, on responsibilities and on
information flows across boundaries arising from:
- Different organizational boundaries (within the project, between the project and
industry, between the project and the Armed Forces).
- Different SDE boundaries and capabilities.
- Show where the IM processes fit into through life activities.
- Provide a basis for the development of a program specific TLBM or other activity
models required solving specific problems.
- By members of NCO, and others, in presenting CALS concepts and ideas during
awareness activities.
- By other NATO or national agencies who are seeking to explore life-cycle issues
(e.g., Co-operative Logistics).

6.1.2.4 TLBM Viewpoint

The viewpoint taken in the TLBM is that of the lifetime owner of the Defense System (DS).
The lifetime owner is accountable for providing and sustaining the specific DS, over its full lifecycle, to meet the Validated Mission Need and Business Directives agreed and maintained for
that DS. Responsibility for performing this role may be held by different organizations over
time.
6.1.2.5 Manage a Defense System Through Life
The NATO CALS Through Life Business Model (TLBM) is
major activities associated with the life-cycle of a defense
Validated Mission Need through disposal. It is intended to
communication tool used to understand the management of
entire life-cycle. This is illustrated in Figure 6-2.

a structured representation of the

system from the definition of a
provide a reference model and a
a future defense system over its

The TLBM was developed from the results of a series of workshops, arranged by the NATO
CALS Organization. Experts from NATO nations were brought together to establish how
information technology can be used to reduce costs, accelerate delivery and improve the
availability of a defense system, over its life-cycle.
The processes illustrated by the TLBM assume that a Shared Data Environment (SDE) will be
implemented within the defense system program, to captures information in digital form, as it is
created. Through the SDE, all program participants can access the information when and where
needed, in an appropriate form, for use many times without loss of intelligence or the need for
data re- entry. This SDE, which may be specific to the program, or part of a wider IT
44

infrastructure, enables the improvement of processes for acquiring, operating, supporting and
disposing of a defense system, as illustrated by the TLBM.
USED AT:
NCO

AUTHOR: John Dunford

DATE: 3/10/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/7/99

DRAFT

READER

DATE

TOP

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10

CONTEXT:

PUBLICATION

Business
Directives

Def
Pol.&
Stds

Laws &
Gov
Policy

Usage&support Ops
Policy
Prog

DS ready for Ops

Validated Mission Need

DS needing support

Contracts & Requests

MANAGE A DEFENCE
SYSTEM THROUGH LIFE

Goods & Services fm others

External Data
Feedback fm Ops

DS Data to Others
Disposed Items
Inst to Ops

A0

Project
Pers

Existing
Infrastructure

Viewpoint: the viewpoint taken in the TLBM is that of the life-time owner of the
Defense System (DS). The life time owner is accountable for providing and
sustaining the specific DS, over its full life cycle, to meet the Validated Mission
Need and Business Directives agreed and maintained for that DS.
Responsibility for performing this role may be held by different organisations over time.

Purpose: To illustrate NATO 's improved business

processes for through life management of
a defence system, enabled by an SDE
NODE:

TITLE:

MANAGE A DEFENCE SYSTEM THROUGH LIFE

A-0

NUMBER:

TLBM 6.01

Figure 6-2 (Top Level Diagram)

6.1.2.5.1 Defense System
A Defense System (DS) is an identifiable product with "special to type" support that has, or will
have, a Validated Mission Need or NATO Staff Target. Validated Mission Need and NATO
Staff Target (Phased Armament Procurement System (PAPS)) are equivalent pieces of
information that can be used interchangeably for a Multi- national or NATO program. The term
"Defense System" is used throughout the TLBM in preference to a number of other terms, in use
across NATO, which have similar meaning: e.g., Defense Equipment, Armament System,
Weapon System, Weapon Equipment. The development of a support strategy for the system and
the conduct of special-to-type support activities are included within the TLBM to allow
illustration of Integrated Logistic Support activities. This support strategy also considers the
complex and variable interface between the specific DS and the logistic infrastructures of the
various Armed Forces that may use it.
6.1.2.5.2 TLBM Principles
There are several key principles identified in the workshops that are fundamental to the new
ways of working.

45

6.1.2.5.2.1 Concurrent Engineering Approach

The TLBM reflects the global change in engineering practice towards the use of an iterative
system engineering approach to product development and support, sometimes known as
Concurrent Engineering (CE). Systems Engineering is defined in IEEE Standard 1220- 1994 as
"An Interdisciplinary collaborative approach to derive, evolve, and verify a life-cycle balanced
systems solution which satisfies customer expectations and meets public acceptability. The
TLBM reflects the increasing reality that the major life-cycle processes -- requirement definition,
development of solutions, manufacture, support and operational use -- operate continuously and
in parallel over the life-cycle, and are no longer confined to specific life-cycle phases.
6.1.2.5.2.2 Life -cycle Integration
The life-cycle integration principle has been applied throughout the TLBM so that each activity
appears once only, even though it may be used in different life-cycle phases. In addition, the
TLBM draws attention (A12) to the requirement to develop and maintain a coherent and
consistent set of life-cycle strategies and policies for certain key processes, which need to be
applied consistently over the full life-cycle, despite changes in the program organization. Six
activities are given special prominence - Acquisition, Risk Management, Integrated Logistics
Support, Configuration Management, Quality Assurance, and Information Management (or
CALS).
6.1.2.5.2.3 The Use of a Shared Data Environment
The Shared Data Environment (SDE) is a key enabling mechanism for the future environment as
shown in the TLBM. Within the TLBM, the term is used to describe the existence of a real and
significant capability, within and beyond the DS program team, to work together with digital
data. Both a logical and physical environment supports consistent definition and management of
information about a defense system and program through life. The DS program SDE must be
established at the beginning of the life-cycle and maintained through life. The SDE must
therefore have an open architecture and be adaptable to changes over time. The TLBM reflects
the activities of creating and operating this SDE and managing information within it.
6.1.2.5.2.4 Multi- Disciplinary Groups
A second key mechanism linked to the TLBM is the use of Multi- Disciplinary Groups (MDGs)
or Integrated Project Teams (IPT). MDG are used to bring together skills and resources from
different organizations, including industry and government, to solve specific problems
efficiently, by joint interactive working. This can be achieved physically by face to face
meetings, or in a virtual environment (the SDE). The structure, composition, and role of the
MDGs will vary depending on the contract strategy and the level of integration between
customer and contractor. Used appropriately, MDGs can accelerate progress and improve
quality by replacing protracted formalized procedures for information exchange and approval, by
direct face- to- face working. MDGs are assumed available, as a resource, for all life-cycle
activities.

46

6.1.2.5.3 Information as an Asset

Many of the benefits from CALS derive from a capability to capture information once, as it is
created, and to use it many times over the life-cycle. Much of the data needed to support the DS
in service is created by the design activity. The TLBM encourages the development, early in
life, of a single, integrated source of product and support data for use throughout the life-cycle.
This will require the development and use of a program information architecture.
6.1.2.5.4 Organizational Interfaces
The interface between participants in a DS program can vary widely between programs and over
the life-cycle. The TLBM does not show any organizational boundaries but can be used to
explore the consequences of different boundaries in terms of who does what, and to identify the
critical areas of information exchange or sharing which any particular boundary will create. (See
Model Scope definition for more on this topic).
As noted above, two other NATO CALS products have relevance to the TLBM.
6.1.2.5.4.1 NATO CALS Handbook
A guide for making best use of information technology in support of Defense System program.
It describes a process for defining and implementing a Shared Data Environment for a specific
DS program. (Chapters 1-5)
6.1.2.5.4.2 NATO CALS Data Model
The NCDM provides a possible start point for the development of the program information
architecture by defining an integrated set of product and support information. The goal is to
develop this data model, with other inputs, into an international standard for product life-cycle
support data.
6.1.2.6 Manage a Defense System Through Life - First Level Breakdown
At this first level of breakdown four major activities are identified which together translate the
Validated Mission Need and program Business Directives into a fully serviced DS Ready for
Operational Use. This is illustrated in Figure 6-3 . After operations, the DS needing support is
returned for maintenance, with the necessary Feedback from Operations. This Feedback also
allows for the assessment of system performance against the Current Requirement and Contract
conditions. DS Data needed by others is provided as an output. Information on other defense
systems, and other topics of interest is provided as External Data.

47

USED AT:

AUTHOR: John Dunford

DATE: 3/10/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/6/99

DRAFT

READER

DATE

CONTEXT:

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
Validated Business
Directives
Mission
Need

Def
Pol.&
Stds

PUBLICATION

A-0
Ops Prog

Usage&support Policy

Laws & Gov Policy

Inst to Ops

Feedback
fm Ops

Contracts & Requests

ESTABLISH AND
CONTROL DS
PROGRAMME TL

Prg Dir
Current Req
Perf Rep
Core Product Data
Support Info
Trg Req

A1

Req Feedback
Eval Def
Spares & Components

OBTAIN DS

Goods &
Services
fm
others

Information
Services
Program
SDE

DS
ready
for
Ops

Predicted Perf
Tools & Facs.
A2

Returned
Items
SUPPORT THE USE of
the DS

TestFindings
Proc Spec

External
Data

DS
Data to
Others

Disposed
Items

Change Impact
A3

DS
needing
support

Feedback fm Maintenance
Evaluation Findings
Required Items
Project
Pers

NODE:

TITLE:

DISPOSE or
RECYCLE
A4
Items
for
Rfb

Existing Infrastructure

MANAGE A DEFENCE SYSTEM THROUGH LIFE

A0

NUMBER:

TLBM 6.01

Figure 6-3 (Diagram A0)

Arrows between boxes are deliberately defined at a high level to avoid too many lines.
Decomposition of these arrows occurs at lower levels, and in the arrow definitions (See for
example the decomposition of Program Directives within diagram A1).
Box A1 generates four types of management instruction to control all work on the program.
Two are used to manage activities within the model; two place actions externally. This first
internal instruction is the Current Requirement, which consolidates and amplifies the VMN and
Business Directives to the level of detail needed by the DS program itself. This Current
Requirement is maintained over the full life-cycle and is used to communicate any changes (both
actual and possible). The Current Requirement may diverge from the VMN if, for example, a
decision is taken to accept a level of performance below that originally specified because
insufficient funds are available to correct the shortfall. The second form of internal instruction is
Program Directives, which are used to manage all activities under the direct control of the
life-cycle owner.
Two kinds of external instructions are also generated. Instructions to
Operators define any necessary limitations on the use of specific systems arising from material
shortcomings. Contracts and Requests (see A13) seek Goods and Services from others, as an
input to the life-cycle processes. The requirement for contracts is established in part by analysis
within A1 and by feedback of Required Items from A2 and A3. The information needed to
monitor DS performance is fed back to A1 to control the overall process and to generate a
Performance Report. A1 also provides the program SDE and Information Services as a resource
to all program participants.

48

Box A2 undertakes the work needed to obtain a successful DS and provide a support capability.
The scope of this work required can vary widely. At a maximum it includes all of the tasks
needed to establish the system concept, design, produce, test and deploy the system itself and
design, develop and commission a "special to type" support and disposal system, to provide inservice support. At a minimum, it could be limited to renting an existing system, owned and
supported by a third party, for use by the Armed Forces. The Obtain function generates a DS
ready for Operation, plus its "special to type" tools and facilities and all necessary spares and
components. It also provides as an output, ideally through the SDE, all of the data needed to
support the use of the system, including a prediction of its life-cycle performance. A2 also
undertakes the refurbishment of Items returned from A4.
Box A3 provides the support needed to sustain the DS fit for operational use, including
Operational and Servicing Tasks. Work is planned and executed as required by the Operational
Program. Tools, facilities, spares, and information needed for this are obtained from A2 or from
the Existing Infrastructure. Items no longer needed are returned to A4 for disposal or recycling.
Feedback on maintenance activities, and on evaluation findings is provided to A1.
Box A4 accepts the retired defense system and DS Items removed from service for disposal or
refurbishment. Items for refurbishment or recycling are returned to A2. Items no longer needed
are disposed of.
6.1.2.6.1 Establish and Control Defense System Program Through Life
Box A1 provides the control mechanism for managing the DS program over its life-cycle
through four linked activities.
In Figure 6-4 (Diagram A21), box A11 translates and develops the Validated Mission Need,
Business Directives, Usage and Support Policy, and other constraints imposed on the program by
external authorities into a program Current Requirement. This Current Requirement establishes
the performance and supportability characteristics that the DS program team is actually striving
to deliver. It is maintained over the life of the system, in an accurate and up to date form, to
communicate all approved changes. The Current Requirement includes all life-cycle support
requirements such as life, readiness, supportability, and availability characteristics. It includes
information on how the System will be used and maintained (a Use Study). Support Information
is fed back from A2 to assist in developing the requirement. Proposed changes to the
requirement are fed back from A14. Approved changes are communicated as updates of the
Current Requirement.

49

USED AT:
NCO

AUTHOR: John Dunford

DATE: 3/10/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/7/99

DRAFT

READER

DATE

CONTEXT:

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

A0

Usage&support
Policy

Business
Directives

Ops
Prog

Validated Mission Need

ESTABLISH AND
CONTROL THE
REQUIREMENT

Support Info

Current Req

A11
DEVELOP LC
STRATEGIES
& POLICY

LC Strat & Pol.

A12
Prg Dir

Change Impact
External Data
Required Items

Contracts & Requests

ESTABLISH and
RUN the DS
ORGANISATION

Proc Spec

Information Services
Program SDE

A13
Predicted LCC

Perf Rep
COMPARE ACTUAL
SYSTEM STATE &
PERFORMANCE WITH
REQUIRED

Predicted Perf
TestFindings
Feedback fm Maintenance
Feedback fm Ops
Evaluation Findings

Inst to
Ops

A14
Change Proposal

NODE:

TITLE:

ESTABLISH AND CONTROL DS PROGRAMME TL

A1

NUMBER:

TLBM 6.01

Figure 6-4 (Diagram A1)

A12 highlights the need to develop and maintain a coherent set of policies and strategies for
managing the DS program efficiently over its life-cycle. These are required to maintain
consistency of approach to certain key functions and processes, in the face of changes to
organization or responsibility allocation (e.g., the hand-over from acquisition to in- service
management).
A13 establishes and directs the organization needed to deliver a successful DS. Three of the five
outputs authorize work to proceed. Program Directives provide the resources and tasking
instructions to the staff controlled directly by the Life-Cycle Owner (LCO). Contracts provide
the same function for commercial organizations being tasked by the LCO. Requests for
assistance are raised to place work, or seek changes or authorizations from Government or other
non- commercial bodies beyond the program in question, including the owners of other DS.
A13 also undertakes the work needed to create and sustain the program Shared Data
Environment (SDE), which is provided as a resource to all other activities. Information Services
are also provided to meet any information needs that users cannot satisfy for themselves, through
the SDE.
A14 assesses whether the DS program is meeting its objectives in relation to the Current
Requirement and Business Directives, and instigates necessary changes.
The predicted
performance of the DS is provided from A2. A life-cycle cost estimate is provided by A134.
50

Information on actual performance is fed back from Operations, from Maintenance and from
Support Evaluations to identify the need for change. The assessment activity generates a
performance report, noting any shortfalls evident and may result in change proposals affecting
the requirement, the defense system, of the DS Program. This activity will also address the
acceptability or otherwise of requests for waivers or concessions for components which fall short
of the design intent.
6.1.2.6.1.1 Develop Life -cycle Strategies and Policy
Certain key processes can benefit dramatically from the power of the Shared Data Environment,
provided they are managed over the life-cycle in a consistent manner.
In Figure 6-5 (Diagram A12), A122 identifies the requirement to develop address life-cycle
issues when developing an acquisition strategy. The acquisition strategy must consider what role
the original designers and suppliers will be expected to play after the initial acquisition, in order
to identify what, rights, information and experience the through life support authority will need
to acquire.
USED AT:
NCO

AUTHOR: John Dunford

DATE: 3/27/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/16/98

DRAFT

READER

DATE

CONTEXT:

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

A1

External Data
LC Strat & Pol.
DEFINE LC
STRATEGY
AND POLICIES
DEFINE
ACQUISITION
STRATEGY
A121

A122

DEFINE RISK
STRATEGY
A123

Acq Strat

DEVELOP ILS
STRATEGY
Risk Mgt
Strategy

A124
DEVELOP CM
STRATEGY
AND PLAN
A125

ILS Strategy

CM Strategy

DEVELOP QA
STRATEGY
AND PLANS
A126

QA Strategy

DEVELOP CALS
STRATEGY & PLAN
A127
CALS Strategy
NODE:

TITLE:

DEVELOP LC STRATEGIES & POLICY

A12

NUMBER:

TLBM 6.01

Figure 6-5 (Diagram A12)

A123 identifies the requirement to manage life-cycle risks from the program outset.
A124 covers the task of developing a strategy and high level plan to ensure effective support is
achieved, through the application of Integrated Logistic Support. The use of a Shared Data

51

Environment, with a Concurrent Engineering approach and Multi Disciplinary Groups at last
makes it truly possible to integrate logistic activities fully into the rest of the life-cycle.
A125 draws attention to the importance of Configuration Management, which, in a Shared Data
Environment is both easier to do and has critical significance. The major CM data flows are
illustrated in the TLBM. A125 is added to TLBM to draw attention to the need to develop a
clear life time strategy for configuration management, as early as possible in the life-cycle
addressing the requirements of all parties over the life-cycle who will need configuration data or
make configuration changes.
A126. Quality Assurance over the life-cycle involves massive volumes of data and is crucially
dependent on reliable access to historic records.
Appropriate early action, linked to the
development of the program SDE, offers the prospect for major improvements in quality through
access to better data, and substantial reductions in quality related costs.
A127 highlights the requirement to invest significant effort in the analysis of the life-cycle
information requirement, by developing a CALS Strategy. Full guidance on this topic is
provided by the NATO CALS Concept of Operations (NCOPS), and is not repeated here.
6.1.2.6.1.2 Establish and Run the Defense System Organization
This activity defines what needs to be done to deliver a DS program to fully satisfy the Current
Requirement (A131). It also identifies who will do the work (A132), establishing the necessary
contracts (A133) and managing the three key resources needed to deliver the program: money
(A134), people (A135), and information (A136).
In Figure 6-6 (Diagram A13), A131 defines the tasks to be performed and services to be
provided, in response to the Current Requirement and Change Proposals and develops a Program
WBS to define the necessary tasks. The WBS is also assumed to include the development of any
Service Level Agreements needed to specify the standard of ongoing services. A131 also
initiates the work needed to assess the impact of proposed change, and based on the results,
decides whether to implement or reject the change. Approved changes are implemented by
updating the WBS or Task list, amending the Current Requirement if needed. A131 also
develops and publishes the high-level program plans needed to define when activities should be
undertaken.

52

USED AT:
NCO

AUTHOR: John Dunford

DATE: 3/26/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/15/98

DRAFT

READER

DATE

CONTEXT:

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

A1

Current Req
Change Proposal

Program WBS
MANAGE
PROGRAM
SCHEDULE

Proc Spec

Prg Dir

Program Schedule

Org Structure

A131
ESTABLISH
ROLES and
RELATIONSHIPS

Requests for Assistance

Contracts
&
Requests

A132
Activities to be contracted
Perf Rep
Required
Items

PLACE &
MANAGE
CONTRACTS

Contracts
& ITTs
Contract Dir.

A133
Budget Req

External
Data

Available Funding

MANAGE DS LC
FUNDING

Change
Impact

Predicted LCC

A134
MANAGE HUMAN Allocated Manpower
RESOURCES

Financial Implication

A135

MANAGE DS
INFORMATION

Information
Services

Program
SDE

A136

SDE Req.

Contract Information Req

NODE:

TITLE:

ESTABLISH and RUN the DS ORGANISATION

A13

NUMBER:

TLBM 6.01

Figure 6-6 (Diagram A13)

A132 establishes how responsibility for the various program tasks is to be allocated over the
life-cycle, develops an organization to undertake "internal" tasks, and raises the necessary
contracts to obtain support from industry. A132 also generates requests for assistance from noncommercial external agencies, such as the Armed Forces or other DS programs. As roles and
relationships will change over time, particular attention should be paid to the management of
transitional arrangements (e.g., on entry into service). Having defined roles and responsibilities,
A133 raises and manages any contracts needed to acquire the goods and services. Requirements
for contracts are also provided from A2 and A3 as Required Items and from A136 (SDE
requirement and Information to be contracted). The Performance Report is provided to allow
assessment of contract achievement in relation to in- service use.
A134 acquires, allocates, and accounts for the funds that are needed to manage the DS throughlife. This is assumed to include the task of forecasting and tracking DS life-cycle cost.
(Financial information flows in the TLBM could be developed in more detail if required).
A135 plans, organizes, monitors and controls, the provision of human resources for DS program
life- cycle, including the issues of recruitment, training, reward and incentives.
A136 responds to the CALS Strategy by developing, deploying, and supporting through life, the
Program SDE. It also provides any necessary Information Services to user, beyond those they
can access for themselves through the SDE. This activity replaces the traditional task of
53

publishing Technical Manuals, which are replaced by information provided through the SDE.
Outputs are provided to A133 to define the information and IT products to be acquired by
contract.
6.1.2.6.1.2.1 Place and Manage Contracts

Figure 6-7 (Diagram A133) briefly illustrates the major activities in placing and managing
contracts. The requirement should be noted for historic data from other programs in developing
a contract strategy (External data) and for significant feedback from maintenance and operations,
to assess the performance of reliability or in service availability clauses. This is provided by the
Performance Report. The proposals received in response to the ITT are treated as part of
External Data.
USED AT:
NCO

AUTHOR: John Dunford

PROJECT: NATO CALS Office - TLBM

DATE: 4/3/98
REV: 10/7/99

WORKING

READER

DATE CONTEXT:

DRAFT
RECOMMENDED

NOTES: 1 2 3 4 5 6 7 8 9 10
Program
Schedule

PUBLICATION

A13

Available Funding

External Data
Required Items

DEVELOP CONTRACT
STRATEGY

Activities to be contracted

Contract
Strategy

Proc Spec
A1331

ISSUE SOLICITATION Invitation to Tender

Contract Information Req
SDE Req.

A1332

ASSESS PROPOSALS
A1333
Selected
Contractor

Contracts
& ITTs
RUN CONTRACT
Contract Dir.

Perf Rep
A1334

NODE:

TITLE:

PLACE & MANAGE CONTRACTS

A133

NUMBER:

TLBM 6.01

Figure 6-7 (Diagram A133)

6.1.2.6.1.2.2 Manage Defense System Information
The extensive activities (Figure 6-8 (Diagram A136)) involved in managing information through
life, in the context of a Shared Data Environment are fully described in the NCOPS to which
reference should be made.

54

USED AT:
NCO

AUTHOR: NCFP Team

PROJECT: NATO CALS Office - TLBM

DATE: 4/14/98
REV: 10/16/98

WORKING

READER

DATE CONTEXT:

DRAFT
RECOMMENDED

NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

Program
Schedule

A13

SDE Req.

Program
WBS

DEVELOP
IM PLAN

External Data
A1361

IM
Plan

ESTABLISH &
OPERATE
Program SDE

Contract Information Req

Program SDE

A1362

PROVIDE
INFORMATION
SERVICES

Information Services

A1363

NODE:

TITLE:

MANAGE DS INFORMATION

A136

NUMBER:

TLBM 6.01

Figure 6-8 (Diagram A136)

6.1.2.6.2 Obtain Defense System
This element of the life-cycle covers all the activities needed to obtain an operational DS and its
associated support capability. It includes four sub- tasks: Integrated Product Development;
Production; Testing and Distribution that apply equally and concurrently to the operational
system and its associated support.
In Figure 6-9 (Diagram A2), the Integrated Product Development activity (A21) converts the
Current Requirement into a full definition of the system and its support products, from which the
DS can be manufactured, tested and deployed. The activity also generates test definitions and
evaluation criteria for the product and its support system, plans and processes for the deployment
and operation of the support system (part of Support Info), Training Requirements for operating
and support staff, a prediction of the DS performance and a requirement statement for the
feedback needed from in- service maintainers and operators to asses life-cycle performance of
the operational and support systems.

55

USED AT:
NCO

AUTHOR: NCFP Team

PROJECT: NATO CALS Office - TLBM

DATE: 5/20/98
REV: 10/15/98

WORKING

READER

DATE

CONTEXT:

DRAFT
RECOMMENDED

NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

A0

Prg Dir

Current Req

Ops
Prog
Trg Req
Proc Spec
Eval Def

External Data

Req Feedback
Support Info
DEVELOP DS

Predicted Perf

Goods &
Services fm
others

Change Impact
Core Product Data
Test Def
As-built Config

A21 Mfr &

Rfb
data

Tools & Facs.

Spares & Components

PRODUCE DS

DS for Deployment
Items for Rfb
A22
TestFindings

CONDUCT TESTING

Items
for
Test

DS ready
for Ops
A23

Users

DEPLOY DS

Spares &
Components
Tools & Facs.

A24
Project Pers
NODE:

TITLE:

OBTAIN DS

A2

NUMBER:

TLBM 6.01

Figure 6-9 (Diagram A2)

A21 also develops a "make or buy" plan, which provides an output (to A1) of the items that need
to be purchased. As development effort is needed through life to assess off- design conditions or
to implement design change, a Change Impact assessment is fed back to A1. A22 turns the
detailed Manufacturing and Refurbishment data, provided from A21, into physical products,
either by manufacturing processes or by the receipt, assembly and integration of Goods and
Services from others. The activity applies to the Operational System, to special- to- type tools,
equipment or facilities required for support, to spares and components, to Items for Test and to
Items returned for Refurbishment and re- cycling. The activity is taken to include all testing and
quality assurance activities applied routinely to production items.
The Conduct Testing function (A23) is the process of comparing the actual performance of the
system and its components with the specified technical performance specification and criteria.
The result of this function is the specific test findings that are used to influence the decision(s) to
move to the next phase of the WS life-cycle. Testing can be applied to any item, but will
typically apply specifically to prototypes, first production items and development items related to
product change.
A24 is the activity of deploying or distributing the Operational System, and all related items,
from the production source to the operational, or normal storage, location. It includes the initial
deployment of an newly delivered Operation system, the setting up of the special- to -type
support capability, and the re-supply of spares and components used to support operations. The

56

outputs are an Operation System, components, and spares, in their required locations and ready
for operational use.
6.1.2.6.2.1 Develop Defense Syste m
The activity of developing potential or actual solutions to the VMN starts as a response to the
first issue of the Current Requirement by developing and selecting a DS concept (A211),
Figure 6-10 (Diagram A21). External Data is required to allow alternative concepts to be
explored and evaluated, in the form of necessary information on the performance, costs and risks
of other DS options.
The DS Concept must address both operational (e. g system performance capability) and support
aspects (e.g., life, readiness and availability).
A212 begins the process of turning the concept into an engineered solution by defining a
functional architecture for the intended system and defining the test and evaluation criteria
against which solutions will be evaluated. Although this task will be performed early in the
system life-cycle, it may need to be repeated many times in response to shortfalls of performance
or proposed changes to the operational system or to its support. A212 also undertakes the work
needed to decide whether various elements of the intended DS will be designed and produced
under the direct control of the life-cycle owner, or be purchased by contract. Details of Required
Items are fed- back to A13 for purchase planning and contract action. The Functional
Architecture is fed forward to provide a start point for the engineering design.
The design of the Operational System and its related support is undertaken concurrently, by an
MDG, through three linked activities: Engineering Design (A213), Failure Modes and Criticality
Analysis (A214), and the design of the support system, through Logistic Support Analysis
(A215). Engineering Design provides two outputs. The Core Product Data provides a definition
of the product to the level needed for the purposes of support and operations. Core Product data
includes the identity, version, definition, properties, classifications and characteristics of all parts
likely to be exchanged during the in- service life and the assembly structure of the defense
system (the Design Configuration) including permitted options and variants. A second output
provides the additional data needed for production and refurbishment. The detailed models,
calculations, and design data used to derive and justify the design are retained within A212, and
are not made available to other program activities. For this reason a feedback loop is through
A212 to establish the technical implications of any proposed changes, or off- design condition.
A214 uses the functional architecture and product structure to identify failure modes, symptoms
and effects as an input to LSA and as an aid to subsequent maintenance.

57

USED AT:

AUTHOR: John Dunford

DATE: 3/27/98

WORKING

PROJECT: NATO CALS Office - TLBM

REV: 10/15/98

DRAFT

READER

DATE

CONTEXT:

RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10

PUBLICATION

A2
Prg Dir

Current
Req

External
Data

In Service Goals

TestFindings

DEVELOP
CONCEPTUAL
OPTIONS DS Concept

Change Impact
Proc Spec

A211

Test Def

DEFINE DS

Eval Def
Functional Architecture
A212
Mfr & Rfb data

ENGINEERING
DESIGN

Core Product Data

A213
FAILURE
ANALYSIS
Support Info

A214
Existing
Business
Info

FMECA
Data

DESIGN THE
SUPPORT
SYSTEM

Req Feedback
Trg Req
Predicted
Perf
PREDICT LIFE CYCLE
PERFORMANCE

A215
Support Equipment Requirements

A216
Users
NODE:

TITLE:

DEVELOP DS

A21

NUMBER:

TLBM 6.01

Figure 6-10 (Diagram A21)

The design of the DS support system, or LSA (A215), is undertaken concurrently with product
design and failure analysis. They are shown separately in the model to only to illustrate the
different outputs. In an SDE environment, it is expected that data from these three activities will
be generated and managed in an integrated product data model within a CM or PDM system.
This product data model is expected to provide the authoritative source for the information
needed to support the DS in service, over the rest of the life-cycle. The data generated in these
three processes should also be sufficient to avoid the requirement to writing additional Technical
Publications.
Structuring, formatting and distribution of information which is not directly
accessible through the SDE is undertaken as an Information Service (A1253)
(A comprehensive IDEF model for logistics support analysis LSA process has been developed
by the Norwegian Defense Forces, and is discussed in Section 6.2 )
6.1.2.6.3 Support the Use of the Defense System
This activity provides the support needed to bring individual systems into the condition required
for operations.
In Figure 6-11 (Diagram A3), A31 defines the work to be done, based on the Operational
Program, the Program Directives, and the support procedures within the Support Data. A31 also
establishes the requirement for items to be purchased for use in support activities.

58

A32 provides storage, transportation, and issue as required of spares and other items needed for
maintenance, based on the deliveries from A2.
USED AT:
NCO

AUTHOR: John Dunford

PROJECT: NATO CALS Office - TLBM

DATE: 3/10/98
REV: 10/16/98

WORKING

READER

DATE CONTEXT:

DRAFT
RECOMMENDED

NOTES: 1 2 3 4 5 6 7 8 9 10
Prg Dir

Current Req

PUBLICATION
Ops
Prog

A0

Req
Feedback

Eval Def
Trg Req

External Data

Required
Items

Core Product Data

PLAN
SUPPORT

Spares &
Components

A31

Tools & Facs.

Support Plan
Req Config
STORE
TRANSPORT &
ISSUE ITEMS
A32

Items for
Use
Returned
Items
MAINTAIN,
UPDATE &
PROVIDE
FEEDBACK

Support Info
DS needing support

Feedback fm
Maintenance
Maintained
DS
O&S TASKS

Goods & Services fm others

DS ready for Ops

A33
As-maint Config

A34

MANAGE
FACILITIES
A35

Trained People
TRAIN
SUPPORT
STAFF
A36

CONDUCT
EVALUATIONS

Predicted Perf

A37

In-Scope EvalFindings
Tools & Facs.
NODE:

Evaluation
Findings

TITLE:

Existing Infrastructure

SUPPORT THE USE of the DS

A3

NUMBER:

TLBM 6.01

Figure 6-11 (Diagram A3)

A33 undertakes the maintenance needed to restore the DS to the condition required for the next
intended operation. This includes the activities of diagnosing, repairing, testing and calibrating
the item in accordance with the Core Product and Support Data. The activity also includes the
work needed to incorporate approved changes to the system configuration. Feedback from
maintenance is provided as specified by Required IS Data, by recording the findings, action
taken, spares used and issues arising. The AS Maintained (current) Configuration is reported to
A31 (and elsewhere as needed) to reflect work undertaken. Items removed or no longer required
are passed to A4 for disposal, recycling or refurbishment.
A34 undertakes any (non-maintenance) activities needed to prepare the system for operations,
e.g., fueling, tow from hanger, empty waste tanks etc.
A35 maintains the support facilities and tools in a fit for use condition.
A36 provides operator and maintainer training, in accordance with the requirement from A215.

59

A37 evaluates the performance of the support system, in relation to predicted performance, in
accordance with the definition provided from A212.
6.1.2.6.4 TLBM Activity Definitions
Activity definitions are included in Appendix C.
6.2 NATO CALS Data Model
6.2.1 Introduction
6.2.1.1 Motivation
Modern defense systems cannot operate without ready access to large quantities of technical
information. This information is an asset as valuable as the physical hardware itself.
Today, technical information is created in digital form. This behaves differently from the same
information on paper.
The opportunities are enormous but new problems and risks are
implicated.
A major problem arises when multiple organizations need to use the same
information. Differences in data definition and data format block communications between
partners and require development of expensive interfaces. Too often, data is locked into the
application in which it is created forcing the use of proprietary solutions. As a result, many IT
systems that ought to be offering business improvement act, in practice, as barriers.
To address the above issues, the NATO CALS Data Model (NCDM) defines a common set of
data definitions that can be used to achieve consistency of interfaces at the information level
without requiring standardization of hardware or software. The role of the NCDM is to
standardize content of a life-cycle repository for defense system technical information with the
objective that Armed Forces with different Information Technology infrastructure, e.g., different
hardware and software platforms, can make use of the same technical information.
6.2.1.2 Information Modeling
Raw data is not information. Two parties can only exchange data in conjunction with an
agreement on the meaning of the data. Consider the number 1964. This number is data
without information. The data becomes useful if we add the information that it is a year (1964),
or the number of people attending the 98 CALS Europe Conference. Although the data is the
same in both cases, the information is different.
An information model addresses the underlying meaning of data regardless of technology. A
model describes meaning through structure and correctness constraints. It does not specify
encoding techniques for data values.
The NATO CALS Data Model uses EXPRESS as a formal language for specifying information
requirements.

60

EXPRESS is an ISO standard (ISO 10303-11) and has been used by STEP, POSC, and other
projects to describe the information requirements of many engineering activities.
The function of EXPRESS is to describe information requirements and correctness conditions
necessary for meaningful data exchange. An EXPRESS information model is organized into
schemas. The NCDM, for instance, is organized in five schemas. These schemas contain the
model definitions and serve as a scoping mechanism for subdividing large information models.
Within each schema are three categories of definitions:

Entity Definitions : describe classes of real-world objects with associated properties.

product, for instance, is an entity of the NCDM. The properties are called
attributes and can be simple values, such as name or id or relationships between
occurrences of entities, such as owner or part of . Entities can also be organized
into classification hierarchies, and inherit attributes from supertypes. The inheritance
model supports single and multiple inheritance, as well as a new type, called
AND/OR inheritance. The NCDM defines 218 entities.
Type Definitions : describe ranges of possible values. The language provides several
built-in types.
A modeler can construct new types using the built-in types,
generalizations of several types, and aggregates of values. The NCDM has 51 type
definitions
Correctness Rules: are crucial components of entity and type definitions. These
local rules constrain relationships between entity instances or define the range of
values allowed for a defined type. Global rules can also make statements about an
entire information base. Only a few local correctness rules are defined in the NCDM

6.2.1.3 How to Use the NCDM

The NCDM could be used in several ways as described in the following paragraphs. However, it
should be recognized that the NCDM is not a plug-and-play tool to solve all information
management issues. Further development is needed to build an IT system around the NCDM.
6.2.1.3.1 Specifying Information Requirements
An information model is an agreement on the meaning of data. This agreement is represented in
a formal manner using an appropriate descriptive language (e.g., EXPRESS). An agreement is a
mutual understanding or arrangement between parties. The parties, in our case, are the
Defense Industry and the NATO Armed Forces. The agreement defines WHAT data will be
exchanged and what is the MEANING. In a data model the meaning of data is conveyed by the
data structure and relationship.
How data is created by the industry and how it is used by the single Armed Force is not part of
the agreement. The processes and software applications that make use of the data are not part of
the agreement either.
The NCDM can be used to specify the technical information needed by the NATO Armed Forces
to support a defense system in service, through-life. From the project manager perspective, the
NCDM can be used to identify data requirements for a specific project. The utilization of the
61

NCDM in this sense is very similar to what is done today when data elements are contracted
according to legacy standards (e.g., MIL STD 1388). The advantage of using the NCDM resides
in the quality of the contracted data. The model gives an integrated view of data where design
data like system physical and functional breakdowns are integrated with support data and with
the data needed to make technical documentation available.
Text appearing as [times roman italics] in the following paragraph is provided as a sample
language that can be used in developing the data requirements for a Request For Proposal (RFP)
or Request for Quotation (RFQ) SOW.

The contractor shall provide configuration and design data that could support the
production of Bill of Material (BOM) Reports and of Labeled Occurrence, Multilevel,
Indented Product Structure Reports. This data shall be in the form of instances of the
following NCDM entities:
-

The contractor shall provide NATO STOCK NUMBERS (NSN), in the format
defined by the NATO Codification System, for the items delivered. The NSNs shall
be in the form of instances of the following NCDM entities:
-

Product
Product_version
Structured_product_definition and its subtypes as needed

External_product_identifier
Product_identification_assignment
Product_identification_category

Characteristics and Management data associated with the NSNs shall be provided in
the form of instantiation of the following NCDM entities:
-

Characteristic_assignment
Characteristic and its subtypes as needed

The business case to evaluate opportunities to move from legacy standards to the NCDM is
outside the scope of this document.
6.2.1.3.2 Defining a Common Vocabulary
There is a flow of information (e.g., Defense System Technical Information) between the
industry, originator of the data, and the Armed Forces, users of the same data.
There could also be a need for data exchanged between Armed Forces of different NATO
nations. When parties with different software and hardware platform need to share the same
information, the need for interfaces arises. These are sophisticated and expensive software that
acts as translators between different systems.

62

B
A

D
E

Figure 6-12 Number of Interfaces without a Common Vocabulary

As illustrated in Figure 6-12 , the number of director translators between systems grows as N(N1) where N is the number of systems. The NCDM can be used as a common vocabulary, agreed
by the Defense Industry and by the NATO Armed Forces, to dramatically decrease the number
of interfaces. In this case the number of interfaces only grows as 2N, as illustrated in
Figure 6-13 .

B
C

A
NATO CALS
Data Model

D
E

Figure 6-13 Number of Interfaces Using the NCDM as a Common Vocabulary

6.2.1.3.3 Implementing an Integrated Product Database
A Data Model can be implemented in a database. An EXPRESS data model is technology
independent and can be implemented in a variety of databases (e.g., Relational, Object Oriented,
and hybrid). For this discussion, we assume that the model is implemented in a relational
database (e.g., DB/2, ORACLE, INFORMIX etc ).

63

The strength of relational systems is in their ability to store large amounts of data in a highly
normalized, tabular form, and to perform efficient queries across large data sets. Relational
systems use SQL for both data definition and data manipulation.
Unfortunately, EXPRESS does not include a construct to create relational tables automatically.
A method of mapping the NCDM to a relational database was experimented during the Rig Test.
In this method, each entity is mapped to a table with columns for attributes. Each table has a
column with a unique identifier for each instance. Attributes with primitive value are stored in
place and composite values like selects, and aggregates are stored as foreign keys containing the
unique instance identifier. Inheritance is normalized out of the tables. The table for each entity
type contains the local attributes defined by the entity and uses the instance identifier as the
primary key. A complete entity instance, with all inherited attributes, can be reconstructed by a
join on the identifier across all tables in the type hierarchy.
Other conflicts that ought to be addressed to implement the NCDM in a relational database are
the following:

The relational model does not directly support the union construct. EXPRESS Selects are
simulated by a table with a column for each possible member type. Only one column in
each row contains a value. The remaining columns are empty;
Relational systems primitive data types are not as extensive as those of EXPRESS are. A
mapping is therefore needed to link the NCDM data types with those supported by the
selected relational system;
Relational systems need to know the length of the each field in the database. This
requires further data analysis since no attribute length is defined in the NCDM;
Finally, EXPRESS imposes no limit on the length of type or attribute names, while the
NCDM define entities and attributes with long names. Some relational systems restrict
the length of table and column names to 30 characters. Name length conflicts in this case
need to be resolved.

Potential users of an Integrated Product Database build around the NCDM are the industry,
Defense System project teams, and the NATO Armed Forces.
6.2.1.3.3.1 In the Industry
The need for the industry to integrate their engineering processes around integrated product
database is becoming increasingly evident.
Engineering applications have unusually complex information models.
These information
models are complex because engineering applications manipulate simulations of the real world.
Models for areas such as CAD geometry, tolerances, materials, and manufacturing plans are
structurally and semantically rich. Applications are similarly complex, and are tightly bound to
the models. Often, the information exists only as program language structures taken from a
primary application, usually a PDM or CAD system. Subsequent applications must be modified
whenever the primary application changes.

64

The resulting situation is that only special-purpose databases, controlled by PDM and CAD
vendors, are used to describe complex products.
Designers and Manufacturers do not have any control over their product databases, which is
clearly undesirable for strategic reasons. In addition, the customers request for complex design
data together with the logistic support information in an open format accessible by off-the-shelf
DBMS, is not easily addressed.
To overcome the above problems, design and manufacturing companies need to integrate their
engineering processes around product databases (Figure 6-14).

CAD/CAM

PDM

LSA tools

Integrated Product
Data Base

users

Figure 6-14 Integrated Product Database Data Sources

The term integrated refers here to the process of reconciling data from many different sources
so that the resulting collection can be managed consistently with minimum redundancy.
Some of the technical opportunities are:

Integration around product databases enables concurrent engineering - a process where

multiple engineers work on different facets of a product concurrently;
An Integrated Product Database gives the opportunity to store, in a single source, may
chose information needed to deliver Technical Documentation (e.g., Technical Manuals)
together with Defense System Configuration data;
An Integrated Product Database enables a more efficient and flexible way of delivering
data to NATO Armed Forces:
The user can be allowed to access the contractor maintained database;
The database itself or part of it can be delivered to the user;
Data can be delivered to the user using exchange files in whatever format the user

In a Project
65

A major value of an Integrated Product Database is that it can support remote access by any
authorized user. The project team can make use of this feature to obtain ready access to the data
while it is created. The advantages of this are obvious, for instance:

Verification that system requirements are met can be assessed in real time;
Verification of database accuracy and completeness can be assessed more easily and
accurately.

Text appearing as [italics] in the following paragraph is provided as a sample language that can
be used in developing the data requirements for a Request For Proposal (RFP) or Request for
Quotation (RFQ) SOW:
The contractor shall provide a cost effective method of implementing an
integrated product technical database based on the NATO CALS Data Model
such that appropriate configuration and version control of the system is
maintained aligned with technical information needed to support it through-life.
6.2.1.3.3.2 In NATO Armed Forces
Several NATO nations are investing heavily in major infrastructure programs to provide logistic
support for their armed forces. The NATO CALS Organization does not intend to recommend a
specific hardware or software solution that all the various parties would be required to adopt and
integrate with their existing infrastructure systems.
The NCDM, by standardizing at the information level, offers the opportunity to define a new
Information Infrastructure built around a Defense System Technical Information Database.
The benefits of such repository of technical information for all available weapon systems are
self-evident.
Benefits that are even more dramatic could be achieved if the Defense System Technical
Information Database is implemented in a consistent way across NATO by all Nations. In this
case, the realization of a NATO Distributed Database for Defense System Technical
Information will be achieved. NATO Nations working together (e.g., Combined Joint Task
Force) could then be allowed to access each-others weapon system technical database on a need
to know basis.
6.2.1.4 How to Implement the NCDM in a Program
NCDM could be implemented in a program. The following diagram loosely follows IDEF0
notation and illustrates the activities required to build an IT system around the NCDM.

66

Entities/Subtypes
Attributes
Relationships
Integrity Rules

Business Model
Data Requirements

Create Logical NCDM

Data Model

Technical Environment

Business Rules
Attribute Formats

Create Physical
Data Model

Performance Consideration

Input Data

Tables
Columns
Keys/Indicies
Triggers

Empty Database
Business Processes & Funct.

Create &
Update Data

Populated Database

Software Applications
Import/Export Interfaces ( STEP/PDM)

Figure 6-15 Building an IT System Around the NCDM

The boxes in the diagram represent activities to be performed; the arrows are components of the
system that should be available to perform the activities.
By delivering the NCDM, the basic component of the system, the first activity is completed. All
other components are grounded on the NCDM but are equally essential.
A single program implementing the NCDM will be faced by the requirement of developing
components such as Business Rules, Implementation Guide, Attribute Format Definition, and
Software Development. A program developing these sets of components could well support a
single project but, inevitably, would provide a project specific solution.
6.2.1.5 How to Achieve Interoperability
To achieve interoperability between programs and between NATO Armed Forces some of the
components in the above diagram should be developed and agreed at NATO level. In particular:

NATO nations should confirm acceptance of model definitions and formally endorse the
NCDM;
NATO should define Attribute Formats and seek agreement of nations;
NATO should develop and agree with partners a set of Business Rules.

The followings do not need to be agreed at NATO level and can vary from program to program:

Business practices and functionality;

Software applications;
Implementation platforms;
Import/Export interfaces.

67

6.2.2 The NATO CALS Data Model

6.2.2.1 What is the NATO CALS Data Model?
The NATO CALS Data Model (NCDM) is a formal description of the data required to support
the logistics process for the acquisition and use of major systems. Such systems include aircraft,
weapons platforms like tanks and ships, and other complex products. The objective is to support
the information required, used, or provided by:

The owner of a complex product;

The people responsible for maintaining and repairing the same product;
The organization(s) who design and manufacture the product.

These three groups have had equal priority. This is necessary, as the contractual boundaries
between them are becoming increasingly variable.
This information has been covered by several existing standards, such as MIL-STD 1388,
AECMA Spec 1000D, and AECMA Spec 2000M. The NCDM takes an integrated approach to
the data covered by these specifications but also recognizes the possibilities for other kinds of
data such as design information and multi-media. It does so in a way that should enable current
approaches to be followed while enabling richer and more effective new methods to be applied.
The NCDM is presented as a data model so that it can be used as the basis for data exchange,
sharing and for system development. The approach being followed is related to that used in the
ISO 10303, Standard for Product Data Exchange (STEP). Like STEP, the NCDM is intended to
be equally applicable in both civil and military arenas.
6.2.2.2 Business Drivers
To justify change there has to be advantages and benefits from the new approach over the old.
The objective of this section is to identify some of the reasoning behind the development of the
model in terms of the business problems and requirements it addresses.
The NCDM forms an integrated model that has been achieved in such a way that:

The resulting database can both act as a common-source database for technical
publications and hold the base information used to create (some of) the documents. The
model enables SGML strings to be stored directly. This matches the conclusions of the
Technical Publications sub-group of the harmonization workshops;
The various legacy-numbering schemes such as LCNs can be incorporated and used if
desired but are not required (and can therefore be changed and adapted as required in the
future). The model should allow for easy integration of analyses performed separately;
The capabilities of MIL-STD-1388 for describing tasks and resources have been
generalized to provide complete information rather than forcing short-cuts which lose
necessary information;

68

Various extensions beyond current MIL-STD-1388-2B capabilities have been included

such as multiple users of a system and better handling of tasks which generate other tasks
and equipment which requires its own spares;
Considerable facility for data sharing has been introduced, removing much of the
duplication inherent in the use of MIL-STD-1388-2B structures;
The ability to include multi-media, such as video and sound clips, has been included for
documenting and illustrating parts, tasks, and failures.

The existing approaches make considerable use of encoding. In the model most of these encoded
items are modeled as the real data (that which is obtained by looking up the meaning of the
encoding. However, to support legacy data, provision has been made for the encoding (and the
identity of the standard which defines the encoding) to be held. This is always optional.
6.2.2.3 The High Level Model
A very basic simplified view of the model is shown below:

Product

Task
Anomaly

Figure 6-16 Abstract view of NCDM

This can be interpreted as follows:
Product, Anomalies, and Tasks are related to each other. When we consider that the main
reason for the whole logistics area is to determine what can go wrong with a product
(i.e., anomalies) and what has to be done (i.e., tasks) to either repair it or to prevent problems
from occurring, this set of relationships are inevitable. Furthermore, other products are used in
repairing or maintaining a given product.
This view can be extended slightly to include the facility to relate information (such as
specifications, manuals, catalogues, etc.) to the three main areas:

69

Information
Object
Product

Task
Anomaly

Figure 6-17 Extended Abstract View of NCDM

A more detailed high level-planning model is shown below.
procurement.commercial_information
project

generates_uses

personnel
facility
spare_
part
support_
equipment

procures_
provides_
owns

operates

realised_as

tech_pubs.tech_information

requirement

for_product

is_maintained_by

product of_product

packaging
_handling
_storage_
transport

resource requires

task

defines

product_
analysis of_
_data product usage
component_
assembly

usage

characterized
_by S[1:?]

of_product

S[0:?]

information

defined_
by

organisation

supports

conditions

product_
definition
describes

representation

illustration
shows

Figure 6-18 The NCDM High Level Planning Model

The diagram loosely follows the conventions of the EXPRESS-G language (formally defined in
ISO 10303-11). For the present purposes, the diagram can be read as follows:

Boxes represent things of interest.

Thick black lines represent is a relationships, so support_equipment is a resource.
Thin lines represent relationships or associations and are labeled to give meaning. They
can often be read as a sentence, such as organization-operates-product.
The double-layered boxes show that the subject is defined elsewhere.

70

6.2.2.4 Model Organization

At present, the data model includes five schemas covering the following areas:

Product Structure, Functional Breakdown (CoreModel);

Failure Analysis (Anomaly);
Task Descriptions (Task);
Technical Documentation (InfoObj);
Logistic Support Analysis (LSA).

There are other major aspects and specific details applicable to the current content, both in the
existing standards and outside of them, which will be developed in future versions of the model.
6.2.3 The Core Model (CoreModel)
6.2.3.1 Overview
The core of the model centers on the following:

Product identification;
Product structure (how products are used to build other products);
Product definitions, including functional and other breakdowns.

Here (and throughout the model), the term product is taken to have a very general meaning. A
complex item (such as a helicopter) is a product but so is a simple washer, nut, or bolt. Clearly,
we are unlikely to provide a functional breakdown of a nut or bolt but they are still products in
that someone will have to provide identifiers, to design, manufacture and potentially to sell them.
This general view of product is taken from the STEP standard where a product is defined as: a
thing or substance produced by natural process or manufacture.
The starting point for the NCDM was to re-use aspects of the STEP model to ensure general
compatibility with STEP. Hence, the central product area of the NCDM follows the STEP form
and re-uses the STEP approach to product structure. (Here product structure means the way in
which one product is assembled from other products.) The ability to define other views of a
product, such as functional or zonal breakdowns was then added. These additional views are
then used to attach related information.
6.2.3.2 Description
The starting point is product. From STEP, the NCDM follows the convention that the product
entity represents the core concept of a product, i.e., its identity, and not the information that is
associated with the product. Such information includes the identification, any versions, and any
more information that defines some things about the product. These two concepts are handled as
separate entities. This gives the starting point for the model as below:

71

*of_product
product

of_version
product_version

product_
definition

Figure 6-19 The Product Entities

This enables there to be many versions of a product and many definitions for that one product.
The latter is reasonable because a product_definition is taken to be a collection of data that
defines the product for a given purpose. Hence, we may have several different product
definitions for logistics purposes.
In fact, two different kinds of product definition are allowed for in the NCDM. One of these is
aligned with the STEP standard. With this approach, the relationships of an assembly to its parts
are captured explicitly and so the product definition for any assembled part becomes a network
of related product definitions. The other type of product definition is common in logistics, where
a single breakdown is used which applies to a product/system and all its constituent
parts/functions. These two types will be looked at in turn. It is important to note at this point
that the NCDM does not require one form over the other nor does one have to be created before
the other.
6.2.3.2.1 Product Structure for Design and Manufacture
This part of the model is taken with a small number of changes from STEP integrated resources
(ISO 10303, parts 41 and 44). The main part of the model defines a network of related product
definitions, where the definition of an assembly is linked to the product definitions of the parts
used in the assembly through the product definition usage entity.

72

structured_product_
definition
parent_product_
definition

child_product_
definition

supplied_
version_
relationship

product_definition_
relationship

product_definition_usage
1

assembly_
component_
usage
measure_
with_unit

make_from_
usage_option

container_
usage

quantity quantified_assembly_
component_usage

next_assembly
usage_occurrence

specified_higher_ promissory_
assembly_usage usage_
occurence

Figure 6-20 EXPRESS-G of product_structure

In practice, assembly is usually handled using the next_assembly_usage_occurrence entity. This
captures the fact that one part (or rather a product_definition for the part) is used as a component
in an assembly (or rather the structured_product_definition of the assembly). Graphically this
can be seen below.

Main assembly

Major subassemblies

Figure 6-21 Product structure presented as a tree

73

SPD

NAUO

SPD
NAUO

NAUO

NAUO

NAUO

SPD
NAUO

NAUO
NAUO

SPD
NAUO

NAUO
NAUO

Figure 6-22 An Instance of a Product Structure

The name attribute of the next_assembly_usage_occurrence should be used to hold an identifier
for the particular place where a component is used. (This corresponds to the use of two different
LCNs to deal with, for example, the Left and Right placements for a pump used twice in the
same engine.)
This situation is shown in the figure above where two
next_assembly_usage_occurrence entities point down to the same component.
6.2.3.2.2 Product Structure for Logistic Breakdown
There are several different breakdowns used for logistics purposes. These include:

Physical
Functional
System
Zonal
and others

All of these basically define a hierarchy and are treated the same way in the NCDM. The
starting point is the breakdown entity (a kind of product definition) that identifies the specific
breakdown by name and description (all product definitions have these) and gives the type of
breakdown (e.g., functional). A number of standard types are allowed for in the NCDM and
additional types may be specified. The breakdown entity also points to the starting elements in
the breakdown. (Usually for a breakdown with a single root, there will only be one starting
element.)
Thereafter additional levels of breakdown are specified by means of
element_relationship entities. Both the EXPRESS-G and an instance are illustrated below.

74

form

breakdown_
type

breakdown

includes S[1:?]
definition
element_
definition

element

relating

related

element_
relationship

Figure 6-23 EXPRESS-G of Breakdown

The breakdown entity has an attribute called form which is used to state the form of logic that
has been applied in creating the breakdown. Several standard values are provided for this as well
as the opportunity to define non-standard forms of breakdown. The standard forms are
catalogue, functional, hybrid, physical, system, and zone.
This indicates the criteria used by the logistics engineer in specifying the elements in the
breakdown.
Note that hybrid form implies a combined physical/functional breakdown and
should not be used for other combinations.
Each element in the breakdown has an identifier. This is the position in the NCDM that can be
used to hold the LCN. There is a separate element_definition entity referenced from the element
entity. This allows the use of a common definition (without duplication) for two elements in
different breakdowns. Thus, a common set of element definitions can be consistently applied to
several breakdowns within a single system or across multiple systems. This corresponds to the
use of standardized logistics terms by a particular armed service or other organization. Perhaps
somewhat confusingly, each element definition also has an optional form attribute. This is
necessary when hybrid breakdowns are defined and enables the nature of a given element in the
breakdown to be determined (i.e., is it functional or physical).
The standard values for this attribute are:

Physical: the element represents a level in a physical breakdown or a physical part in a

hybrid breakdown;
Functional: the element represents a level in a functional breakdown or a function in a
hybrid breakdown;
75

Zonal: the element represents a zone in a zonal breakdown;

Catalogue: the element represents a level in a catalogue breakdown;
System: the element represents a level in a system breakdown;
Group: the element is an element_group (see below).

There are two specific subtypes of element. These are:

element_group - used to define an element in a breakdown that acts as a collection point

for more elements. This is used to deal with the logical form of figures in parts
catalogues where the drawing is effectively used to define a group of parts.
lsa_element - this carries the additional information as to whether or not an element is to
be treated as a candidate for Logistic Support Analysis.

The links between elements are captured using the element_relationship entity. This is also true
of the links between levels of indentation in the traditional LCN numbering scheme. Thus for
the following LCN breakdown:
id
28
2801
2802

name
Fuel system
Fuel storage system
Fuel pressurization

There will be an explicit element relationship between the element with id 28 and that with id
2801. (Note it is also permissible to make the id of the fuel storage system element 01. The fact
that the fuel storage system is a part of the fuel system is captured by the explicit relationship and
so there is no longer a need to repeat the 28 in the id of the fuel storage system element.).
There are several types of element_relationship defined in the NCDM. These are necessary to
capture all the different links established in the breakdowns currently used for logistics, in the
MIL-STD-1388 LSAR or in breakdowns established for catalogues and manuals.
The following types of element relationship are allowed:

alternate_element_relationship: two elements at the same level of breakdown are

alternates to each other;
element_equivalence_relationship: two elements are equivalents to each other;
sub_element_relationship: one element is a sub-element of another. (This is the type
used to show a new indentation level in the LCN structure.);
element_conversion_factor: used to specify how values associated with an element are
converted to a common basis (such as annual usage);
element_group_membership: used to show that an element is included in an element
group. (This is how to show that a part is included in a figure in a parts catalogue
breakdown.);
element_group_relationship: used to show that two element_group (figures) are related.

76

6.2.3.2.3 Crossing Between Breakdowns and Product Structure

Not surprisingly, it is extremely useful to be able to cross-reference between the breakdown and
element structures. You are unlikely to have individual breakdowns for many components (and
systems) used in a given large product. Instead, there will be elements in the breakdowns that
correspond to either components or sub-assemblies. Similarly, it is necessary to know which
components together provide a certain function in a functional breakdown.
The product_definition_element_relationship entity provides a general link between an element
and a product_definition or a product_definition_usage. The reason why it is either a
product_definition or a product_definition_usage is that an element (corresponding to an LCN)
may refer to either the use of a component (or sub-assembly) that occurs only once or the use, in
a particular position, of a component (or sub-assembly) that occurs more than once.
The product_definition_element_relationship entity simply establishes a link. A subtype of
product_definition_element_relationship called element_realisation is used to assert that the
product_definition is the corresponding product in the case of a physical element (LCN) or
provides the function for a functional element (LCN). Note that several product definitions can
be asserted as realizing the same function (i.e., they all point to the same one). This can be
interpreted as that they combine in some way to do this. Equally, a single sub-assembly may
have several functions and so can be linked to several elements in a functional breakdown.
In some cases, however a part may realize a function only in the scope of some overall function.
In this case, the realisation_application entity can be used to show the function or other types of
elements for which the realization is valid.
6.2.3.3 EXPRESS G Diagrams
EXPRESS G Diagrams and EXPRESS DEFINITIONS for the NCDM COREMODEL functions
may be found in Appendix B .
6.2.4 Failure Analysis (Anomaly)
6.2.4.1 Overview
An anomaly is a reason for doing something. There is something about the product that is not
how it should be and so work must be done.
Traditionally logistics has been driven by the Failure Mode Effects and Criticality Analysis
(FMECA). The model does not start with Failure Mode because there are more general reasons
for defining tasks than Failure. As an example, the availability of a new software upgrade is not
a failure but does give rise to tasks. Hence, the name product_anomaly is used simply to
indicate that not all is as it should be with the product (e.g., in the previous example, the software
is not at the desired release and so is anomalous). However, the model does provide for two
specific types of Anomaly: Failure and Damage.

77

The NCDM treats the propagation of anomalies differently to the legacy standards. Instead of
following the logic dictated by the breakdown(s) being used (such as a functional breakdown), it
captures the cause-effect relationships. Thus, the effects of a given failure can be traced in a
manner that reflects the real physics and its equivalent functional impact.
6.2.4.2 Description
The obvious starting place is the product_anomaly entity. As explained above there are two
specific types of anomaly identified. These are failure_mode and damage. Failure results from a
physical problem of the product concerned while damage is externally caused. Damage is
treated as a special type of failure_mode. Either of these can also be specified as a
failure_mode_from_a_specified_source, which allows the source to be identified. This is to
allow for failure_modes defined in standard references, such as the predicted failures for certain
types of printed circuit boards.
Now for each failure, we may get some effects. These can be seen as falling into two major
categories: local symptoms (for example, increased engine smoke) and other failures (for
example, failure in an oil-pump bearing leading to failure of the engine)
6.2.4.2.1 Effects
Local symptoms are captured using the effect entity. This allows the effect to be described.
Effects are specified as an entity so that the same effect can be shared across multiple failures.
(This also allows the query: show me the failures that have this effect).
There is no direct link from failure_mode to effect. Instead, there is the mode_effect_assignment
entity that allows an effect to be associated with a failure_mode or with a combination of a
failure mode in an operational phase. Thus, the fact that the effect of a landing gear failure mode
is different during taxi than flight can be captured.
6.2.4.2.2 Causal Relationships
Traditionally the means to document a failure has been to capture its cause/effect via a functional
or hybrid breakdown. The NCDM allows the direct cause/effect relationship to be captured,
independent of the breakdown. The NCDM provides a general relationship entity between
anomalies. This is then subtyped to be the consequential_failure_relationship. At a simple level
the use of the consequential_failure_relationship is as shown below

failure mode 1
consequential
_failure_
relationship

causes

failure mode 3

failure mode 2

Figure 6-24 One Anomaly Caused by 2 Others

78

This figure says that failure modes 1 and 2 act as the causes of failure mode 3. In this case,
failure mode 3 will be specified as a consequential_failure_mode (a subtype of failure_mode). It
is possible that failure modes 1 and 2 are primary failures (the start of a cause-effect chain) in
which case they can be specified using the primary_failure entity. Alternatively, one or both of
them could be consequences of other failures.
Primary failures have a cause_description attribute that refers to a separate entity
(cause_description) to allow a common set of fundamental causes to be re-used across many
failure modes. Examples of such a cause description could be cracking through fatigue or
personnel error.
Now life is not always so simple and it may be that a particular failure will occur only if two
other failures occur together or if a third failure occurs on its own (not with the first two). This
accumulative logic, showing what combinations will occur, is known as roll-up.

failure mode 1
consequential
_failure_
relationship
failure mode 2

causes

xor_consequential_
failure_relationship

failure mode 4

failure mode 3

consequential
_failure_
relationship

Figure 6-25 Example of Failure Roll-up

Altogether there are three types of roll-up relationship allowed for:

xor_consequential_failure_relationship
and_consequential_failure_relationship
or_consequential_failure_relationship
together

the related causes are mutually exclusive

the related causes must occur together
the related causes can but need not occur

6.2.4.3 EXPRESS G Diagrams

EXPRESS G Diagrams and EXPRESS DEFINITIONS for the NCDM Failure Analysis
(Anomaly) functions may be found in Appendix B .

79

6.2.5 Task Descriptions (Task)

6.2.5.1 Overview
The NCDM breaks away from the traditional view that a task is solely a sequence of steps that
must be followed. Firstly, a distinction is made between what the objective of the task is and the
(one or more) ways that the objective can be achieved. In very simple terms the what is to be
done and the how to do it are separated. Why? Because different methods can be defined
according to the situation. It is clear that different approaches will be taken to do a given job in
the field or in a well-equipped base, or in the arctic versus the desert. Even differently trained
personnel, the laws, and other restrictions that apply may affect how the same job is done.
Once this immediate separation is made, the NCDM also allows different approaches to do a task
rather than just a pure sequence of steps. The existing approaches made use of free text plus
labeled lines to allow for some sequencing changes (such as taking different routes if a test was
passed). However this meant that an entirely separate and additional functionality (use of IETM
approaches) was required if this variation was to be used in a computer-sensible way. Hence, the
NCDM provides facilities that enable the way a task is done to be programmed. This is
effectively equivalent to a simple programming language, rich enough to enable IETM style
functionality to be provided directly from the database that corresponds to the model. (Note that
it is still possible to use textual descriptions only, as in the existing MIL-STD-1388 task
narratives. However, this reduces the potential advantages of using the NCDM.)
Thereafter, the other main component of the task area of the model is concerned with the
resources necessary to do the job.
6.2.5.2 Description
The more detailed description is divided into the two areas: what to do and what is used to do it:
6.2.5.2.1 What to Do
The task entity is used to identify something that needs to be done. It has a subtype,
logistics_task , which carries additional information, such as criticality and maximum time.
Neither of these entities includes the reason why the task has to be done, some kind of anomaly,
or the way in which it can be done.
The way in which a task can be done is captured through the task_method entity. The link
between them is given by means of an instance of the task_method_assignment entity (or its
subtype, the task_method_relationship_with_context). One or more task_methods can be
associated with the same task. By using the task_method_relationship_with_context, these can
be shown to apply in different scenarios. Hence, it is now possible to allow for the different
ways in which the same task will be achieved in varying climatic conditions or by different
organizations (with different skill-sets or even different legislation applying).
The most complex area of the task part of the NCDM is the handling of how a task is done, i.e.,
task_method. The first thing to realize is that it is still possible to give a simple narrative

80

description of how a task is accomplished. This is achieved using the logistics_task_method

subtype of base_task_method entity. The text is then given as the value of the representation
attribute. (The reason it is called a representation is that other forms of description, such as
video, can also be given.)
If, however, it makes sense to divide the task up into some series of stages, each stage will also
be documented using the base_task_method entity. At this point, it may also be necessary to
designate some of the stages as being warnings. This is done using the advisory_task_stage
entity that is a subtype of the base_task_method entity. After separating the stages of the task
method, it becomes necessary to join them back up to form the method for a single task. This is
achieved using the structured_task_method entity and its subtypes.
We will start with the simplest case, that of a sequence of stages which has to be followed. A
task_method_sequence is used to specify a list of stages.
This is one type of
structured_task_method. The ordering of the stages is captured using a List for the methods
attribute. There is no sequence number stored so additional stages can be inserted without
recourse to renumbering. A second advantage of this approach is that the same stage can be
called out by several task_methods without having to duplicate the description of the stage.
task_
method_
sequence

methods
LIST

logistic_
task_method

Open hatch...

advisory_
task_method

Beware exhaust fume

build-up.

logistic_
task_method

Remove oil filter..

logistic_
task_method

Remove parts .

logistic_
task_method

Install new ..

Figure 6-26 Task Method Sequence

This is a simplified view in two major respects:

Rather than referencing a base_task_method (which is either a logistic_task_method or an

advisory task_method), it is allowed to refer to another task_method_sequence. This
means that sequences can be nested within each other. This is equivalent to saying, for
example: Stage 3 of this task is to do that additional sequence of tasks. (After we
consider the other types of structured_task_methods it will become clear that this opens
up many more possibilities than just sequences);
Instead of referring to a simple stage in a task, it is also possible to refer to another task.
This might then itself have multiple methods associated with it, dependent on different

81

situations, each of which might be formed as a sequence or other structure.

equivalent to saying, for example: Stage 3 of this task is to do all of that other tasks.

This is

Both of these are aimed at two significant requirements: the reduction of duplicated descriptions
(by enabling sharing of the same information) and the intelligent (electronic) processing of task
descriptions (so that the LSAR can act as a direct source for interactive manuals).
Now it is appropriate to look at all the options for structuring tasks:

task_method_sequence: lists stages or tasks to be carried out in order;

concurrent_methods: gives a group of stages or tasks to be carried out during the time it
takes to do the longest task;
decision_point : enables a choice between two different routes through the task,
depending on the result of a test condition;
looping_method: enables one or more stages to be repeated. There are three ways of
controlling the number of repeats and these can be combined:
- repeat_count : repeat the task a specified number of times;
- repeat_until: repeat the task until a test condition is met;
- repeat_while: repeat the task while a test condition remains true.
stop_task_method: used to terminate a particular path through a task.
Together these provide a capability not unlike a simple programming language so that tasks can
be structured flexibly and tracked or presented intelligently.
6.2.5.2.2 What is Used to Do the Job
The other key area associated with tasks is the resources necessary to complete the task. Here
the model centers around the link from the task to the resource. This is captured through the
task_resource_requirement entity. This essentially says: here is the resource needed for this
task. It has a subtype that allows for the quantity of the resource to be defined. Otherwise it is
assumed to be one of the resource.
There is a possibility to describe the requirement for the resource, to specify why it is needed and
the role that it will play in the task. The likely roles are: Spare parts, consumable, test
equipment, labor, safety equipment, calibration equipment, etc. The value for role is given as a
separate entity, enabling a standard set of values to be defined by a given project/organization
and referenced rather than duplicated.
The NCDM allows additional tasks to be associated with required resources. Thus if a particular
piece of equipment has to be calibrated before use, the calibration task can be given as a
supplementary task for using the equipment. (Because of this, calibration and similar tasks are
not treated differently from any other task in the NCDM.) Such a supplementary task can, of
course, have additional resources associated with it.
There are the following types of resource identified in the NCDM:

82

facility_or_infrastructure: may be a reference to a generic facility such as a 115V

power supply or a generic item of infrastructure such as a dry-dock, or a specific named
and located facility, such as British Aerospace Military Aircraft EF2000 assembly line
at Warton, UK;
information_requirement : some information required for the task.
This allows
reference to drawings, wiring diagrams, manuals, etc.;
personnel_skill: labor with known skill subject and grade;
task_training: established training for a given task;
additional_skill_requirement : training specific to the task but not available at present;
product_definition_usage: the task requires a part (or sub-assembly) that is already part
of an assembly (most likely that to which the task applies). This situation arises, for
example, when built-in test equipment is used;
structured_product_definition: the task requires an identified product.

Note that products (identified by a structured_product_definition) may play several different

roles in a task so an item can be a spare part and a resource for use in testing.
6.2.5.3 EXPRESS G Diagrams
EXPRESS G Diagrams and EXPRESS DEFINITIONS for the NCDM Task Descriptions (Task)
functions may be found in Appendix B .
6.2.6 Technical Documentation (InfoObj)
6.2.6.1 Overview
The basic viewpoint taken by the NCDM is that there will be all kinds of additional information
connected to aspects of the system/product data. Possible information types include:

Specification documents
Engineering and other drawings
Manuals for products, including support equipment, calibration tools, etc.
Maintenance manuals for major sub-systems
EDIFACT and E-Mail messages

In fact, there will be such a variety that no attempt has been made to sort these types of
information into pre-defined buckets. Instead, the NCDM provides a kind of library facility for
holding information and linking it to the detailed information covered by the rest of the model.
Such links may be very general in nature, simply indicating some relevance of the document.
6.2.6.2 Description
The information object area of the data model is very general in that it can be used to support
several different processes. Some of these are identified below by listing the input, controls, etc.
An additional column identifies the suggested target for an information link from the resulting
information object(s).

83

Input
1. Task and task
method,
resources, etc.

Control
AECMA
1000D spec

Mechanism
Technical
writer
(person)

2. Task and task

method,
resources, etc.

Various
(could be
AECMA or
in-house
defined
format)

Query and
report
function

3. Task and task

method,
resources, etc.

Various
(could be
AECMA or
in-house
defined
format)
Various
(could be
AECMA or
in-house
defined
format)

Query and
report
function

4. Many tasks
and associated
data

Technical
editors
and/or report
generators

Output
One information
object containing
the Data Module
according to
1000D DTD
Two information
objects, one
containing the task
description, and
one containing the
parameters/instruct
ions for the
query/report.
One information
object, one
containing the
parameters/instruct
ions for the
query/report.
Publication
collection
equivalent to a
maintenance
manual

Linked To
Task method
assignment,
Product

Task method
assignment,
Product

Task method
assignment,
Product

Figure 6-27 ICOM Notations

These can be described as follows:

This is the current traditional process of giving a technical writer access to the LSAR to
produce a data module. The NCDM lets the resulting SGML be stored in the same
database and potentially linked to the task description in the database.
The database is queried to produce a report that is the task description. Both the resulting
task description and the query are stored in the database. In the case of the query, this
allows the report to be updated as and when necessary.
In this case, the query only is held in the database and it is invoked when necessary. This
will support the use of the database as the source for an IETM.
A collection of task descriptions is published together as a maintenance manual.

This part of the NCDM is fundamentally simple but does not seem so because it contains many
recursive relationships. To help understand what this part of the NCDM supports, consider the
following analogy:

84

We have a collection of specialist papers (in electronic form) and a database that deals
with the same area.
The database includes a list of the papers and some key links from the list to the
corresponding data.
It also contains references to papers held in other collections.
New papers are created which are based on queries against the database and on the
existing papers and even the external references.
If a specific new paper is considered useful or valuable or is to be made available
externally, it is added to the collection of papers.
Occasionally an expert in the topic publishes either a single paper or a collection of
papers together. Extra information (such as the date of publication) is held in the
database for such publications.

This is roughly how the information object part of the model is structured:

Each paper, whether old or new, is an information object. New papers are added firstly
as information objects.
In the case where a new paper is the result of a query against the existing data, it is
marked as such (this is a derived information object).
The query itself is also stored (as an information object derivation). It is possible that the
query is more useful than the resulting paper and so only the query is kept (so it can be
re-executed on demand).
A paper that is not held in the local database is held as an information object too.
However, it has an external reference as content (using the curiously named document
entity).
The links from the papers back to the database are held using the information link entity.
Published papers are held using the publication collection entity that allows the date of
release and other similar information to be held.

6.2.6.3 EXPRESS G Diagrams

EXPRESS G Diagrams and EXPRESS DEFINITIONS for the NCDM Technical Documentation
(INFOOBJ) functions may be found in Appendix B .
6.2.7 Logistic Support Analysis
6.2.7.1 Overview
The descriptions given above cover the major elements of the NCDM. There is however much
more to logistics data. There are many aspects allowed for in the model that have not been
described so far. In particular, two further areas merit description here:

Scenario and role

Characteristics

85

6.2.7.2 Description
6.2.7.2.1 Scenario and Role
In the NCDM allowance is made for the likelihood that a system may be supplied to different
customers who may not only use it in different ways and environments but may also have
different resources (such as personnel skills) and different policies on maintenance. However it
is inevitable that the same failures will probably occur and that many tasks will be common
(e.g., the NH90 helicopter is intended for 11 different services across 4 nations). Rather than
force a separate copy of the database to be developed for each customer, the NCDM provides for
these differences through the scenario entity. This is then used in many places as the context for
assignments (such as a task to a product) to indicate that the assignment is applicable in the
scenario.
As a further refinement to this, the system may have multiple roles (for the NH90 these could be
submarine warfare, search and rescue, etc.) that lead to different maintenance requirements. A
scenario may include several roles.
6.2.7.2.2 Characteristics
It became clear during the creation of the NCDM that there is an enormous amount of data that is
covered by the existing legacy standards that is attached to the key ideas of product, anomaly,
and task (and the relationships between them). The data provides for many characteristic values,
varying from the familiar ideas, such as mean time between failures to much more obscure
values. Furthermore, many of these are provided twice (in the LSAR), once as a requirement
(from the assumed single customer) and later as a predicted value (provided by the
system/equipment supplier).
However, in the NCDM, these values can be specified as
requirements by different organizations (i.e., applying in a different scenario). Furthermore,
taking a view that goes through the life of the product, a measured value (based on fact rather
than prediction) may also be provided.
Given the potential number of such characteristics (see the combined data element lists of the
legacy standards), the NCDM takes a more general approach. Firstly, a characteristic (or one of
many subtypes) is used. In general terms, this defines a name, description, and value.
name

Characteristic

description
value
measure with unit

Figure 6-28 General Form of Characteristic

This is then assigned using a characteristic_assignment entity that allows the following to be
defined:

Who provided the value

86

What scenario does it apply to

Is it measured, required, planned, allocated or calculated
To what does it apply
scenario
organization

Characteristic
assignment

target
form

Characteristic

required
measured
...

Figure 6-29 Characteristic Assignment

Additionally, some characteristics may be qualified as being mean, maximum, or minimum
values. This is done by using a qualified_characteristic_assignment entity with an additional
attribute that allows the value to be qualified as being a mean value for example.
By using this approach, the NCDM is kept as an open model that can easily be extended as
additional characteristics can be added.
Currently there are many different specific characteristics defined as subtypes of the
characteristic entity. If we look at one example to see the way these work, most of the subtypes
will become clear.
Mean time between failures is a typical characteristic. It applies to a product (in the NCDM, a
structured_product_definition or an element) and may be specified as a requirement or as a
predicted value by a supplier. In the NCDM, this will be a qualified assignment (as mean) of
the time_between_failure characteristic.
6.2.7.3 EXPRESS G Diagrams
EXPRESS G Diagrams and EXPRESS DEFINITIONS for the NCDM LOGISTIC SUPPORT
ANALYSIS (LSA) functions may be found in Appendix B .
6.3 Developing a Life -cycle Cost Model
A life-cycle cost analysis is a method of calculating the cost of a system over its entire life span.
The analysis of a typical system could include such costs as System Planning and Concept
Design, Preliminary System Design Cost, Design and Development Costs, Product Costs,
Maintenance Costs, and Disposal Costs. This type of analysis often uses values calculated from
other reliability analyzes such as failure rate, cost of spares, repair times, and component costs.
Life-Cycle Cost (LCC) looks at the total cost of ownership of a process, system, or piece of
equipment. For installation of new equipment, a LCC analysis can assist in the decision-making
as to what most benefits the owner economically.

87

Likewise, a change or improvement to an existing process or equipment can be evaluated on

LCC to determine any cost benefit or justification for making the change. The LCC comparison,
between the existing condition versus the changed condition, can reveal payback period,
cumulative cost savings, or illustrate the change has little or no cost advantage and should not be
done.
The outcome of the analysis is dependent on the assumptions made or criteria used in the LCC.
Interest (or discount) rate, equipment life, inflation factor(s), operating, and maintenance cost
impact are just a few. The better this information, and ones persistence and integrity in using
good data, results in a higher confidence level of the outcome and success in finding
management support.
In LCC you are looking at the cash flow or money spent each year over the life of the asset -- in
effect, its total cost of ownership. Present value is a term and a formula that normalizes future
cash flows to a common point of reference that is todays dollar. By knowing the cash flow and
when it occurs, present value can be calculated. The present values of each option can then be
compared and the most beneficial option selected.
6.3.1 Life -cycle Cost Models
The following was extracted from "ANALYSIS of LIFE CYCLE COST MODELS For DoD and
Industry USE in Design-to-LCC by John C. Sterling.
6.3.1.1 Background
Design-to Life-Cycle Cost (LCC) has been mandated since the 1970s, but essentially ignored
or implemented on a selective basis. The main alternative, Design-to-Production Cost, ignores
the effects of Operating and Support (O&S) costs. These costs can often be 60% to 75% of the
total LCC of a system. Design-to-Production also ignores the LCC of various alternatives for
Level of Repair (LOR) options (i.e., the intended support policy) for each repairable item that
can vary widely depending on the repair/discard-at-failure policy selected.
6.3.1.2 A Summary of Design-to-LCC and Life -cycle Cost Models
Currently, Military Standards and Specifications and most U.S. DoD/Service approved LCC
models address only pieces of the LCC process. In particular, they fail to adequately address the
Design-to-LCC process during the front-end design analysis stage of a systems
development which occurs before a systems hardware design freeze. These Specifications
and Standards, and most LCC models, generate large amounts of non-compatible data that is
funneled to Program Managers who are expected to use all of this data to support major LCC
decisions (including LOR decisions) on their respective programs.
Therefore, Program
Managers in both Government and Industry badly need help to structure and analyze this large
amount of data so that they can project, early in the concept and hardware design stages, not only
the LCC of all available program options and combinations, but also the LOR for each of the
systems repairable items, i.e., its Line Replaceable units (LRUs) and Shop Replaceable
Units (SRUs)].

88

The LCC models available today are Database Managers that have the capability, to varying
degrees, to import, modify, analyze, integrate, and manage large amounts of data from many
different sources. From this data, reports are generated that display or project the overall effects
and results of program decisions on existing or alternative system designs, including risks
thereof. These LCC models store a baseline of program decisions that can also be used to
provide a valuable, systematic audit trail. One major advantage of a few (but not most) of these
available LCC models is their ability to provide early input to the front-end design analysis stage
of the Concurrent Engineering (CE) and ILS processes. This early LCC influence on design
ensures the systematic and simultaneous design of both the end-item system, and the processes
by which they are produced, tested/evaluated and supported for their life-cycle.
Both NATO Program Managers and Industry CE and ILS teams need greater awareness of the
availability and capabilities of these LCC models. This knowledge must include how they can
best be used to ensure that fielded systems are successful (i.e., meet reliability, maintainability
and availability goals), both initially and over the life-cycle, and remain within, or below, their
established LCC budgets.
6.3.1.3 Life -cycle Cost Model Characteristics
LCC models are primarily Database Managers that accept and manage large amounts of data
imported from other programs, such as:
1. Level of Repair Analysis Models (LOR/LORA), (e.g., EDCAS, MCLORA, MIL-STD1390, NRLA, OSSAM, etc.)
2. Reliability Models (e.g., R1, RPP, Relex, etc.)
3. Spares Optimization Models (e.g., VMetric)
4. Failure Modes, Effects and Criticality Analysis Models (FMECA)
5. Work Breakdown Structure (WBS) Models (e.g., SDU)
6. Constructive Cost Model for Software LCC Analysis (e.g., COCOMO)
7. LSAR Databases (MIL-STD-1388-2B), (e.g., LEADS, L-Base, OMEGA, SLIC, etc.)
8. External ASCII Databases (e.g., Bills of Material, Provisioning, Engineering, etc.)
The LCC models should be capable of modifying (i.e., adding-to, updating, changing),
analyzing, calculating, mixing, and then sorting this imported data into information.
This
information is usable to determine which approaches are the most economical in terms of
Design-to-LCC analysis, including LOR decisions, during the front-end design analysis
stage.
The primary differences between the available LCC models can be grouped into one of the
following categories:
1. How user-friendly each model is for collecting and entering input hardware
configurations and required data elements and in running each model.
2. Each models capability to sort, present and produce usable, comprehensive output
reports.
3. The flexibility and effectiveness in application of each model to a variety of other
design-to issues required in the front-end design analysis stage [e.g., design to a 2-level
89

4.
5.
6.

7.
8.

or 4-level support policy, evaluation of Commercial-off-the-Shelf (COTS) items,

determination of each repairable items LOR prior to imposing a design freeze and prior
to performing an LSAR, LRU/SRU sizing/packaging (partitioning analysis), and
pinpointing a systems Reliability Budget].
Initial cost to procure multiple sites, with multiple seats (users), and the initial and
follow-on training costs, for each model.
The quality and cost of technical support, including both initial and annual renewal costs,
plus model upgrade costs.
The cost savings and man-hours saved by using each model for a Programs hardware
system analyzes, vs. other models and/or processes; this includes the time needed to
research, collect and enter the systems structure and various data elements.
The resultant LCC savings by a Program through their Design-to-LCC application of
each model on their hardware system.
The willingness, capability, and cost of each models developer to modify its model to
meet specific DoD Services (e.g., U.S. Navy) Design-to-LCC requirements.

The five most popular U.S. DoD approved LCC models are as follows:
1.
2.
3.
4.
5.

The Equipment Designers Cost Analysis System (EDCAS) Model.

Automated Cost Estimating Integrated Tools (ACEIT) Model.
Flex + Life-cycle Costing Model.
The Cost Analysis Strategy Assessment (CASA) Model.
Constructive Cost Model (COCOMO) - Usable for software development LCC only.

90

7.0 TOOLS
7.1 Tools
Selection of user tools is as important as designing and implementing the Shared Data
Environment. These tools are an integral part for providing connectivity with a common basis
for sharing DS information in ready-to-use formats. It is important to note that data stored
within the SDE is useless unless it can be extracted, analyzed, manipulated, updated, formatted,
and presented in a user friendly manner by the appropriate software application tool.
In parallel with the analysis used to determine the SDE requirements, tool selection must be
considered within the SDE context. The ideal situation is to provide an environment that
separates information from applications and is based on open system standards. This will help
ensure future flexibility in upgrading to new software solutions as technology evolves.
7.1.1 Desktop User Applications
If information is to be effectively used, the user(s) must be able to apply appropriate application
software to it. The application(s) software is used to create, analyze, modify, simulate, or
interpret the information generated by business processes.
This software may address
information of a technical or a business aspect, e.g., a CAD/CAM modeler or an EDI transaction
generator.
There are as many application packages as there are processes and users. Some are so generic
that they may be better identified as an Infrastructure Desktop Element, such as office
automation products (word processors, spreadsheets, etc.). Some are very much discipline
specific such as a finite-element modeler. In any case, the applications provide the mechanisms
to the user to form and finalize the ultimate deliverable of the business process, i.e., the
information product or package.

91

Lo
inf gistic
orm s
ati
on

SDE

Product
information

7.1.2 Tool Sets

Design
information
$

Target Concept
$

$
$

$
$

Digital document
information in
standardized formats
modular
product related
contently structured

PaperDocumentation

Digital
documents
in various
proprietary
formats

Digital data
model based
information
in standardized
formats

Digital
documents
with presentation
separated form
content
in standardized
formats (SGML today)

Figure 7-1 Development Steps for Info rmation Management Capability

7.1.3 Areas for Tool Consideration
The number and types of tools is almost infinite. The below list is an example of some of the
areas that should be considered for tool applications. The list is nowhere near complete, but is
only a representative sample. Listing of commercial tools does not imply NATO endorsement or
preference.
Office Automation and Connectivity - The use of computer systems and
communications technology to perform general, every day tasks such as document
management, electronic mail, archiving and retrieval of text/graphics groups.
The
operation of systems in which a machine interface is required for the user to create, work
with, display, or delete records within a general office environment.

E-Mail
Word processing
Internet Browsers
Spreadsheets
Presentation Graphics
Office Suites
Electronic calendaring
Imaging

92

Desktop publishing

Groupware - Groupware is an umbrella term describing the electronic technologies that

support person-to-person collaboration. Groupware includes E-Mail, Electronic Meeting
Systems (EMS), Desktop Video Conferencing (DVC), as well as systems for workflow
and business process re-engineering (BPR).

Lotus Notes
Allaire Forums
Microsoft Exchange, NetMeeting

Electronic Document Management - A document management system incorporates

document imaging, archival, storage, text retrieval, workflow, OCR conversion, and fax
capabilities.

Xerox
Documentum (Documentum, Inc.)
OPTIX (Blueridge Technologies)

Configuration Management- (CM) - A process for establishing and maintaining

consistency of the configuration of a product over its life-cycle. This is typically
achieved through: (1) CM planning and management; (2) Configuration Identification
and documentation; (3) Configuration Change Management; (4) Configuration Status
Accounting; and (5) Configuration Audit.

CMStat
C*Gate
CMIS

Enterprise Resource Planning (ERP) - Enterprise Resource Management is accepted as

a broad term for the activities and software infrastructure that manage all of a companys
assets and resources, including such basic applications as general ledger, accounts
payable and receivable, as well as manufacturing, inventory, and human resources. It is
the process of managing an organizations functions, processes and methodologies to
achieve focus on customer driven delivery of product or service for the least cost and
highest value

Baan
PTC
SAP
People Soft

Product Data Management (PDM) - Product data management in the broad sense
addresses all data that directly or indirectly supports the concept exploration, design,
fabrication, assembly, testing, and life-cycle support of a product. This includes primary

93

and derived requirements and the cost/schedule information required to support tracking
of progress and timely corrective action.

Metaphase
Sherpa
Windchill

Drawing Computer Aided Design/Computer Aided Manufacturing (CAD/CAM) Software that enables developing digital master product models that makes it possible to
create, simulate, optimize, document, build, and test products within a single electronic
environment.

Catia
Optegra
AutoCAD
I-DEAS Master Series

Workflow Managers - Real-time work management software to track processes, create

built-in audit trails, and keep records on service quality and timeliness. Standards are
developed by the Workflow Management Coalition (WfMC).

JCALS (U.S. DoD and Computer Sciences Corporation)

InConcert (TIBCO Software, Inc.)
jFlow (Workflow Automation Corporation)

Performance Measurement
Metrics
Capability Assessment
- E-BAT (Britain)
- IDA-BAT (U.S.)
SEI CMM Assessment Tools
7.1.4 Configuration Management
Configuration management embodies two concepts: (1) the configuration management of items
and their defining technical data, referred to herein as configuration documentation; and (2) the
application of CM principles to digital data in general. Because, digital data management is
critical to the control of configuration documentation and therefore to the configuration
management of Weapon Systems, document management rules are integral to the CM process.
Configuration management is defined by the Electronics Industry Association (EIA) Standard
649 as a process for establishing and maintaining consistency of a products performance,
functional and physical attributes with its requirements, design and operational information
throughout its life. Figure 7-2 is a top-level activity model depicting the CM process showing:

Inputs - Information needed to initiate and perform the process

94

Constraints - Factors or information that inhibits or puts limitations on the process

Mechanisms/Facilitators - Information, tools, methods, and technologies which enable or
enhance the process
Outputs - Results that derive from the process or information that is provided by the
process.
Timing
Resources
Inadequate
planning and
preparation

CONSTRAINTS

INPUTS
Mission Need
Program Initiation
Syst Eng. Reqmts,
Funct Analysis,
Alloc & Synthesis
Logistics &
Maintenance Plans

Configuration
Management
Process

Performance
Measurements
Communication
Management support
Effective working
relationship among Govt &
Contractor CM, Program
Management, Systems
Engineering, Logistics &
Quality
Facilities
Resources
Training
Guidance Handbooks &
Standards

OUTPUTS,
RESULTS
Verified changes
Documented CM process
incorporated in all
consistent with planning
affected items,
Consistent & Appropriate:
documents
RFP & Contract CM/DM Status accounting data
Acquisition of data; EDI
base appropriate to
Items identified
each phase
Performance attributes CM-competent
identified and achieved
contractor base
Supported items
CM process
documented
performance measured
Identification and
& continuously
marking sufficient for
improved
support
Lessons learned
Proposed changes dispositioned Program image
expeditiously
enhanced

MECHANISMS/
FACILITATORS

Figure 7 -2 Configuration Management Process Model - Overview

The CM process encompasses:

Configuration items
Documents that define the performance, functional, and physical attributes of an item.
These documents are referred to as configuration documentation.
Other documents which are used for training, operation, and maintenance of an item
Associated and interfacing items used for training, operation, or maintenance of the
configuration item.

The CM process is embodied in rules, procedures, techniques, methodology, and resources to

assure that:

The configuration of the system and/or item (its attributes) is documented.

Changes made to the item in the course of development, production, and operation, are
beneficial, and are effected without adverse consequences.
Changes are managed until incorporated in all items affected

95

CM is applied to defense material, whether hardware or software, that are designated as

systems and configuration items. Systems generally refer to the level at which major
defense acquisitions are defined and managed. A configuration item (CI) may be an individual
item, or may be a significant part of a system or of a higher-level CI. It is designated at an
appropriate level for documenting performance attributes and managing changes to those
attributes. The concept of CIs has confused some people into thinking that the level at which
they are designated is the point at which configuration management stops. In reality, the CI level
is where configuration management really begins; the process encompasses, to some degree,
every item of hardware and software down to the lowest bolt, nut and screw, or lowest software
unit. This does not mean that the acquiring activity, the prime contractor, or even subcontractors
have visibility or configuration control authority over every part. Rather it means that some
organization within either the supply chain or the standardization process has configuration
documentation and change control responsibility for each part.
The attributes of configuration items are defined in configuration documentation. Configuration
baselines are established to identify the current approved documents. Configuration items are
uniquely identified. They are verified to make sure they conform to, and perform as defined in,
the configuration documentation.
Whenever a change is contemplated to an item, the effect of that change on other items and
associated documents is evaluated. Changes are systematically processed and are approved by
the appropriate change control authority.
Change implementation involves update and
verification of all affected items and documentation.
Information about item configuration, document identification and status, and change status is
collected as activities associated with the CM process occur.
This configuration status
accounting information is correlated, maintained, and provided in useable form, as required.
The responsibility for the CM process and supporting activities is shared between the
Government and the contractor and will usually vary according to the acquisition philosophy
(performance or design-based) and according to the phase of the life-cycle.
7.1.4.1 NATO and Contractor Roles in the CM Process
Both NATO and the contractor participate in the CM process. Since, NATO has ultimate
responsibility for the performance and configuration of the systems and equipment it acquires
and operates, NATO is always the configuration control authority for the top-level performance
attributes, and for selected lower level performance and design attributes that it specifies and
contracts for. Contractors may exercise a significant degree of authority for configuration
control during any or all phases of the life-cycle, depending on such factors as type of
acquisition, contractual requirements, and ownership of the data.
For a specific acquisition, configuration control authority means that the activity or organization
exercising that authority controls the configuration of the product and determines what changes
are to be installed or incorporated in that product.

96

It does not mean that NATO or any other configuration control authority can unilaterally
authorize change to configuration documentation throughout the life-cycle. Each configuration
document has a current document change authority (CDCA), i.e., an agency, activity, or
organizational entity that is responsible for the content of the document and is the only authority
that can effect changes to the document.
The concept of current document control authority (CDCA), introduced in MIL-STD-2549,
establishes that configuration control authority to effect a product configuration change under a
contract does not automatically mean that a change can be directed or made to a document for
which another organization is the controlling design activity and has content responsibility. An
activity that uses a product and its documentation, but is not the CDCA, is referred to as an
Application Activity (AA). An AA can only approve for use (adopt) the document, but cannot
direct changes to it. These concepts become increasingly more important as acquisition looks to
the commercial industrial base. It is central to the management of an automated information
system concerning documentation used by different application activities.
The CM process is applicable both to development of new systems and items and to
modifications of existing systems and items. A typical distribution of CM related roles is shown
in Table 7-1 ; responsibilities included for continuity that are not primarily configuration
management activity are italicized.

97

Table 7-1 Typical NATO and Contractor CM Roles and Responsibilities

Applies to Development of New Systems and to Modifications of Existing Systems
NATO

Contractor(s) or NATO Performing Activities

Solicits concept (Systems Engineering) studies. May

participate on Integrated Product Team (IPT)
Specifies desire performance attributes of a
system/Configuration Item (CI)

Performs system engineering studies. Determines

alternative system approaches
Proposes Items or Design Solution
Prepares and submits performance specification for
approval. May participate with NATO on IPT.

Selects Contractor or approves engineering change

proposal or modification request
Approves and baselines top level performance
configuration documentation (specifications) and acts
as current document control authority (CDCA) for
those performance specifications and configuration
control authority for the System/CI
Monitors contractor CM process via:

IPT participation

Metrics

Performance reviews
Baselines selected product performance configuration
documentation after verifying (e.g. FCA) that
performance requirements have been achieved
Continues as CDCA for selected performance
configuration documentation; may become CDCA for
other documentation as contractually established
Consistent with support approach for selected Cis,
baselines selected product (design) configuration
documentation after verifying (e.g. at a PCA for the CI)
that the design documentation matches the delivered
configuration
Continues as configuration control authority for the
System/CI during its life as a NATO asset and CDCA
for selected performance and design documentation, as
contractually established.

Initiates development. Incrementally baselines design

solution and acts as current document control authority
(CDCA) for released configuration documentation, e.g.
performance and detail specifications (below the level
controlled by NATO), engineering drawings,
engineering models, etc. for which another NATO
activity or commercial organization is not already the
CDCA)

Baselines product (design) configuration

documentation after verifying performance attributes
and consistency between item and configuration
documentation. (FCA & PCA)
Continues as CDCA for configuration documentation
which it does not transition to NATO

Similar cycle repeats for modifications

Similar cycle repeats for modifications

7.1.4.2 CM Benefits, Risks, and Cost Impact

Configuration Management provides knowledge of the correct current configuration of defense
assets and the relationship of those assets to associated documents. The CM process efficiently
manages necessary changes, ensuring that all impacts to operation and support are addressed.
The benefits of the process should be obvious but are often overlooked.
the benefits of CM from an industry view, as follows:

EIA-649 summarizes

Product attributes are defined. Provides measurable performance parameters.

Buyer and Seller have a common basis for acquisition and use of the product.

98

Both

Product configuration is documented and a known basis for making changes is

established.
Decisions are based on correct, current information.
Production
repeatability is enhanced.
Products are labeled and correlated with their associated requirements, design and
product information. The applicable data (such as for procurement, design or servicing
the product) is accessible, avoiding guesswork and trial and error.
Proposed changes are identified and evaluated for impact prior to making change
decisions. Downstream surprises are avoided. Cost and schedule savings are realized.
Change activity is managed using a defined process. Costly errors of ad hoc, erratic
change management are avoided.
Configuration information, captured during the product definition, change management,
product build, distribution, operation, and disposal processes [the equivalent of the DoD
acquisition life-cycle], is organized for retrieval of key information and relationships, as
needed. Timely, accurate information avoids costly delays and product down time;
ensures proper replacement and repair; and decreases maintenance costs.
Actual product configuration is verified against the required attributes. Incorporation of
changes to the product is verified and recorded throughout the product life. A high level
of confidence in the product information is established.

These benefits are equally applicable to NATO and industry.

Additionally, the effective
application of CM principles to defense products contributes to and enhances the partnering
environment desired between NATO and its suppliers.
In the absence of CM, or where it is ineffectual, there may be equipment failures due to incorrect
part installation or replacement; schedule delays and increased cost due to unanticipated changes;
operational delays due to mismatches with support assets; maintenance problems, down-time,
and increased maintenance cost due to inconsistencies between equipment and its maintenance
instructions; and numerous other circumstances which decrease operational effectiveness and
add cost. The severest consequence is catastrophic loss of expensive equipment and human life.
Of course, these failures may be attributed to causes other than poor CM. The point is that the
intent of CM is to avoid cost and minimize risk. Those who consider the small investment in the
CM process a cost-driver may not be considering the compensating benefits of CM and may be
ignoring or underestimating the cost, schedule and technical risk of an inadequate or delayed CM
process.
7.1.5 Interchange Specifications
7.1.5.1 Introduction
This document describes the NATO CALS Data Architecture (NCDA) Version 4.0 and methods
by which it can be used to identify and exchange information about a defense system over its
life-cycle through the use of Through Life Interchange Specifications (TLIS). The methodology
for developing TLIS and an example are detailed in Section 5. The NCDA is based upon the
concepts and activities identified and defined by the NATO CALS Through Life Business Model
(TLBM) Version 4.0. The TLBM represents improved business methods and efficiencies that
can be brought about by the use of information technology throughout the life-cycle of a defense

99

system to reduce costs, improve quality and reduce time cycles. The NATO CALS Concept of
Operations (NCOP) describes how to achieve the vision of a Shared Data Environment (SDE) in
support of a defense system through life. Taken collectively these tools and techniques can be
used on individual programs and across programs and provide a framework for CALS in NATO.
7.1.5.2 Background
The need to exchange and to share product related data has long been recognized, and the NATO
business requirements are to establish a standard method of identifying products and their
structure as a means of:

Exchanging information on product identity and product structure

Referencing related product information

For NATO a product is a major engineered asset with a significant life-cycle.1

The problems of achieving effective and efficient data exchange between the computer systems
of different organizations are well documented2. The underlying problem is that most computer
systems (even those developed by the same organization) are usually based on different data
structures, and they usually store the data in file formats or databases that are proprietary or
defined according to standards with restricted domains. Hence, being able to read data into
system A that was generated by system B, is often impossible. The data exchange standards
described by Bloor and Owen3 attempted to overcome these problems by defining publicly
accessible data structures and file formats which each system could map to. However, these
early standards suffered from other problems, including vendors defining their own subsets of
the standards with which they could easily map to, but which were usually different to the
subsets that other vendors mapped to. Hence, there were still significant data exchange
problems, even with the use standard formats.
The NATO CALS Handbook4 identifies standard formats for the digitization and delivery of
numerous types of typical deliverables such as Technical Data Packages and Technical
Documentation. However, even though this information is exchangeable in digital form, it does
not begin to solve the real business problem of keeping technical information in synchronization
with a changing product .
This critical need requires that the data management associated with product related information
be in synchronization with the configuration management of the product itself. This then leads
to the requirement to relate the two sets of data, product data and information about the product,
simultaneously. Sophisticated data models are required to achieve this.
1

Requirements for through-life standards: 13/11/97:; ISO SC4/TC184/WG3/T8; draft

document.
2
Product data Exchange; M S Bloor and J Owen; UCL Press London; 1995
3
Ibid.
4
NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March
1996.
100

In recognition of the requirements across industries to standardize product information, a new

data exchange standard the STandard for the Exchange of Product model data (STEP) began
being developed under the auspices of ISO, the international standardization organization. STEP
began development in 1984 and the first parts were released as full International Standards in
1994. The majority of the work to date has concentrated on the design, and to a lesser extent, the
manufacturing phases of the product life-cycle. Until late 1996, little attention had been paid to
the operation, maintenance, and decommissioning phases of the product life-cycle.
From a users perspective, STEP defines a series of specifications called Application protocols
(AP), which define self contained sets of data which can be exchanged between two computer
systems (thus avoiding vendor selected subsets and the myriad of problems which that caused in
the past). Where it is seen to be sensible, various conformance classes can be defined for each
AP. These conformance classes are further subsets of the total content of an AP, and are again
precisely defined in terms of specific data structures required by a conforming implementation.
The STEP standard uses a specific modeling language called EXPRESS that is machine
interpretable. STEP then, is an enabler for the intelligent management and exchange of related
product information. It is the standard the NATO CALS Office intends to use to support NATO
CALS requirements. This document describes the requirements in the form of a NATO CALS
Data Architecture (NCDA) and Through Life Interchange Specifications (TLIS) that are derived
from it.
7.1.5.3 NATO CALS Data Architecture
An important result of the 1995 NATO CALS Acquisition Workshop was that a consistent lifecycle product data model could be established to satisfy the need to manage change to a product:
The objectives for the development of the systems engineering data model were the alignment
with the international standards and the reflection of the TO-BE environment, including
concurrent engineering, the recursive systems engineering approach, requirements tractability,
version control and life-cycle change management.5
The workshop report further stated that a data model needed to support all of the processes
associated with a product throughout the life-cycle:
Working in a concurrent engineering environment, using the system engineering process,
addressing all the life-cycle processes, demands a data model that well supports the continuous
comparison between the actual product as it is being developed through all phases and the
requirements as they are defined and changed. The management of the different relationships
between all the elements of the model is a critical factor for the model to be successful.6

Acquisition Workshop Stage 2 Overview and Results; NATO CALS Management Board;
NATO Industrial CALS Group; NATO Unclassified; March; 1996; page 18.
6
Ibid.
101

The team that developed the generic high level model during the 1995 Acquisition Workshop
selected the ISO 10303 Standard for the Exchange of Product Model Data (STEP) as the
appropriate standard for a NATO CALS model.
The NCDA has been developed as a follow on to the NATO CALS Workshops and the NATO
CALS Data Model (NCDM) developed as part of the Pilot Project #1 activity that focused on the
Acquisition Logistics domain.
Considerable input has been received from the ISO STEP
community and experts from the NATO community, both governmental and industrial. The
architecture is currently conceptual and requires further development of the NCDM for
implementation. This is a planned activity as part of the NATO CALS Office 1998 Strategic
Plan and is discussed further in Section 3.4. The NATO CALS Office has chaired a ISO project
to identify the requirements in the area of Product Life-Cycle Support (PLCS). The activity is
complimentary to the NCDA and will provide the basis for the additional standardization
required to support the NCDA. Since the work of the ISO PLCS project and the NCDA are
connected, references are provided where appropriate. The NATO work is to be performed as a
contribution to the ISO STEP standards.
Once fully developed, the NCDA will consist of:

Consistent Core
Data Model(s)
Data Definitions
Documentation

The NCDA is independent of time, organization, and implementation, and it is not inherent in the
processes it supports. This enables the NCDA to support the entire life-cycle in a manner where
data is created only once and used many times. The following graphic depicts the NCDA.

102

Through Life Business Model

Operate

Support

Effectivity

Support

Inventory

State

Engineering

Management

Core

D
e
s
i
g
n

Configuration

Concepts & Referencing

Organisation

Task
Requirements
Identification
Item
Physical Product
Configuration
Effectivity
Anomaly
Administration
Documentation

Consistent
Linking &
Referencing

Product
ID

CM/Change
Control

Product
Maintenance

Produce
Management
ManagementInformation
Information
NATO CALS Data Architecture

Darch4_0.ppt

Figure 7-3 NATO CALS Data Architecture

The following sections describe the NCDA.
7.1.5.4 Through Life Business Model Analysis
The focus on through life product information was brought forward into the Through Life
Business Model (TLBM) and NCDA as the primary target for standardization. The inputs,
outputs, controls, and mechanisms of the TLBM Version 4.0 were analyzed to determine the
types and normalized categories of information that the TLBM focused on. While the TLBM is
not at a sufficient detail to determine the detailed data requirements of the information, a general
architecture can be derived from the TLBM that is focused on the product and its life-cycle. As
the TLBM is decomposed, the specific content of these data assemblies can be determined and
incorporated into the NATO CALS Data Model that is the instantiation of the conceptual NCDA.
The objective of the NCDA is to
satisfy the information management
information is created very early
throughout the complete life-cycle.
the information must be managed.

provide a structure to support the TLBM requirements and

goal of data created once and used many times. Product
in the life-cycle (e.g., requirements definition) and exists
In many armament programs, this represents decades that
This is less true for much of the management information

103

associated with programs that support the defense system. There is a significant amount of
information identified in the TLBM that is not product centric meaning that it does not require
product information as part of its content. An example is a budget. This type of information is
not currently detailed in the NCDA, but is part of the overall concept of managing information in
support of a defense system. The management category of the NCDA is large and merits further
study.
The categories of information in the NCDA are:

Management
Design
Production
Operations
Support

104

The following table details the classification of the information requirements in the TLBM into
these categories.
Table 7-2 TLBM Version 4.0 Data Assemblies by DA Categories
Management
Acquisition Strategy
Authorization
Budget
CM Plan
Contractor or Government Entity
Disengagement Intention
External Data and Information
ILS Plan
Information Management Plan
Mission Need Document
Operational Plans
Proposal
SDE Changes
Solicitation
Design
Defined Conceptual Options
Functional Architecture
Product Data
Quality Data
Validated Mission Need (NST)
Production
Accepted Defense System
Defense Product
New Defense System
Operation
Mission Feedback
Operational Defense System
Operational Feedback
Operational Performance Data
Support
Cannibalization Data

Allocated Funding
Available Funding
Business Plan
Concept of Operations
Contractual Mechanism
DS Life-cycle Strategy
Government/Industry Policies, Legal
System, International Cooperation
In-Service Goals
Mission Need
Multi-Disciplinary Groups
Procedures, Regulations and Standards
QA Plan
Shared Data Environment
Through Life Business Model
Configuration Data
Design Data
Operational Requirements
Proposed Conceptual Solution
Test Findings
Support (continued)
Disposal Data
End of Use Data
ILS Data
Non-Operational Defense System
Non-Operational Support System
Operational Support System
Retired Defense System
Support Data
Support System
Support System Performance Data
Transfer Data
Used Defense System

105

7.1.5.5 Architectural Core

The existing ISO STEP standards support a significant amount of product information,
particularly in the areas of design and to some extent production. The NCDA acknowledges the
existence of this capability and it will not be replicated in the NCDM. However, in order to
accurately link to and reference the various models (called EXPRESS schemas in STEP), a
consistent and persistent core model is required. The components of the Core are not only
individual data entities, but are elementary EXPRESS schemas that will be called modules for
purposes of this report.
The following sections identify the modules of the NCDA Core.
7.1.5.6 Product ID
Product Identification is at the center of the Core and essential in identifying the correct product.
This module supports the unique identification of a product, which is the unique identification of
a product instance or a group of instances. Among the requirements for this module are:7
1. Identification, within a specific domain, of a product and its components at
multiple levels e.g.:
part numbers
serial numbers (instances of parts)
batch number (unique to a set of instances)
classification schema (e.g., NATO Stock Number - Form, fit and function)
2. Need to hold multiple identifiers for each of the above
3. Identification of context for "uniqueness" - how big, what are the boundaries of
"global"
4. Need to link parts identifier to related identifiers:
ID of part requirement
ID of part design/model
Drawing id
Number used to sell part
"assembled number"
"where used" ID
5. Ability to deal with encoded part number, e.g., Bar code (UPC)
6. Identification by classification (e.g., group technology).
7.1.5.7 Organization
Organization is necessary to know the identity of the organization assigning the Product
Identification. This module supports the unique identification of a product.
The requirement is stated as:

Requirements
document.

for

through-life

standards:

106

13/11/97;

ISO

SC4/TC184/WG3/T8;

draft

Need to know the organization, which assigned the identifier.8

7.1.5.8 Configuration
Configuration is necessary to identify the structure and the relationships among components of
the product. The following are requirements for the module:9
1. Need to define product by multiple, hierarchical breakdowns, e.g.:
Assembly structure
Zonal structure
Functional structure
Program specified structure
2. Need to distinguish applicability of breakdowns to different life-cycle stages:
(as built/as assembled/as fielded/)
3. Need to maintain product configuration history
4. Need to distinguish between different states which can exist at a point in time e.g., actual/permitted (states and combinations)/required
5. Need to identify that elements of the structure may be replaced by others:
Supercedence
Alternates/Alternatives
6. Need to identify and distinguish different versions of a product
7. Need to represent breakdown to different levels of detail e.g.:
Configuration Item
+ parts
+ material (BoM)
+ source of material (batch no.)
8. Need to control configuration of Interfaces between separate products
9. Need to hold information about Configuration anomalies
10. Configuration control of software.
7.1.5.9 State
State is necessary to know the condition of the product (at a point in time). The requirement is:
1. Need to identify a given configuration state.10
7.1.5.10 Effectivity
An effectivity is the identification of the valid use of an aspect of product data. An effectivity
may be tracked by date, serial number, or lot number. (ISO 10303-41)
8

Requirements for through-life standards: 13/11/97:; ISO SC4/TC184/WG3/T8; draft

document.
9
Ibid.
10
Requirements for through-life standards: 13/11/97:; ISO SC4/TC184/WG3/T8; draft
document.
107

7.1.5.11 Linking and Referencing

The NCDA is based upon the principle that the Core model can be used consistently within
STEP to provide for linking and referencing between data models, typically in the form of
Application Protocols (AP). The ISO PLCS identified the following requirements:11
Referencing and Link (our "hooks" must have "eyes" elsewhere.)
1. Need consistent use of core at three levels:
when developing a schema
when implementing a schema
when transferring information from any implementation to another
2. Keys and pointers. Identifiers as surrogate for data object
3. Need capability to navigate between the modules which use the core
4. Need business rule to ensure consistent identifiers across
implementations

multiple

7.1.5.12 Product Life -cycle Support (Logistics)

As a military alliance, NATO has a particular interest in Cooperative Logistics. The following
is taken from a NATO paper on the topic:
Many forms of logistics co-operation exist, in many areas, between many partners, at many
levels and for different purposes. As the provision for logistics was a national responsibility, the
large majority of information systems are built to support national needs. Whenever logistics cooperation requires the exchange of information, specific designed to purpose interfaces are
built. With the increase in co-operation as a result of the drive for more effective and efficient
logistics solutions, within the context of the aim to make logistics a collective responsibility, the
number of logistics co-operation programmes equally increases and with that, the number of
proprietary interfaces, database as well. It is quite obvious that this is not the most effective way
of proceeding, especially as the Armed Forces are more and more confronted with multiple, noncompatible interfaces.12
7.1.5.13 Within the NATO Context
Within the NATO Context then, requirements exist to exchange specific sets of information to
support communications between:

Those responsible for defining the requirements for the end-item or system
Users and maintainers of the end-item or system (such as governments)
Manufacturer and assembler of the end-item or system

11

Ibid.
THE NATO LOGISTICS ARCHITECTURE PLAN or the need for conceptual logistics
standardisation; NAMSA; NATO Unclassified; 6/30/97; page 1.
12

108

Suppliers of parts and/or related equipment.

A key element of the NATO CALS Framework is a specific data model that was originally
developed to harmonize the requirement of three existing military standards, MIL-STD-1388-2B
(US), AECMA 2000M (Europe) and AECMA 1000D (Europe). This work was based upon the
results of a NATO CALS Workshop on Acquisition Logistics conducted in 1993. This model,
named the NATO CALS Data Model (NCDM), has been encoded in EXPRESS and is intended
to be the instantiation of the NCDA. It is currently limited in that it does not meet all of the
requirements of the core, contains certain legacy characteristics, and needs to be modularized
in accordance with the NCDA. It is part of the NATO CALS Office Strategic Plan to modify the
NCDM in accordance with the NCDA.
This focus on Logistics is reflected in the NCDM and is the foundation for the instantiation of
the NCDA. It is also the major input to the ISO STEP work on product life-cycle support.
7.1.5.14 Information Sharing and Exchange
The NATO CALS Handbook13 contains information and guidance for selecting and using
information standards for general types of digital information exchange. The purpose and focus
of the NCDA is to go beyond general information exchange and focus directly on clearly defined
data elements and relationships associated with a product as defined by the data models in STEP
and the NCDM. Data models are powerful tools that are used to define information objects and
the relationships amongst them. With existing technology, the utilization of an EXPRESS data
model enables significant advancements in the ability to use information beyond that of simple
data exchange. Systems utilizing a common data model either as an internal structure or as a
system interface can communicate directly and operate as a single logical unit, rather than
separate distinct systems that require translation and physical movement of data to perform
operations. Applications built upon the data model can then operate anywhere in the systems
environment and access data through the model in ways not possible in data exchange, which,
for example, must rely on external referencing to identify information and relationships
(e.g., LCN to product). In a data model, this referencing is inherent within the model. These
powerful concepts represent and enable new ways of doing business.
The NCDM was built to take advantage of these powerful concepts and enable improved access
and management of information about a product and its support throughout the total life of the
product, not only during acquisition.
Much of this information is created, stored, and
managed, within the industrial enterprise supporting the defense system (i.e., product and its
support system).
The NCDM will change the way industry creates, manages, and makes available product and
logistics information. It will also change the nature of the interfaces between all the enterprises
associated with a defense system throughout its life-cycle. Traditional forms of data exchange
can be supported through data models, and the analysis of the TLBM along with the utilization
13

NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March
1996.

109

of the NCOPS will provide an Information Management Plan (IMP) that identifies the optimal
use of EXPRESS schemas and the NCDM.
The preferred method of data exchange for the NCDA/NCDM is defined in the STEP Standard
as a Part 21. The details concerning STEP Part 21 are covered later in this document. These
physical files can be transported by a wide variety of information envelopes from attachments
to EDI messages, to MIL-STD-1840 and Internet FTP (File Transfer Protocol), as well as on
physical media such as magnetic disks. The Part 21 form of exchange preserves the relationships
between the entities in the data model so that they can be retained and utilized in the receiving
system. Some forms of exchange do not support this important feature. In addition to a STEP
Part 21 physical file transfer between systems, the following types of exchanges can be
supported using the NCDM in a CALS Environment.

Bulk Data Transfer

Data Lists
Tables
Reports
Direct Access
Dynamic Link

Each of these is described in the following sections.

7.1.5.14.1 Bulk Data Transfer
The capability to exchange an entire database of information can be supported by transferring an
entirely populated NCDM using a Part 21 Exchange.
7.1.5.14.2 Data Lists
Data Lists are simple lists of data elements and values. This form of transfer usually does not
preserve the relationships between entities
7.1.5.14.3 Tables
Tabular information can be used to transfer information in a way to preserve relationships such
as relational tables. In some cases, this form of transfer can be used to directly import
information into databases and spreadsheets.
The receiving system must unambiguously
understand the tables for this to be used, and it is not as potentially powerful a transfer
mechanism as a Part 21 exchange.
7.1.5.14.4 Reports
Reports can be generated from the NCDM and formatted in such a way as to be humaninterpretable. The usual application of this format is to extract data from the NCDM into a
document that is intended to be read. There are techniques to do this automatically and remotely
in response to system queries.

110

7.1.5.14.5 Direct Access

Direct access to NCDA data can be provided through a service such as the Contractor Integrated
Technical Information Service (CITIS)14 and Internet Home Pages. In this case, the Interchange
Specifications are actually Interface Specifications.
7.1.5.14.6 Dynamic Link
Dynamic linking of information systems that use the NCDM as a systemic interface is a
powerful tool to push information via Part 21 files to other systems. This can be used to
distribute information to a number of recipients in a distributed environment.
7.1.5.14.7 Through Life Interchange/Interface Specifications
Interchange Specifications can be used repeatedly during a scenario and over the life-cycle of a
defense system. For example a Supportability Characteristics data assembly from a through
life perspective shows that it would be utilized several time during the life time of a defense
system:

From Government to Contractor with the set of targets for supportability;

From Contractor to Government with the predicted outcome;
Several times between the two with the test achievements;
From Contractor to Government at acceptance/handover;
Several time between the two (with the aim of monitoring) the actual/achieved
supportability.

The generalization of these can be built derived into the following states:

Targeted
Predicted
Tested/Evaluated
Accepted
Actual

7.1.5.15 Methodology
A methodology for determining Through Life Interchange Specifications (TLIS) using the
TLBM is the first step in developing a Concept of Operations for a Program. It yields the
information requirements that are input to the programs Information Management Plan (IMP).
Refer to the NATO CALS Concept of Operations for details on the IMP.

14

NATO CALS HANDBOOK; NATO CALS Office; 2nd Draft; NATO Unclassified; March
1996; Section 5.

111

The following steps are recommended to develop TLIS for a program.

1.
2.
3.
4.
5.
6.
7.
8.

Define Scenario
Define Government/Industry Interface
Apply Scenario to TLBM
Determine Purpose of TLIS
Select Type/Style of Exchange
Determine Nature of the TLIS
Define Content of TLIS
Refine Scenario

The steps should be used recursively because both at the scenario level and at the activity level
the government-industry interface and relationship had to be examined and fed back/refined at
the previous steps. The following graphic depicts this recursive approach.

SCENARIO

IS

GVNT-IND INTERFACE

TLBM

Figure 7-4 Recursive Approach

Once the process has produced sufficient results, the TLIS requirements can be translated into
STEP Part 21 encodings. This is described in later sections.
The following sections describe the steps in TLIS analysis methodology.

112

7.1.5.15.1 Define Scenario

The context in which the TLBM is implemented should be established. There are several
obvious high-level scenarios for the TLBM in a NATO and Multi-National programmes.
Examples of these are:

A complete defense system life-cycle program

Acquiring an existing defense system
A mid-life update of a defense system
Renting defense system hours

As you apply a scenario to the TLBM and make decisions while doing so, you will need to revisit the scenario recursively to refine it. The scenario should be defined as unambiguously as
possible.
7.1.5.15.2 Apply the Scenario to the TLBM
Apply the scenario to the TLBM with the aim of developing a tailored business model by:
1. Analysing applicability of activities and their definitions;
2. Analysing applicability of ICOMs and their definitions;
3. Consolidating the tailored business model.
After selecting and defining activities and ICOMs, the connection between applicable activities
has to be re-established. Some activities may be found not be applicable for the scenario and
tailoring of the TLBM may be required.
7.1.5.15.3 Define Government/Industry Interface
The interfaces between government and industrial participants in the programme may be
different for each activity, and will most likely change over time. The nature of the interface will
impact the decision on the type of interchange selected. Refer to the NATO CALS Concept of
Operations for details on analysing the implementation of a CALS Environment for a
programme. The interfaces between all participants should to be defined at the lowest possible
level in the tailored business model.
7.1.5.15.4 Determine TLIS Purpose
The question of how the TLIS is to be used should be analysed.
organisational and workflow analyses.

This can even include

7.1.5.15.5 Select Type/Style of Exchange

The Type/Style of exchange can be determined at this point. This can include the following:
STEP Part 21 File (Based upon NCDM )
Bulk Data Transfer

113

Report
Data List (e.g., tabular data and values
Tables (e.g., relational table information )
Access
Dynamic Link

7.1.5.15.6 Determine Nature of the TLIS

Select the type of TLIS to be used for the exchange. The
Standard (e.g., STEP AP 203)
Part of existing library (e.g., a set of STEP Part 21 TLIS for re-use)
Custom STEP Part 21 TLIS
7.1.5.15.7 Define Content of TLIS
Once the TLBM is tailored for the scenario, each ICOM should be analysed for its specific
content. For those TLIS that contain product related information based on the NCSDM the
EXPRESS definitions can be located in the NATO CALS Data Dictionary. The goal of NATO
CALS is to have a library of TLIS in STEP Part 21 format for re-use. Until this exists, the STEP
Part 21 encodings need to be developed for the requirements generated from the TLIS
methodology. The following sections describe the development of STEP Part 21 files and a
working example based upon the NCDM.
7.1.5.15.8 Develop STEP Part 21 Definition
An Interface Specification is intended to properly define the capabilities required for these
exchanges. This requires a definition of:
1. The objective - in terms of business need.
2. The data content written in the EXPRESS language (ISO 10303-11)15 and specified in
terms of a well-defined subset of the NCDM16.
3. The rules in terms of additional constraints imposed on the data content, which are
either specific to the business objective or which enforce common conventions that apply
to all Interface Specifications.
The format in this case the STEP file format (ISO 10303-)17 with user-defined extensions.
15

ISO 10303-11, 1994; Industrial automation systems and integration Product data
representation and exchange Part 11: Description methods: The EXPRESS language reference
manual.
16

In ISO 10303 (STEP), the concept of a conformance class serves a similar purpose in identifying a subset of an
AP. However it does not add any constraints, nor do they identify a specific implementation form.
17

ISO 10303-21, 1994; Industrial automation systems and integration Product Data
representation and exchange Part 21: implementation methods: Clear text encoding of the
exchange structure.
114

ISO 10303
Standard for the
Exchange of
Product Model
Data

N
C
D
M

NATO Rules & Tailoring

STEP Part 21 Files

I
n
t
e
r
c
h
a
n
g
e

S
p
e
c
i
f
i
c
a
t
i
o
n
s

Figure 7-5 NATO CALS Standardization Architecture

The following sections review the elements of the STEP technology that will be used in defining
Interface Specifications. These fall into two main categories: use of the EXPRESS language and
use of the STEP file format. These will be described separately and the example given later will
show how they relate to each other.
7.1.5.16 Use of EXPRESS
The NCDM is defined in the EXPRESS language. To define the Interface Specifications we will
use two different facets of the language. The first is that necessary to select a subset of the
NCDM. The second covers the ability to impose rules on valid sets of data.
7.1.5.17 EXPRESS Import Facilities
EXPRESS provides two related mechanisms for defining new schemas that select entities and
other constructs from an existing schema. These are:
The USE statement
The REFERENCE statement 18
These are formally described in ISO 10303-11 in clause 11. Only an informal description will be
given here.

18

In common with STEP this paper adopts the convention of specifying EXPRESS language
key words in UPPER CASE.
115

The general effect of both statements is to import some items from one schema into another. See
below for a small example. The two statements differ in that the legitimate instantiations of the
data sets vary according to which was used. If the USE statement is used, the imported entities
are considered to behave as if they had been declared in the schema and may exist independent
of other entities indirectly, which is either imported by USE or declared in the schema. (In the
case of the Interface Specifications, there will be no entities in the second category.)
For both USE and REFERENCE, any entities and types that are required for the attributes of the
entities named but are not explicitly named are considered to be implicitly REFERENCEd.
NOTE: The following is a simplified example loosely based on entities from the NCDM. It
should only be used as an illustration of how the USE and REFERENCE mechanisms work. 19 In
the case of REFERENCE the imported entity can only exist if it is referenced by another
ENTITY.
SCHEMA base_model;
ENTITY mission;
in_scenario : scenario;
description : STRING;
name : STRING;
mean_duration : OPTIONAL time_measure_with_unit;
END_ENTITY;
ENTITY scenario;
user : STRING;
id : STRING;
description : STRING;
operating_location_count : OPTIONAL INTEGER;
number_of_systems : INTEGER;
END_ENTITY;
ENTITY time_measure_with_unit;
measure : REAL;
unit : STRING;
END_ENTITY;
ENTITY person;
name : STRING;
END_ENTITY;
END_SCHEMA; -- base_model
-- New schema using things from the base schema
SCHEMA Interface_Specification;
USE FROM base_schema (mission);
REFERENCE FROM base_schema ( scenario );
END_SCHEMA;

19

Such an ENTITY may of course be dependent on some other ENTITY through its attributes.
116

In the previous example, the following is the result in the new schema:
Entity
Mission
Scenario

time_measure_with_unit
Person

Result
Included. May be independently
Included. May not be independent instantiated.
(Would have been implicitly REFERENCEd
because of its use in the in_scenario attribute of
mission.)
Included by implicit REFERENCE from
Not included.

7.1.5.17.1 EXPRESS Rules

A major aspect of EXPRESS is the ability to define rules that a data set (such as an exchange
file) should satisfy to be correct. The EXPRESS language provides equivalent power to many
programming languages for defining such rules.
As an Interface Specification is inevitably a restricted subset of information to meet specific
objectives. It therefore makes sense to allow for the definition of rules specific to an Interface
Specification. Given that no new entities will be defined in an Interface Specification, the only
EXPRESS construct that is applicable is the RULE.
RULEs can be used for the following types of constraint:

Population constraints (that deal with the whole sets of entities)

Value constraints (to ensure that all instances of a given entity meet a condition)
Uniqueness constraints (to ensure that all instances of a given entity are different)
Relationship constraints (to ensure appropriate combinations of related entities)

Examples of the first two of these are given below, based on the schema used above:
RULE only_one_scenario_allowed FOR (scenario);
WHERE
one_scenario_only: SIZEOF(scenario) = 1;
-- returns false if there is not exactly one scenario (population constraint)
END_RULE;
RULE positive_systems_count FOR ( scenario);
WHERE
systems_count: SIZEOF( QUERY(each_scenario <* scenario |
each_scenario.number_of_systems < 1)) = 0;
-- returns false if there are any scenarios with less number_of_systems less than 1
END_RULE;

Rules such as these can be specified in the same schema that USEs or REFERENCEs the
NCDM entities.

117

7.1.5.17.2 Use of ISO 10303-21

STEP provides a file format that is based on a mapping from the EXPRESS language. It has two
major components:
A header which deals with information about the file;
A data section that contains data according to an EXPRESS schema identified in the
header section.
An example file (corresponding to the schema given previously) looks like this:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((This file contains a sample STEP model),
1);
FILE_NAME(Example STEP File,
1997-12-01T16:20:00,
(JOHN DOE,
ACME INC.,
METROPOLIS USA),
(ACME INC. A SUBSIDIARY OF GIANT INDUSTRIES,METROPOLIS USA),
CAD STEP Processor Version5,
In house Logistics System Release 4.0,
Approved by James R. Crawford);
FILE_SCHEMA((BASE_MODEL));
ENDSEC;
DATA;
#1=MISSION(#2,Search and Rescue, SAR,#5);
#2=IN_SCENARIO(US Navy,1,East Coast mainland USA,12, 20);
#5=TIME_MEASURE_WITH_UNIT(15.0,Hours);
ENDSEC;
END-ISO-10303-21;

The header section is required to contain the three entities shown in the example above. These
are:
1. The file_description specifies the version of this part of ISO 10303 used to create the exchange
structure as well as its contents.
2. The file_name provides human readable information about the exchange structure.

3. The file_schema entity identifies the EXPRESS schemas that specify the entity instances in the data
section. The schema_identifiers attribute is constrained to contain exactly one schema_name .

The three entities are defined according to the following EXPRESS schema:
SCHEMA header_section_schema;
ENTITY file_description;
description : LIST [1:?] OF STRING (256) ;
implementation_level : STRING (256) ;
118

END_ENTITY;
(*
description: an informal description of the contents of this exchange structure.
implementation_level: an identification of the required capability of the system to process
the data in this exchange structure.
*)
ENTITY file_name;
name : STRING (256) ;
time_stamp : STRING (256) ;
author : LIST [ 1 : ? ] OF STRING (256) ;
organization : LIST[ 1 : ? ] OF STRING (256) ;
preprocessor_version : STRING (256) ;
originating_system : STRING (256) ;
authorization : STRING (256) ;
END_ENTITY;
(*
name : the string of graphic characters used to name this particular instance of an exchange
structure.
time_stamp: the date and time specifying when the exchange structure was created.
author: the name and mailing address of the person responsible for creating the exchange structure
organization: the group or organization with whom the author is associated.
preprocessor_version: the system used to create the exchange structure, including the system
product name and version.
originating_system: the system from which the data in this exchange structure originated.
authorization: the name and mailing address of the person whom authorized the sending of the
exchange structure.
*)
ENTITY file_schema;
schema_identifiers : LIST [1:1] OF schema_name;
END_ENTITY;
TYPE schema_name = STRING(1024);
END_TYPE;
(*
schema_identifiers : the schema(s) that specify the entity instances in the data section.
*)
END_SCHEMA;
(*

Outside the scope of STEP, this header information can be extended by means of user-defined
entities to carry additional data about the exchange, rather than the product itself that is referred

119

to within the data section of the file. The concept here is that the exchange file is itself a
document and needs to be identified and controlled as such.
For the purposes of Interface Specifications, the following concepts/entities could also be
included:
1.
2.
3.
4.
5.
6.

Project/contract reference within which the exchange takes place

Version of the file/exchange
Status draft, approved, released, obsolete
Distribution list of recipients, reasons, dates
Security classification - implying an Availability list
Message other free format text

7.1.5.18 Common Conventions for all Interchange Specifications

The NCDM has been written with its eventual inclusion in an ISO standard in mind and for use
in databases. Consequently, it does not impose many constraints or business rules such as might
be expected for a model that carries the NATO badge. Such business rules might for example
ensure that NATO conventions for part numbers are followed.
In order for the Interface Specifications to work in a compatible fashion and serve their intended
joint purpose along side databases and other software based on and around the NCDM, it is
necessary to impose some of the missing rules. These can be defined using the RULE facility of
the EXPRESS language described previously.
The use of a second schema for these rules may seem contrived but it has been found extremely
valuable to have the definitions of the information content of a domain separated from the
business rules that relate to it. Such an approach facilitates change and does not force the
business rules to apply to others who have information with the same content.
7.1.5.18.1 Example of Conventions
Please note that the following is intended to show how to specify the common conventions and
only includes a simple rule restricting the length of identifiers for product and product version.
This obviously does not represent anything like the full set of possibilities. At the time of writing
the necessary requirements analysis has not been undertaken.
SCHEMA nato_cals_data_model_plus_conventions;
USE FROM nato_cals_data_model; -- imports all of it
(* define new rules for common conventions *)
RULE product_identification FOR ( product, product_version);
WHERE
id_length: SIZEOF(
QUERY(each_product <* product | LENGTH(each_product.id) > 32)
120

) = 0;
-- returns false if there are any products with id longer than 32 characters
id_length: SIZEOF(
QUERY(each_version <* product_version |
LENGTH(each_version.id) > 32)
) = 0;
-- returns false if there are any product_versions with id longer than 32 characters
END_RULE;
-- more rules as appropriate here
END_SCHEMA;

7.1.5.19 An Example Interchange Specification

The following brief example is based on an activity identified as part of the NATO Framework
project.
7.1.5.19.1 Objective
This Interface Specification is intended to support the exchanges identified for the following
activity from the NATO CALS Framework activity model:
DEFINE SUPPORTABILITY CHARACTERISTIC REQUIREMENTS
This activity was derived from the following:

Para 2.1.6.3 Establish Supportability Targets (GE ALS)

Para 2.1.6.4 Establish Supportability Design Constraints (GE ALS)
Sub-task 205.2.4 Supportability Objectives and Associated Risks (00-60/1388-lA)
Sub-task 205.2.5 Specification Requirements (00-60/1388-lA)

7.1.5.19.2 Activity Overview

To identify required design and operational characteristics and restrictions which affect the
product supportability.
7.1.5.19.3 Activity Description
Establish supportability, cost, environmental impact and readiness objectives and related
customer or design requirements for the product. Identify the risks and uncertainties involved in
achieving the objectives established including risks associated with new technology planned for
the new product (hardware and software). The design constraints will address, but are not
limited to, those related to hazardous material, hazardous waste, and environmental pollutants.
Customer constraints such as the required use of existing equipment or facilities shall be
considered.
121

These requirements and constraints shall be both quantitative and qualitative and are required for
contractual information and as input to various project documentation including the ALDB or
equivalent format approved by the project.
7.1.5.19.4 Activity Methodology
If required, further detail on the functionality and methodology behind this activity for the
acquisition logistic requirements in defense equipment procurement may be found in the US
MIL-STD-1388, UK DEF STAN 00-60, and GE ALS.
7.1.5.19.5 Mapping of Required Data into the NCDM
The following table shows the data elements required and the elements of the NCDM that
correspond to them:
DED
LSAR Name
001
REQUIRED ACHIEVED AVAILABILITY
009
013
019
021

ADDITIONAL REQUIREMENTS
REQUIRED ADMINISTRATIVE
AND LOGISTIC DELAY TIME
ALTERNATE LCN CODE
ANNUAL NUMBER OF MISSIONS

022

ANNUAL OPERATING DAYS

023
064
096
164

ANNUAL OPERATING REQUIREMENTS

CREW SIZE
END ITEM ACRONYM CODE
REQUIRED INHERENT AVAILABILITY

199
203
222

LSA CONTROL NUMBER (LCN)

LCN TYPE
REQUIRED MAXIMUM TIME TO REPAIR

223

TECHNICAL MEAN ACTIVE MAINTENANCE

DOWNTIME
REQUIRED TECHNICAL MEAN TIME
BETWEEN FAILURE
REQUIRED TECHNICAL MEAN TIME
BETWEEN MAINTENANCE ACTIONS
REQUIRED TECHNICAL MEAN TIME TO
REPAIR
MEAN MISSION DURATION
MEAN MISSION DURATION MEASUREMENT
BASE
NUMBER OF OPERATING LOCATIONS
REQUIRED OPERATIONAL AVAILABILITY
RELIABILITY OPERATIONAL REQUIREMENTS
INDICATOR

229
230
236
228
238
262
273
275

122

Model Reference
achieved_availability
assigned
with
"Required
narrative_characteristic.description
administrative_and_logistic_delay_time
assigned as "required,maximum"
alternate_element_relationship.related.id
scenario.usage.
annual_number_of_missions
scenario.usage.annual_number_of_operating
_days
property assigned as required to element
property
project_breakdown_assignment.project
inherent_availability
assigned
with
"Required"
element.id
element.definition.form
distribution_based_period
(assigned
as
required maximum)
mean_maintenance_downtime (assigned as
required mean)
time_between_failure (assigned as required
mean)
time_between_maintenance_tasks (assigned
as required mean)
time_to_repair assigned as (required mean)
mission.mean duration
measure_with_unit.unit_component
scenario.operating_location_count
operational_availability assigned to scenario
scenario.usage[].name

DED
286
376
450
454

LSAR Name

Model Reference

INDICATOR
REQUIRED PERCENTILE

distribution_based_period.percentile
(assigned as required maximum)
organization
no longer required

SERVICE DESIGNATOR CODE

ADDITIONAL REQUIREMENTS TEXT
SEQUENCING CODE
TOTAL SYSTEM SUPPORTED

scenario.number_of_systems

7.1.5.19.6 The Use Study Interface Specification Schema

For the purposes of this example, it is assumed that the source for the necessary entities is a
single schema called the nato_cals_data_model_plus_conventions. This schema would include
the rules defining common conventions for all NATO Interchange Specifications.
The example also shows one rule applicable to the Use Study Interchange Specification only. As
the full requirements for the restrictions appropriate to this Interchange are not defined, only two
rules are given as examples. The first rule limits the number of products for which requirements
are being specified to one and one only. The second requires that all characteristic assignments
point to the one product via its product definition.
SCHEMA nato_use_study_Interchange_specification;
USE FROM nato_cals_data_model_plus_conventions (
achieved_availability,
administrative_and_logistic_delay_time,
alternate_element_relationship,
breakdown,
characteristic_assignment,
distribution_based_period,
element,
element_definition,
inherent_availability,
mean_maintenance_downtime,
mission,
narrative_characteristic,
operational_availability,
organization,
product,
product_version,
product_definition,
project_breakdown_assignment,
property,
role,
scenario,
scenario,
time_between_failure,

123

time_between_maintenance_tasks,
time_to_repair
)
-- additional rules specific to this Interchange Specification
RULE only_one_product FOR ( product);
WHERE
only_one: SIZEOF( product) = 1;
END_RULE;
RULE all_assigned_to_product_version FOR ( characteristic_assignment);
WHERE
only_one: SIZEOF(
QUERY(this_one <* characteristic_assignment |
NOT (NATO_USE_STUDY_INTERCHANGE_SPECIFICATION+
PRODUCT_VERSION IN TYPEOF(this_one) ) )
) = 0;
END_RULE;
END_SCHEMA;

This schema can be expanded to give an explicit schema for the Interchange Specification. The
result will contain considerably more entities than are listed above. As an example the
information object part of the model will be imported, enabling Use Study requirements, mission
and role descriptions, etc., to be specified as SGML documents.
Note: Interchange Specifications should be published in electronic form, such that they can be
used in software development. There are well-established STEP/EXPRESS tool kits that can
process EXPRESS definitions and generate much of the required software architecture.
7.1.6 Product Data Management
Product Data Management (PDM) refers to the management of all of the data flowing through an
organization that is required for use in the development of new products or in the updating of
current products.
Several market pressures have encouraged the recent emergence of PDM systems:

The need to continually reduce product development time.

The consequent needs to speed up product development tasks.
The widespread adoption of good, dedicated product development tools (such as CAD,
CAM, CIM, MRP etc.) that, as independent solutions, require overall integration and
coordination.
The greatly increased volume of data, generated largely because of the use of these tools.

124

The effective control of this data is a prerequisite of coping with all the above pressures.
Implementing PDM should have three beneficial effects:
1. Better data quality - All data (even different types) that belong together can be
electronically linked.
2. Better data consistency - As data is created or changed it immediately becomes current.
There is no time lag that could result in different engineers working on different data
versions.
3. Greater data transparency - Instead of design projects being viewed by one engineer at a
time, the whole process can be viewed by the whole development team, all the time.
Therefore, for instance, the production engineers can start studying product designs (and
contributing their expertise) well before the drawings would normally have been handed
over for tooling.
The last of these points hints at the real power of PDM - the way it controls and facilitates the
distribution and circulation of product data. For example, when you use one of the more
advanced PDM systems to send information to other team members, although that information
leaves your "ownership" (so you can no longer work on it), it does not leave your sight. At the
click of a mouse, you can refer to it, monitor its development, and keep track of changes to it.
With the latest generation of PDM systems, the principles of concurrent engineering, still largely
theoretical, receive practical computerized support.
What is more, these systems do not overturn existing working practices. On the contrary, they
actually emulate the familiar manual procedures. People, therefore, adapt to them naturally,
producing a rapid increase in productivity band efficiency. In addition, as familiarity grows and
new working methodologies evolve, the PDM system is flexible enough to provide continuing
support.
This text is from a "Product Data Management - Understanding the Fundamental technology and
Business Concepts, a report by CoCreate.
7.1.7 Enterprise Resource Management
Enterprise Resource Management is accepted as a broad term for the activities and software
infrastructure that manage all of a companys assets and resources, including such basic
applications as general ledger, accounts payable and receivable, as well as manufacturing,
inventory, and human resources. It is the process of managing an organizations functions,
processes and methodologies to achieve focus on customer driven delivery of product or service
for the least cost and highest value. The software and processes enabling this approach,
Enterprise Resource Planning or ERP, was created to enable businesses to new markets, new
demands in the global community and changing customer expectations. Industry, particularly
manufacturing, has been driven to:
125

Improve Product Quality

Increase product assortment
Lower Costs, across the entire supply chain

At the same time, manufacturers must respond to the need to reduce on-hand stocks, implement
just in time delivery of materials and products and provide more reliable delivery dates and
higher levels of service to customers.
There has been a fundamental shift in focus, as the business community has become global in
nature. Inventory control was the focus through the 1960s, and in the 1970s planning for
material requirements (MRP) began to emerge. MRP and MRP II began to evolve through the
1980s and into the 1990s extending from the Shop floor through associated areas such as
Human Resources, Project Management, Finance, Engineering, etc. An awareness began to
emerge that all these activities, their infrastructure, and supporting software should no longer be
managed independently, but viewed and managed as they contributed to the core business. The
entire business process was being addressed, thus the term ENTERPRISE Resource Planning
evolved.
Throughout this time frame, the focus of this effort has been generally aimed at large business
and manufacturing concerns. ERP software suppliers developed solutions to address the large,
manufacturing sector. At the same time, industry began to turn to outsourcing and use of mid to
smaller size suppliers. As the market forces began driving dependencies in the manufacturing
process for inclusion of smaller and outsource suppliers, ERP software began to be developed for
mid and smaller sized businesses. Through use of virtual enterprise approaches, the entire
enterprise is being addressed.
ERP functionality is based on examining an activitys business processes and dependencies and
focusing business processes or changes thereto on:

Identifying and integrating all critical processes

Reducing, and in some cases eliminating complicated or non value added business steps
Managing the total process, not just the steps and
Focusing on creating value for the customer.

The Goal is to simplify processes before automating them, then apply tools that automate and
integrate the processes to support meeting customers desires and needs in cost effective ways.
Within ERP, several software vendors, such as SAP , BAAN , PeopleSoft, and others
provide services and suites to address Sales and Distribution, Business Planning, Production
Planning, Shop Floor Control, and Logistics. Briefly, these software suites provide:

Sales and Distribution, which covers, order entry and delivery scheduling. This module
also checks on product availability to ensure timely delivery. In some implementations,
it may also check a customers credit line.

126

Business Planning consists of demand forecasting, production planning, capacity, and the
detailed routing information that describes the where and when (in what sequence) a
product is manufactured.
Capacity and production planning gets very complex.
Simulation tools may be provided which help managers to decide how to overcome
shortages in materials, labor, or time. Once a master production schedule is complete,
data is fed into a Materials Requirements Planning module.

An MRP module may produce output such as an exception report, an MRP list, and order
proposals. An exception report brings attention to situations such as late delivery of
materials, or rescheduling. An MRP list shows the details of shipments and receipts for
each product and component. Order proposals are used to order materials and issue
production orders.

These outputs lead to Shop Floor Control. The planned orders from an MRP are
converted to production orders, which leads to production scheduling, dispatching, and
job costing.

The Logistics system takes care of the rest, assuring timely delivery to the customer.
Logistics would consist of inventory and warehouse management, and delivery.
Typically, the purchasing function is also found in the logistics area.

Through the mid-1990s, the ERP process has been applied across the spectrum of the business
processes required to produce products and services within the global marketplace. ERP product
suites are expanding to address product data management, product configuration management
and logistics planning, especially for complex, long-lived products. ERP, its approach and
underlying software are encompassing Supply Chain Management (SCM) issues, treating the
supply chain as a continuous and seamless activity, looking at demand, supply and constraints
simultaneously. Thus Enterprise Requirements Management is the management of all the facets
needed to tie together processes, diversified activities and organizations and still provide the
final, customer driven, product in a globally competitive environment.

127

8.0 TECHNIQUES
8.1 Through Life Business Case Analysis
The Business Case is the principal document in a decision package that evaluates proposed
actions to achieve some functional objective. The Business Case has three primary uses:
1. Evaluate the existing system and proposed courses of action
2. Present the business case for approving and implementing a proposed improvement
action
3. Re-examine the project at Life-Cycle Management (LCM) milestones and defend
changes from the original course of action
The Business Case documents the functional process improvement effort and presents the
business case as part of the decision package. It serves as the primary instrument in deciding
which approach, if any, should be further evaluated in detail for approval. Gross measurements
and estimates of cost and benefits data are usually all that is available early in the project. More
data is available if there has been a complete activity based costing effort.
The Business Case presents the economic analysis various alternatives. Economic analysis is a
systematic approach to the problem of choosing the best method of allocating scarce resources to
achieve a given objective. A sound economic analysis recognizes that there are alternative ways
to meet a given objective and that each alternative requires certain resources and produces
certain results. To achieve a systematic evaluation, the economic analysis process employs the
following two principles:
1. Each feasible alternative for meeting an objective must be considered, and its life-cycle
costs and benefits evaluated.
2. All costs and benefits are adjusted to present value by using discount factors to account
for the time value of money. Both the size and the timing of costs and benefits are
important.
8.1.1 Background
The following section was adapted from a study, Business Case Model for The DoD Logistic
Community: A Guide to Business Case Development completed by ManTech, West Virginia for
the U.S. Department of Defense Logistics Reinvention Office (LRO).
In todays hectic, complex world, decisions are often forced, supported by little, if any analysis
or documentation. Yet, we are constantly asked to render decisions that can have both short and
long-term consequences. In the NATO Alliance, such decisions can have dire results and tear at
the very fabric of "freedom" because our decisions ultimately effect "Defense Readiness."
Despite the dire consequences of poor decisions, the practice of preparing, reviewing, and
making decisions that are based on sound analysis or business case is infrequently applied. A

128

properly prepared business case represents an effective tool to reverse this practice and foster
timely, and accurate decisions within the NATO logistics community.
This Section is intended to assist all within the NATO logistics community who have a need for
preparing, documenting, and evaluating alternative approaches as well as those ultimately
responsible for decision making and directing a course of action with the development of a
business case.
This Section provides the information needed to use business case modeling as an effective tool
to manage change. It is simple, straightforward, and will serve as a road map for formulating a
sound business case. Use the guidance provided here to create a sound business case that is also
consistent with NATO Logistics Strategic Goals and Objectives. There are three simple steps:
1.
2.
3.
4.

Tailor the business case model that is provided in this section to meet specific needs.
Gather the information needed to support population of the tailored model.
Populate the tailored model in accordance with the guidance provided.
The populated model is the business case.

8.1.2 Introduction
Business cases are an integral part of every competent managers decision process. They are
frequently informal and often undocumented.
Such analyzes and models consist of the
managers assessment of financial, procedural, organizational, and performance implications of a
proposed change. Informal as it may be, this process yields information needed to support a
business decision and is therefore a business case. In general, the more complex the change of
the organization, the more formal and rigorous the business case development process should be.
Within NATO, formal business cases are critical elements of on-going Business Process
Reengineering (BPR) and other improvement activities, and related decision-making processes.
Despite significant guidance published to date, business cases continue to be misunderstood and
inconsistently applied within the NATO community. Ineffective applications of a business case
are found throughout the organization, such as, being used after the fact to justify technology
decisions, in-process implementations or projects, and related sunken costs. They are also
improperly used to determine the value of completed technology or software development
projects. This section will help in avoiding these traps.
8.1.3 Purpose of this Section
This sections purpose is to bring consistency and understanding to business case development
efforts within the NATO logistics community. It highlights the process steps required to produce
a simple, straightforward and easy to understand Business Case Model. The target audience is
NATO logistics functional experts, program management, and others tasked with implementing
change and making decisions about change within the NATO logistics community. Its objective
is to promote the use and consistent application of business cases as the tool for the evaluation
and management of change within the NATO logistics community.

129

The Need of the Decision-Maker

The need of the decision-maker is for timely, consistent, complete, and accurate
information. The business case facilitates making decisions consistent with the
organizations strategic goals and objectives, as well as keeping in compliance
with the NATO governing directives. It provides a formal yet flexible system
to manage individual initiatives more efficiently and align them with NATO
initiatives underway.
This section, when properly applied, will assist the decision-maker to:
Align proposed investments within their purview with NATO mission priorities and NATO
component strategic plans.
Present management with relevant decision information in a consistent framework that will allow
comparison, evaluation, and prioritization of competing and overlapping change initiatives.
8.1.4 Business Case Modeling Fundamentals
This section provides the fundamentals needed to integrate business case modeling into the
management decision-making process. It answers the questions: What, Why, When, How, and
Who. This section provides additional references for business case preparation and on-line
training.
8.1.4.1 What is a Business Case?
A business case is a tool used to manage business process improvement activities from inception
through implementation. A business case is a document that identifies functional alternatives
and presents economical and technical arguments for carrying out alternatives over the life-cycle
to achieve stated business objectives or imperatives. Each business case will look different
depending on its application.
However, essential ingredients remain constant.
Essential
ingredients include functional process descriptions, technical architecture descriptions, cost
projections, action plans, measures of performance, and risk assessment for each alternative
under consideration. Its focus is on process improvement and reengineering, not on technology
insertion. Technologys role is to enable or support meaningful process change. To be effective
as a management tool, a business case must never begin with any predetermined notions of the
outcome or predetermined technological solution. It must be completely and totally unbiased in
its conduct and presentation.

130

8.1.4.2 What is the Role of Business Case Modeling in Logistics Reengineering?

Linkage to Overarching Plans and Visions
Linkage to overarching plans and visions is of primary importance. Each
business case must show linkages to NATO goals and strategic objectives.
A business case should include activity models that focus on relevant
logistics functions. This enables the decision-maker to learn if there are
any overlaps in activity coverage, and potential contentions in project
dollar allocations.
Business cases should support the organizations strategic goals and objectives.
NATO, this means that all business cases must clearly support the following:

Within the

NATO Security Strategies

NATO Basic Political Documents
The NATO CALS Through-Life Business Model.
The NATO CALS Data Model (NCDM).
Principal NATO Committee Policy and Guidance.
NATO Logistics Handbook.

To this end, each business case and the included alternatives must:

Address a specific area within the Logistics Strategic Plan. Pinning down how the
business case links to definite goals and objectives within the Plan, is the beginning of
defining business case value for the decision-maker.

Show how it directly adds value to the accomplishment of the strategic plan, and helps
move toward the achievement of the NATO vision.

Show relationships to NATO Committee(s) vision, goals, and objectives.

Should clearly indicate how alternate courses of action would take the current, or AS-IS,
state to a reengineered, or TO-BE state that is consistent with the NATO CALS ThroughLife Business Model and NATO Logistics goals and objectives.

8.1.4.3 When Should I Prepare a Business Case?

Prepare a business case when any change is anticipated in a business process or supporting
technology. For significant changes, the requirement to prepare a formal business case and its
actual preparation should occur as early as possible in the change planning process. Formal
business case preparation is imperative:

When business process reengineering is identified and technology choices become

drivers of process redesign. This usually happens when strategic plans show a need for
major jumps in productivity. This might be seen in a strategic plan goal that describes an

131

end state that is significantly different from current experience.

Here, executive
management has decided that fundamental change is needed, and the business case lays
out an investment to enable the transition to a performance-based organization.

When any planned project, program, initiative, effort, implementation, product purchase
or lease will result in a significant change in an organizations processes.

When decisions between competing or overlapping change initiatives must be made.

When conformance with organizational strategic objectives has an adverse impact on

programmatic objectives.

When an initiative affects business processes or policy outside the span of control of the
implementing organization. (If we build it, they will come.)

When there is a requirement to provide a Comprehensive Portfolio Approach to IT

Investment, which defines the portfolio of information technology (IT) investments in
every phase of development (from concept exploration to operational) and of every type
(mission-critical, cross-functional, infrastructure, and administrative) as they relate to
missions and processes.

8.1.4.4 How Do I Get Started?

Establish a dialog among all of the parties involved. Those designated to prepare the business
case must know what is important to the decision-maker. They must also understand the
initiatives and alternatives to be included in the business case and gain an understanding of how
the business case will be used to arrive at a decision.
The decision-maker should identify the critical elements of the decision process for those who
will develop the model. Preferences for presentation of alternative comparisons should be
discussed, agreed upon, and documented. Specialist and/or training, if any, required to support
the process should be identified and scheduled.
Activity modeling, financial analysis, and
Activity Base Costing (ABC) are areas that are most likely to drive the need for training and or
support from specialists.
8.1.4.5 What Should My Model Include?
Business cases are about choice. They must present the decision-maker with alternatives and the
consequences of those alternatives. In general, not less than three alternatives should be
presented. The figure at right provides the general information that should be included for each
alternative.

132

Functional
Process
Descriptions

Technical
Architecture
Descriptions

Cost
Projections

Action
Plans

Measures
of
Performance

Risk
Assessment

8.1.4.6 Who Should Prepare a Business Case and What Should They Know?
The most important requirement is to be thoroughly versed in the organizations processes and
activities, and corresponding goals and objectives as they relate to the business case. Know what
is important to the decision-maker. Activity modeling and financial analysis skills are also
required or alternatively, specialists may be used to assist in these areas. Use of specialists,
when available, is highly recommended. They can significantly reduce the time required to
prepare a business case.
8.1.4.7 What Should the Decision-Maker Know?
The decision-maker must have an understanding of how to use the business case and how it will
apply to the expected change. The decision-maker does not need to understand the detailed
analysis techniques; however, he or she should have a basic knowledge in financial areas such as
return on investment and discounted cash flow. Matter-of-course knowledge of business process
reengineering topics, such as activity modeling, aids in using the model to make good decisions.

133

Dos and Donts of Business Case Development

Do include a business case as an integral part of BPR. A BPR is recommended prior to
IT acquisition.
Do establish a business case development team that is independent of those who are
responsible for the project.
Do keep IT-related measurements used in defining IT investments in terms of functional
requirements, identifying which outcome-based performance measures accurately assess
achievement of requirements.
Do continuously ensure that the linkage between investments and mission
accomplishment is maintained.
Do mold the business case development process into the entire organizations way of
planning and making investment decisions.
Do directly tie the use of the business case process with funding of any initiative.
Do adopt a timeline for completion of business cases prior to budget completion to allow
approved alternatives proper funding during the next budget year.
Do prepare a business case model prior to the selection of any alternative or technological
solution.
Do not prepare a business case in support of decisions already made or in support of
implementations already in progress.

8.1.4.8 What Else Should I Know?

Several barriers exist to preparing a business case. They fall within four categories: vision
barrier, people barrier, learning barrier, and operations barrier. The vision and learning barriers
have been previously addressed.
The people barrier occurs when individuals within the
organization may, for one reason or another, inhibit development of a business case. This often
occurs when the business case represents a beginning in the process of change. An operating
barrier exists because of how the organization works. One such barrier may be cost accounting
systems. The political climate, and procedures and rules required by the military may also cause
an operating barrier. Similar barriers may exist to the implementation of changes addressed by
the business case itself. If so, the barriers and the plans to overcome the barriers should be
documented within the business case.
8.1.5 Business Case Model Minimum Report Requirements: A Simple Structure
The table displayed provides the recommended outline that all business cases should follow.
Each outline element is briefly discussed to provide an understanding of needed content.

134

Typical Business Case Table of Contents

1.0 Executive Summary
2.0 Boundaries of the Business Case
2.1 Goals and Vision
2.2 Context and Perspective
2.3 Functional Performance and Metrics
2.4 Initiatives Considered
2.5 Baseline/Alternatives Considered
2.6 Key Assumptions
2.7 AS-IS Activity Model
3.0 Discussion of Alternatives
3.1 Alternative 1
3.1.1 Functional Process Description
3.1.2 Performance Impact and Metrics
3.1.3 Technical Architecture (optional)
3.1.4 Cost Projections
3.1.4.1 Investments/Action Plans
3.1.4.2 Operational
3.1.5 Risk Assessment
3.2 Alternative 2
4.0 Comparison of Alternatives
(Graphical Presentations Preferred)
4.1 Functional
4.2 Performance
4.3 Costs
4.3.1 Investment Costs
4.3.2 Operational Cost Savings
5.0 Conclusions, Recommendations and Issues

8.1.5.1 Executive Summary

The Executive Summary, is the foundation for senior leadership briefings and must answer the
So What? question. The Summary should recognize sponsor and funding organizations and
describe the approach used in broad terms. The Summarys objective is to establish confidence
in methods followed during business case synthesis and preparation, and should focus on the
results, not the activity behind producing them. Make sure that this addresses the Why of
doing the case. The question of So What? is met by explaining benefits of approving an
alternative and its initiatives, or emphasizing the need to continue.
The developers should answer a set of questions. Does the Executive Summary contain all basic
elements? Can it stand by itself? Is the business case uniquely identified so that it stands out
among others? Are all acronyms explained? Is it short (two pages or less)? Is it absolutely error
free? Finally, does it support the need to continue?

135

8.1.5.2 Boundaries of the Business Case - Goals and Vision

As stated earlier, all business cases should support strategic goals and objectives put forth in the
NATO Strategic Plans. Business cases should support implementation of the TO-BE State
identified within the NATO Alliance and component vision, mission, goals, and objectives.
Explain why the business case is being prepared. Identify sponsoring and funding organizations.
This explanation of why the business case was done can reinforce the idea of aiding NATO in its
transition to a performance-based organization. The starting point for identifying the business
case subject is usually a proposed or planned action, but the business cases subject ultimately is
defined in terms of objectives.
The Importance of a Stakeholder
A stakeholder is anyone who has a vested interest in the organizations efficiency and
effectiveness. This interest gives them the ability to affect an organizations management,
policies, and objectives. Typically, there are four main stakeholders of a function:
1.
2.
3.
4.

Customers, or recipients of output and services produced by a process.

Suppliers, or providers of inputs used by a process.
Regulators, or overseers of a process.
Process Participants, or employees and managers that form the product or service.

Stakeholders express their interests as outcomes. Outcomes can drive process behavior and
drive investment and operating decisions about these processes or their outputs.
Persuading process customers and participants, who are the most visible stakeholders, to
accept change is the process owners high order objective. While across the board
acceptance is highly desirable, some stakeholders may not accomplish everything they
want. The depth and breadth of firm commitments from stakeholders reflect downstream
potential for process and organizational change, resistance, or acceptance.
8.1.5.3 Boundaries of the Business Case - Context and Perspective
The context and perspective should match with the context activity model developed during
Functional Analysis. Define what is and is not being considered in the scope of this business
case, and reinforce whom it is for and what decision is helped by it. Identify potential
stakeholders, including what organizations will be affected, and who plays the biggest part in the
failure or success of the alternatives.
Stakeholders should be identified before functional
analysis.
Once identified, stakeholders must participate in the analytical process, whether in an active or
passive mode. The business case must address how carrying out an alternative will affect
stakeholder interests, and vice versa. This preempts actions by those who initiate regional
changes that may drive other downstream changes, while having no authority to make that
change happen.
Answer the question "What does it take to fulfill our mission and achieve our vision? The
answers to this question describe catalysts of success or failure in the functions mission.
Stakeholder requirements about products and services drive factors that are critical to the

136

fulfillment of mission and achievement of vision.

This is markedly true of customer
requirements. These cannot be decided in a vacuum. Participants in functional analysis of
activities must understand and document the impact these changes will have on employees,
customers, and others.
Taking various stakeholder perspectives, scrutinize pro forma initiative events, deliverables,
workflow, and integration opportunities.
As they arise, examine resource and planning
contentions to learn if any transition event or implementation would have a significantly adverse
affect or outcome. On a best effort basis, recognize uncertainty in the plan or its outcomes,
quantify transition and stakeholder risks, use previous lessons-learned that apply, and delineate
any potential benefits or values. Identify underlying causes (e.g., drivers, inhibitors) of risk, and
outline past successful strategies for dealing with these type of causes. Integration opportunities
normally focus on shared data assets or continued use of legacy systems as migration backbones.
Learn if there are established, clear lines of (internal) data ownership, custody, and access.
Develop impact statements, positions that outline concerns and recommend suggested courses of
action that could mitigate, or at least lessen, impact or risk. These impact statements may also
include suggesting tailored messages that would resolve uncertainty in affected stakeholders, or
recommending certain time frames that may increase chances for success. Section stakeholders
through resolution of impact statements, with an aim to produce impact agreements. Affected
stakeholders must be given an open and fair forum to express their concerns and disagreements.
Reach a consensus position; one where not everyone may agree, but everyone can support, even
if their support is passive.
8.1.5.4 Boundaries of the Business Case - Functional Performance and Metrics
Measures identified within the Program Managers business case must be subsets of the NATO
Logistic Strategic Plan or other relevant documents such as Component or Agency Strategic
Plans.
The Primary Measure May Not Consider Cost
Although cost is a primary measure, it is not sufficient to be able to say that the TO-BE is
achieved by accomplishing this measure alone. Additional measures may be used to relate
to the organizations overall goals and objectives. Performance measures are used to
distinguish and weigh primary benefits received from the activity generating the measure.
Meeting the desired level for these measures could imply that the level of benefit the
organization seeks was attained.
Not everything that counts can be counted, and not everything that can be counted
counts. Albert Einstein
Performance measurement is the assessment of effectiveness and efficiency of activities,
operations, and processes in support of achievement of an organizations missions, goals, and
quantitative objectives through application of outcome-based, measurable, and quantifiable
criteria, compared against an established baseline.

137

Good management practices require the establishment of clear organizational hierarchies of

goals and performance measures. Goals and measures used at lower organizational levels must
be linked to NATOs mission/strategic goals. Mission benefit, not cost and schedule constraints,
must be the overriding measure of success for any IT project.
There are four classes of performance measures used in both functional and economic analysis:

An outcome measure assesses actual results, effects, or impacts of a program activity

compared to its intended purpose.
An output measure describes goods or services produced and the actual level of activity
recorded or effort that was realized.
An efficiency measure is a ratio of outputs to inputs.
An effectiveness measure should identify critical characteristics of the output that meet
customer requirements.

Discuss what organizational performance measures are being used and how they are influenced
by the initiatives, preferably through use of a selected metrics from the NATO Logistics
Strategic Plan or Agency Plans.
A performance indicator is a factor used to assess speed or responsiveness, quality, or cost of a
process, input, output, or outcome. In effect, it is the unit of measure for a performance measure.
Indicator definitions can be used to compare projected outcomes of each alternative, as well as
how the indicator will be maintained for continued feedback into the success or failure of the
selected alternative once implemented. A brief discussion on the costs and benefits of collecting
this monitoring information should be included, especially if a method of collection must be set
up to facilitate the new metric.
8.1.5.5 Boundaries of the Business Case - Initiatives Considered
Develop high-level plans that describe new or different approaches to doing business according
to performance targets and business objectives. It is likely that several improvement ideas and
plans will be identified. However, not all of them can, or should, be put into place. Find
possible ways to do each approach and then parse these into achievable packages of work and
results. Project-level groupings of work that produce distinct deliverables are named initiatives.
Initiatives can vary in scope and size. There must be a narration of each initiative included in the
business case. Describe how strategies will be put into place in terms of specific actions,
timeliness, and resources. Evaluate initiatives against demonstrated implementation experience
or others best practices. Identify and assess each candidate initiatives risks and define different
paths to abate such risk. Match each candidate initiative to common barriers or characteristics.
Barriers to successful implementation, previously mentioned, refer to those situations that tend to
be outside the span of control of those making change, or that have prevented desired outcomes
of previous attempts to adopt new ideas or technologies. Similar implementation efforts must
find ways to overcome or bypass these barriers to achieve closure. For most individuals, change
is difficult. Therefore, resistance may be encountered when gathering accurate information from
individuals within the organization. These barriers are overcome with proper communication.

138

Explain why certain questions that are being asked can promote a more open environment for
dialog. Sometimes there is nothing to do except document within the business case, any issues
relating to the people barrier.
Take Care Not to Introduce Bias
Take care not to introduce bias into the process when creating alternatives. Technology
initiatives must have a clear relationship to process improvement initiatives when they are
combined into a single alternative. Ask this question: "Does this technology initiative enable
each and every process change included in this alternative?" If the answer is no, the
technology initiative should be excluded from the alternative. This approach will prevent the
perpetuation of "pet" technology projects that are impractical or have no real benefit to the
organization.
Each initiative must reflect progression (including phased achievement) toward affected
performance targets.
Convert performance targets into provisional performance objectives.
These objectives can frame stepped-investment justification and selection decisions, and drive
downstream development of the TO-BE process.
Providing clearly defined initiatives give the decision-maker an understanding of what the
business case is about, because in the end, the business case is about initiatives.
8.1.5.6 Boundaries of the Business Case - Alternatives Considered
The objective of functional process improvement is to achieve the vision. Because each
initiative considers only one or a few areas for improvement, analyze combinations of initiatives
to address each goal. It is unreasonable to study all combinations, because there will be too
many. A more practical method is to combine logical packages of initiatives that work well
together or portfolios of a set of initiatives with common objectives or goals to form alternatives.
As a rule, initiatives sharing common critical performance measures or objectives make the best
business case for being put in one portfolio versus another. However, each set of related
initiatives must put into place changes that handle the same predicted level of process workload
within the planning horizon. Another point to consider is the decision-makers focus on the
business case and the corresponding emphasis to place on each element of analysis across all
alternatives. Look at tuning the business cases emphasis in the same way the settings are
adjusted on a sound systems graphic equalizer.
The reference for measurement is the status quo, or the baseline. Baseline cost and performance
provide threshold values for the cost and performance of alternatives.
AS-IS costs and
performance measurements revised to reflect any approved changes not yet implemented would
provide this baseline. The business case should include at least three alternatives, including the
status quo. Each alternative must give functional management a complete view of financial and
operational impacts of proposed changes.

139

B u s in e s s C a s e F o c u s
Technical
Architecture
Descriptions

Cost
Projections

Functional
Process
Descriptions

Action Plans

Measures of
Performance

Risk
Assessment

Develop total investment cost flow and total anticipated process cost savings flow for each
alternative. Quantify total risk assessments based on probability and consequence of failure for
each principal initiative activity. Develop an action plan for each alternative, and assemble as a
total package for review by the approval authority. Pre-test any controversial ideas with the
approval authority or his or her peers. Use economic simulation techniques (e.g., risk-adjusted
discounted cash flow) to develop supporting cost schedules.
8.1.5.7 Boundaries of the Business Case - Key Assumptions
Assumptions are necessary in a business case because they are explicit statements used to
describe present and expected future behavior upon which the business case is based. Since no
one knows what the future holds, assumptions must be used to set boundaries for painting the
business case.
Example assumptions include future workload, estimated useful life of an
investment or system, and the period over which alternatives will be compared.
Summarize key economic and political indicators used for each alternative assessment; also
briefly discuss what non-quantitative issues need consideration. Employ a sensitivity analysis or
another method and focus on assumptions that are thought or historically demonstrated to cause
the greatest amount of variation in costs and performance.
8.1.5.8 Boundaries of the Business Case - AS-IS Activity Model
Assumptions Should Be Documented
Assumptions should be documented for the decision-makers consideration.
Obvious
assumptions such as there will be a next year, are not required. The assumptions should be
clearly defined. Work closely with the decision-maker to determine critical assumptions. In
some cases, the decision-maker may want to provide additional information. An example
assumption would be the frequency of an event remains constant in the future.
The current process-flow of that piece of the organization that is being considered in the business
case must be detailed to a level where all stakeholders can support conclusions drawn from the
analysis. It also must be developed enough to understand areas affected by proposed initiatives.
Finally, it must be detailed enough to assign costs and link performance measures. This step is
also considered developing the baseline or baselining. It provides the picture of what is being
changed that will be used to compare with the alternatives. The entire span of activities depicted
in a business case should map to both the NATO CALS Data Model and other NATO process
models. Integration Definition Function Modeling (IDEF0) modeling as defined in Federal
Information Processing Standard (FIPS) Pub 183 is recommended.

140

8.1.5.9 Discussion of Alternatives - Functional Process Description

Functional Analysis is about what is done. This should describe significant outcomes, outputs,
measures, and inputs involved in executing this process. It must focus on efficiency (best use of
inputs), effectiveness (best delivery of outputs and outcomes), and productivity (output over
input). Sometimes these differences in TO-BE versions tend to be very subtle, and this may
require a greater focus on change in flows than on the processes themselves. Another approach
is to build higher-level context models. These show how the change impacts upstream or
downstream activities (that is, the outcome difference may not be within the scope of the activity
model). Give attention to those actions that will eliminate or reduce excess and delay.
8.1.5.10 Discussion of Alternatives - Performance Impact and Metrics
Provide the projected metrics that is expected to result from each alternative and indicate how
the metrics compares to the baseline. At this level, we are talking about how mission
requirements, strategic goals, expected outcomes, and expected performance will be met by this
alternative. A conscious, focused effort should be made at each stage of the process to recognize
and document the relationship of each requirement to the accomplishment of a higher-level goal
or objective.

8.1.5.11 Discussion of Alternatives - Technical Architecture (Optional)

Often, the business case will be considering technology that an initiative is driving, employing,
or developing to achieve the organizations goals and objectives. Develop a clear picture to
explain how technology will do this, what activities this technology will impact, and how it
blends with other implementations.

Information Technology (IT) alone is not sufficient to justify the cost. It must be shown that the
IT will impact the organizations activities in a way that improves benefits as well as reduces
costs. This should be the predominant focus of the technological discussion within the business
case, not a detailed technical discussion of its function and components. Not how it works, but
how it impacts the operations that it supports.

141

8.1.5.12 Discussion of Alternatives - Cost Projections (Economic Analysis)

Economic Analysis is about the costs and benefits of how something is and will be done. The
business case places emphasis on future economic benefit rather than on period costs, and on
value-added as opposed to cost savings. This section must focus on what investment option
should produce the best use of investment capital.

The economic analysis should focus on productivity, and describe how it mitigates both
initiative-fulfillment risk and organizational uncertainty stemming from the intended changes. It
should offer the decision-maker multiple cash flow calculations.
Underscore that there is no one right answer, only one best answer. The best course of action
should blend the total cost of involved processes, output performance, and outcome impacts
prevailing over all sub-optimal choices; e.g., those that only justify better technology for the sake
of better technology. Qualitative considerations may tip the scale between alternatives, as when
data or system integration, purchase of COTS software, inadequate security mechanisms, et al.
cannot meet some mission requirement.
The organizing backbone of the business case is a time line extending across months or years.
This provides a framework for showing management how they can work to help put financial
tactics into place: reduce costs, increase gains, and accelerate gains.

142

Cost Projection Issues to Consider

Consider the impact of the initiative across multiple fiscal years.
Consider the time value of money. (When adding costs across years, dollars in future years
must be discounted.)
Consider inflation by including adjustments in future year cost projections by a rate
consistent with this economic reality.
Consider, for comparison, constant dollars to demonstrate the impact of the inflation
assumption.
Consider that estimations based on various operational cost data may be the best estimate.
Consider using the 80/20 rule (where 80% of the costs are made up of 20% of the activities).
The ratio of investment to savings should be so significant that most estimating errors will be
insignificant.
Consider the following measures: current project funding support, dollar value of benefits,
projected project costs, rate of budget expenditures compared to projections, and adherence
to baseline schedule or time frame.
Consider the Earned Value Management approach that provides an effective mechanism for
linking cost, schedule, and benefits performance for acquisition programs.
Consider Internal Rate of Return (IRR) that demonstrates what interest rate would have to be
obtained outside the organization before the decision to invest funds outside rather than on
this initiative.
Consider Return on Investment (ROI), also called Return on Assets, that demonstrates what
rate of return can be expected from the investment outlay.
Consider Risk Adjusted Discounted Cash Flow (RADCF) that considers risk and discounting
cash flow. It brings all alternatives back to the current year for a total cash-flow comparison.
Any positive RADCF value is considered a good investment, but another alternative may
demonstrate greater RADCF value, making it the preferred alternative.

The business case is not a budget, not a management accounting report, and not a financial
reporting statement. This distinction is meaningful for deciding which kind of cost and benefit
data go into the business case: incremental values or total cost and benefit figures. Incremental
values are probably the right choice in decision support situations, notably where both costs and
benefits will enter the business case.
8.1.5.13 Discussion of Alternatives - Cost Projections - Investments
These costs should be the complete and total costs necessary to have the alternative turned into a
reality. This includes training and needed purchases. Provide an aggregate, initiative-level
mapping that would help view required cash flows over time as they relate to each alternative.

143

This would also link to activities that an alternative affects. At the heart of this mapping is a
high-level course of action used to frame when and how a TO-BE state becomes operational.
This is called an action plan. This should enable the decision-maker to see how cash spending
increases until some point at which operations costs start decreasing.
Prepare an action plan that specifies what needs to be done and when. A solid and complete
action plan has each of the following characteristics:

Each component action has a specific beginning and ending point.

A specific person or group of people does each component action. Responsible parties
have authority, capability, and obligation to get the job done.
Each component action has a tangible, clear result. Afterward, it is possible to know
whether it was done or not.

8.1.5.14 Discussion of Alternatives - Cost Projections - Operational

At a minimum, the business case should reflect the AS-IS cost of doing the whole activity,
coupled with a targeted reduction percentage that can be applied over time (tied to its initiatives).
This will show expected TO-BE activity costs once changes are put into place. Moving it to the
next level of output costing, or better yet outcome costing would be desirable, because this is
what most people can relate to.
Activity Based Costing (ABC) relates cost of resources to activities that consume them. At a
minimum, this information provides insight for calculating future out-year resource requirements
and costs. ABC can provide calculations that will depict activity levels through the planning
horizon. These costs should be ongoing operation costs directly contributing to activities defined
within the activity model mentioned in the functional analysis.
8.1.5.15 Discussion of Alternatives - Risk Assessment
This must be discussed with or without having quantifying information. Even with
categories, it cannot be assumed that some standard mitigation routine can be applied to
one of that type. Each identified risk needs to be separately looked at and handled. To
paralyzing the decision-making processes, rank these factors and address the
ominous of them.

these
every
avoid
most

Recognizing risk does not have to hit an exact number, but instead distinguish one alternative
from another by the degree of risk that separates them. This recognizes that not every decision
carries an equal degree of failure or success. It allows the decision-maker to recognize the fact
that estimates have varying degrees of becoming reality.

144

A Proper Study of Risk

A proper study of risk should be addressed in any business case, but risk is perhaps the most
difficult area to analyze.
Risk should be viewed as "an undesirable implication of
uncertainty." Risk can be quantified in terms of odds (probabilities) or remain non-quantified
(uncertainty). In situations involving (what we commonly call) risk, probabilities of various
outcomes are known.
Under uncertainty, there is no knowledge of the probability
distribution of possible outcomes. We can classify different categories of risk: Business
Risks, Process Risks, Technical Risks, and Organizational Risks. Risk to the organization
can be an influence from other organizations that formed alliances because of the alternative
(i.e., outsourcing).
8.1.5.16 Comparison of Alternatives - Functional
Describe the TO-BE activity models for each alternative and describe how they address
performance measures vis--vis the AS-IS activity model.
These TO-BE models should
represent a different future state in line with each alternative. This should also point out why the
alternative would achieve a distinctly different manner of doing business, rather than continuing
with the AS-IS, or baseline. Annotate differences between each TO-BE diagram and the AS-IS
diagram, and among TO-BE diagrams. These diagram comments can depict organizational and
other resource volumes as well as volumes represented by the flow arrows. Tying initiatives to
both AS-IS and TO-BE activities illustrates intended changes and helps visualize necessary
project work.
USED AT:

AUTHOR:

DATE:

07/02/97

PROJECT:

REV:

1.00

WORKING

R E A DER

DATE

CONTEXT:

DRAFT
RECOMMENDED

NOTES: 1 2 3 4 5 6 7 8 9 10

Available Technical Capabilities

Performance Directives

Industry Standards

DT Update Prescriptions

PUBLICATION
Operating Budgets & Plans

Expressed Customer Expectations

Asset and User Data

Standard Policies, Practices & Procedures

Recommended Improvement Directives
Historical Purchase Data
Business Initiatives

Identify
Technology
Trends

Independent Research & Analysis

Technology Policy

Vendor Provided Product Plans

A11

Updated Technology Standards

Technology Incorporation Opportunity

Assess Business
Technology Needs

Business Technology
Requirements
Gold Disk Configuration
Production Release
Configuration Performance Results

Current Technology Standards

A12

Assess
Integration
Opportunities

Legacy Non- Standard

Information Infrastructure

DT Integration Framework

A13

Forecast
Technology Needs

Technology Item Forecast

Technology Investment Options

Identified DT Purchase Volume

A14

Approve
Technology
Commitments

Asset Base Improvement Project Plan

DT Refresh/Replacement Budget Plan

Approved Asset Base
Improvement Project Plan

A15

Technology Planner

Technology Standards Board

Client Business Managers

Virtual Team & Environments

Software Distributors (Systems Manager)
Technology Planner/
Technology Standards Board

NODE:

A1

Asset Manager
Client and Business Managers

TITLE:

LAN/WAN Systems Groups

Project Management Groups

Asset Repository
Accounting/Financial Systems

NUMBER:

Plan Technology Usage

P.

8.1.5.17 Comparison of Alternatives - Performance

Use various charting techniques to show expected performance improvement in line with
realizing changes put into place by various initiatives. Another technique arrays over a timeline
the expected performance level ranges for each measure and all alternatives in a table that is
highlighted in red, yellow, or green. Regardless of the approach, provide the decision-maker
with a straightforward picture of expected performance.
Guidance in using the software
application Turbo BPR Version 2.5 for business case development is available on the Internet.

145

Lead Time Performance

100
50
Baseline
Alt C
Alt B
Alt A

Days

0
2002 2004
1998 2000

8.1.5.18 Comparison of Alternatives - Costs

As stated earlier, the organizing backbone of the business case is a time line extending across
months or years, as the figure suggests. A graph of total investment and operational costs for the
baseline and each alternative should be provided, as well as any other presentation helpful to the
decision-maker. Increasing or accelerating gains, or reducing costs may effect changes in cash
flow.
Projected Costs vs. B aseline

vs Baseline

$12,000
$10,000

Alternative 1
Alternative 2
Alternative 3
Baseline

$8,000
$6,000
$4,000
$2,000
1

Fiscal Year

8.1.5.19 Comparison of Alternatives - Investment Costs

Value-added Must Be Considered
Value-added must be considered over costs alone. The business case must consider the cost
of the initiatives, but even more so, it must identify the value-added to the organization.
Reducing services just to reduce costs will more than likely not accomplish the organizations
strategic goals and objectives. Although one initiative can show greater cost savings, the
initiative may compromise value. This should be clearly stated within the business case.
Other alternatives that generate greater value, but at a greater cost, may present justification
more consistent with NATO goals and objectives. Both tangible and intangible benefits and
costs should be recognized.
Cost measures gauge the number of investment dollars needed to achieve a particular milestone
or activity level. For example, a performance measure can be the dollars necessary to move an
146

effort through one phase. The granularity of a performance result is not as important as tying the
investment of dollars to the achievement of some result. This task is decidedly different from
measuring whether budgeted dollars were spent in a particular fiscal year. Schedule measures
gauge the amount of time necessary to obtain a particular performance result. As stated above, a
performance measure can be the amount of time needed to move an effort through a phase or the
amount of time to do part of a phase. What is important is that the schedule measure is tied to
the same performance result as the cost measure. Investment project baselines should contain
major events that impact the effort.
Achieving these events on time may demonstrate
satisfactory progress. For each effort, establish a target date that is based upon contractual
requirements or the need to complete an event before another can start. Thresholds for these
events can be set by policy (e.g., 90 days beyond target) or by absolute need when there is no
slack in the schedule.
8.1.5.20 Comparison of Alternatives - Operational Cost Savings
Exploit Activity Based Costing capabilities in the business case by assigning projected costs to
various activities affected by each initiative. The change in activities from the AS-IS activity
model to the TO-BE activity model should make up cost savings realized by that initiative. The
TO-BE activity model should always represent increased value-added to the organization.
8.1.5.21 Conclusions, Recommendations, and Issues
This section should be prepared at the end of the business case development and may include a
sensitivity analysis.
Make an initial conclusion and recommendation to the decision-maker
based on the findings. Conclusions, recommendations, and issues should be documented as an
amendment to the business case as provided by the decision-maker.
8.2 CALS Techniques
8.2.1 Approach to Implementation - Change Management
8.2.1.1 General
8.2.1.1.1 CALS
CALS and/or its organization must be seen as an enabler of the Change Process. CALS is the
strategy to implement an overarching management framework to combine technology insertion
and change management.
8.2.1.1.2 PMview
This document is written for the Manager in Charge of the overall organizations change
process.(in some organizations this might be called the CALS-office). The documents goal is to
set a general methodology to ENABLE the Change.
We must warn you that this document is only gathering some good advises found through
different sources. The document is not written out of personal experience.

147

8.2.1.1.3 Techniques
This is a warning. Indeed, a number of techniques exist to facilitate the Change Process. We
site, the different implementations of Business Reengineering, Benchmarking, Continuous
Process Improvement, Performance Based Change Management, of which some of these
overlap. The techniques must be carefully chosen in function of an overall strategic goal. The
prime concern of the Change Manager should be to carefully integrate, Process Change,
Technology Insertion, and Organizational Change.
8.2.1.2 Step 1 - Motivate to Change
This is the first step in creating an environment in which Improvement is encouraged and
nourished. Its aim is barrier reduction and general goal setting. Management must have a clear
vision of what it wants to accomplish and where it wants to go.
8.2.1.2.1 Top Level Management
Top managers recognition of the need for significant change and their willingness to learn more
is the first step toward effective change planning. It is probably not possible to overstate the
importance of the role of top management. Leadership is essential during every phase of the
change process. In fact, indifference and lack of continuous involvement by top management are
frequently cited as the principal reasons for the failure of Improvement Programs. To be
successful, you will not only need the vision, planning and active involved leadership of top
management, but also such practical support as providing resources for implementation - the
necessary time, money, and personnel. Delegation and rhetoric are insufficient. Without top
management assuming an active role as champions of the Improvement Program, you will not
obtain the full scope of benefits available.
One of the first tasks of the Management will be to draft a Vision Statement
8.2.1.2.1.1 Vision Statement
A key step in the Change Process is the creation of a common understanding among top
managers about what they want the organization to look like in the future and what principles
will guide the actions they take to achieve the Modernization. his strategy will become the basis
for formal statements of the new organizations vision and values.
The Change Vision should be a clear, positive, forceful statement of where the organization
wants to be. It should be expressed in simple, specific terms. The vision must be powerful
enough to excite people and show them the potential of what can be done. A well-crafted vision
statement supported by action can be a powerful tool for focusing the organization toward a
common goal.
Whatever forms the vision and guiding principles take, it is important that they be communicated
throughout the organization frequently and with conviction. It is important that the vision be
followed soon by a concrete plan of action to avoid its being dismissed as a hollow slogan.

148

Align Goal/Vision with Management Level

Think Globally, Act Locally
Focus

Key ideas in the new vision can be (not limited list):

Client orientation.
Through-Life Management.
Need for product processes.

8.2.1.2.1.2 Understanding
To obtain top-management commitment, you need to begin to educate senior managers regarding
the impact of possible business modernization. This can be done through Workshops, Briefings,
Management Guides, and White Papers.
8.2.1.2.2 Why Change
In considering a Business Modernization initiative, the first and possibly the most important
success criteria is to make sure that the rationale for initiating the project is sufficient for
justifying the effort and expense of the project.
8.2.1.2.2.1 Current Environment
Analyses of the current environment with a report on the lessons learned will most of the time
make clear why and where changes are necessary.

8.2.1.2.2.2.1 Fear of Failure

8.2.1.2.2.2 Change Drivers
There needs to be sufficient motivation for the enterprise to make significant changes for
improvement. In the business environment, this motivation is often driven by actual or perceived
failures in performance. This actual or perceived failure can apply to how the enterprise
measures up against the competition in terms of production, distribution, customer service, price,
etc.
8.2.1.2.2.2.2 Critical Assumption Analysis

Under CAA, stakeholders in the enterprise identify the assumptions under which their business is
conducted. They then attempt to isolate those assumptions, which, if violated, would cause the
enterprise to cease to exist as it is today (e.g., the assumption that quality watches must be
149

precision machines or that the cold war will always be with us, etc). All assumptions, but
particularly the ones in the critical category, are candidates around which to build a case for
action.
8.2.1.2.2.2.3 Need for Structural Evolution

A second commonly used rationale is the need for structural changes in the organization. The
structure of our Defense Organizations has always been vertical. That is, a top-to-bottom
management structure - with decision-makers at the top and soldiers at the bottom - has
characterized the typical army. This generally has meant that strategic planning for our Defense
enterprise occurs at a high level and is delegated down to divisions, departments, and individual
job performers in the form of policies, procedures, and directives. In response, performance
appraisals - which can take the form of periodic formal performance reviews or weekly status
reports, sales figures, etc. - are reported back up the chain of command. This paradigm operates
in a strict up-and-down the chain of command communication manner.
The emerging paradigm, however, has enterprises relying more on concurrent, cross-functional
teams (i.e., teams that cross organization boundaries) composed of knowledge workers organized
in a horizontal fashion. The goal of these cross-functional teams is to produce the enterprises
products most effectively by focusing on the product processes, not the organization of the
enterprise itself. Customer success relies on these cross-functional business processes to build
and support the product. Under this paradigm, in fact, the quality of a product consists of both
that product and its associated processes in designing, building, and maintaining it over its useful
product life.
Structural organization evolution, however, does not come easy to an enterprise.
While
processes can be changed overnight, people and organizations typically cannot. Therefore, part
of this structural evolution is not only an increasing corporate awareness but also a change
management plan that plans for the orderly, evolving transition of the organization and the job
performers within that organization from a vertical, structure to one that is more horizontal. This
change management plan must include processes for facilitating information flow and
communication across organizational boundaries.
What occurs between managements setting strategic goals and workers on the line reporting
their progress and all the layers in between? What occurs is a business processa series of
time-ordered individual activities performed as discrete events in a larger scenario that is guided
by a strategic vision that must be implemented in stages, at the tactical level, to achieve the
overall strategic objective. To use a literary analogy, one can think of the business process as a
stage play: the play is written and directed (by management) to achieve an artistic (corporate)
effect; the actors (employees) play their roles to enable this achievement; each scene (discrete
event) contributes to an overall plot (process) that unfolds sequentially, uniformly, and
deliberately; and all is held together by the motifs and themes (policies and procedures) that
manifest themselves as each scene unfolds.

150

With this business process paradigm, however, there are often communication breakdowns (or
disconnects) between various groups and/or departments that inhibit process performance. Many
enterprises recognize that such breakdowns pose significant challenges to process improvement
initiatives. In fact, the success of a Change effort largely depends upon discovering and
analyzing these disconnects.
8.2.1.2.2.2.4 Agility

A third principle or rationale is the need to align an enterprises strategic goals with the
objectives of its departments and employees, as well as with the tactical processes that are
intended to achieve the overall strategic goals. It is generally recognized today that success in a
rapidly changing environment is closely tied to how the enterprise proactively manages and
evolves its business practices as part of an efficient implementation of its overall strategic plan;
and how quickly and effectively the enterprise leverages new opportunities. We have, in fact,
entered the age of agility.
Of concern to any enterprise today is the increasing rate of change in the socio-economic
environment. The rate at which we must adapt our enterprise to the current business
environment is changing exponentially as information and computer technologies seem to
change and improve on an almost daily basis.
Todays challenge is determining how to effectively respond to, and manage , change . Every
managerin fact, every job performer (or employee)is faced with the fact that the current
situation is, or will shortly become, unfavorable. More importantly, radical change will often be
required. Critical business issues intricately tied to change include affordability, responsiveness,
quality assurance, resource scarcity, and assurance of total customer success.
8.2.1.3 Step 2 - Develop Change Plan
Once a Vision Statement has been drafted by top management you can start to develop the
Strategy for the Change. This will include, (start) setting up an organizational structure, the
identification of the "customer" needs, the selection of organizations who will be involved by the
Change Process, and the determination of needed/available resources.
However, be aware that there is no one right way to implement the Change Process in your
organization, no guaranteed recipe for success. What followed is only offered as a guide in
developing strategies and associated plans to carry out these strategies. It is important to take a
flexible approach to capitalize on an organizations strong points so that energy is focused on
key improvement opportunities.
8.2.1.3.1 Develop an Organizational Structure
Developing an organization structure that will institute, sustain, and facilitate expansion of your
improvement effort is an essential element for success. This "phantom" structure can be called
CALS-organization or office; however, it might be a good idea to give a more forceful name,

151

which has a specific relationship to the Vision. The following is a proposed organizational
structure. This structure will grow as the Change Process evolves. Important is the integrated
nature of the structure: high involvement of top management and of the employees from the
departments.
In the early stages of the Change Process, a team of top managers should form an Executive
Steering Committee (ESC). This ESC will be chaired by the Organization Head or Deputy. By
establishing the ESC, top management provides identity, structure, and legitimacy to the
Modernization Process; it is the first concrete indication that top management has recognized the
need to improve the process, and has begun to change the way the organization conducts
business. The first task of the ESC is to publish its vision, guiding principles, and mission
statement.
The ESC is at the top of the Change Structure. The committee members provide leadership and
direction for the Change Process. Below the ESC, Change Managers (CM) work on the
organizations key change areas. There can be one or more CM-teams depending on the extent
of the goals set for the organization.
To ensure good communication between ESC and CM-teams members of the ESC act as
sponsors and linchpins on each CM-team.
Below the CM, teams are Change Development (CD) Teams that work on specific problems
assigned by the ESC.
In turn, the CD-teams can designate Tiger Teams (see Step 6) to carry out one task. When the
task is completed, the Tiger Team is disbanded. Members from CM and CD-teams will as
sponsors and linchpins in the same manner as the ESC-members
8.2.1.3.2 Identify Customer Needs
To make the change process work you must focus on meeting your customers expectations
(=needs and wants). Customers can be either coworkers (=internal customers) or end users
(external customers) of your services or products.
8.2.1.3.2.1.1 Customer - Things We Know

Customer Satisfaction is defined by our customers - and thats what we should be seeking
to achieve.
We may be very content with what we are doing, but if our customer does not like it, we
will never achieve Customer Satisfaction.
GOOD customer service results in Satisfied Customers, who are more likely to give
positive recommendations to their friends and colleagues. This will result in seeing an
increase in new customers and probably an increase in repeat business from those who
choose to return.

152

BAD customer service results in Dissatisfied Customers, who not only do not come back,
but also tell their friends of their experiences and dissuade new people from ever trying
us out.

8.2.1.3.2.1.2 What is a Customer?

A customer is the most important person in our business.

A customer is a person who comes to us with needs and wants and it is our job to handle
them in a manner that is beneficial to him/ her and ourselves.
A customer is not a cold statistic, he/ she is a human being with feelings and deserves to
be treated with respect.
A customer is not an interruption to our efforts - he is the purpose of it. We are not doing
him a favor by serving him, he is doing us a favor by giving us the opportunity to do so.
A customer deserves the most courteous attention we can give.
Customers are not dependent on us; we are dependent on them!

8.2.1.3.2.1.3 Select Organizations

At the outset of the Change Program, you must choose to implement it either widely or with one
or more product or process development pilots. A partial implementation will allow focusing the
resources on specific projects. Selecting the change targets involves identifying the potential
opportunities, setting priorities, and choosing the effort that offers the most significant
opportunity for business improvement.
It is also possible to tailor a combination of the two approaches to fit particular circumstances.
In any case, the decision is one that each organization must make after realistically assessing a
number of factors, including:

The time frame

The size and complexity of the organization
The ability of the organization to change
The resources (time, money, and people) that can be allocated to introduce and sustain
the effort

8.2.1.3.2.1.4 Determine Resources

The Change Plan must disclose how much it will cost to implement the Change, the level of
effort to be funded, where the required time will come from and how it is to be accounted for,
who will provide what personnel, and what facilities will be used. Obviously, these resource
decisions must be coordinated with all those affected by the decisions. This part of the plan may
the hardest to develop because Change Management will now be competing with other

153

requirements for organization resources. In addition, it may be the first test of the managements
commitment to the Change Process. Milestones for providing the identified resources should be
included in the plan.
One must be aware the new way of doing things are to become a way of life in the organization,
and that in reality Change Management is not competing for resources because it will be integral
part of the future corporate mission.
8.2.1.4 Step 3 - Conduct Training
Training and/or retraining are essential to the success of the Change Project. Training programs
will create the kernel of an organizational culture, which will create a favorable climate for the
change program.
It is important to note that during the early stages of implementation of the effort, attention
should be given to developing a detailed plan for training executives, managers, engineers, and
all team members. This includes:

Explaining the need for radical improvement as well as its benefits.

Communicating the Goals for Change.
Developing a common language with which to talk about the Change Issues.
Defining the structure and the process through which the Change will take place.
Clarifying everyones responsibilities.
Providing people with the tools and techniques to change their work process.

Besides learning the necessary technical skills to use the tools, each team-member must be
encouraged to learn the basic philosophy, principles, and practices involved in making the new
strategy one that focuses on "Why do we do what we do at all. You need to provide the
freedom for your team members to raise questions regarding problems that are thought of as
business-as-usual practices. All employees must better understand their jobs and their roles in
the organization, and how their jobs will change.
Such understanding goes beyond the
instruction given in manuals and job descriptions. Employees need to know where their work
fits into the larger context: how their work is influenced by workers who precede them and how
their work influences workers who follow.
To prevent surprises and delays in implementation, the training plan must include reasonably
accurate estimates of the schedule and required resources.
8.2.1.5 Step 4 - Ide ntify Goals and Performance Measures
Once the Change targets for improvement have been set, the team should define the change
efforts as clearly and completely as possible.
The principal benefit of this step is that Change Development teams begin their work with a clear
understanding of their mission and an idea of what successful performance will look like. Their
efforts are properly focused on how they will achieve the process vision and performance

154

objectives set in place by senior management, not wasted on trying to determine what their
objectives should be.
8.2.1.5.1 Business Case Analysis
It is critically important for the for a successful Change Process to have a clear understanding of
the business case justification.
You must include a strategic planning, business issue
identification, business opportunity identification, critical process identification, strategic goals,
and top-level cost performance analysis. This is not as difficult as people think. Most
enterprises have some picture of their performance, as well as some idea about how much they
want or need to change or improve over a given time frame. The difference between where they
currently are and where they want/need to go is the driving motivation for the Change Process.
The difference must be translated into a set of goals, initiatives, and top-level initiatives that
form the roadmap or strategic plan for improvement. This plan can then be used to further
expand definitions or critical business issues or opportunities, as well as to identify the core (or
critical) business processes that support those business issues.
By identifying critical business issues, processes, and goals, this process produces the primary
inputs to the Change efforts. A business case based on these goals, initiatives, measures, and
estimated costs needs to be developed to reassure management that the enterprise is headed in
the desired direction and that the fundamental question of affordability (or return on investment
for the effort) is identified early on. The specific benefits to be gained also need to be identified
at this point. This initial business justification or forecast will be used to benchmark progress
throughout the change effort when preliminary or intermediate results will be compared against
the business case to ensure that the options being chosen or evaluated are consistent with the
business case.
The business case should focus primarily on what it takes to help a customer to be very
successful. That is, the ultimate goals of a business from the customers perspective (and,
therefore, the business case itself) need to demonstrate how the business goals, such as revenue,
profitability, improvements in other socio-economic factors, growth of interest to the business,
etc., are also supported.
8.2.1.5.2 Performance Measures
An importantand often overlookedcomponent of an effective Change Initiative is the
yardsticks to use to measure and gauge progress and performance. If the Change Team knows
from the outset their goals and targets in a measurable form, the probability of success is greatly
increased. There needs to be meaningful metrics, and the means to measure for that metrics.
The Change Development teams should set in place a means of measuring performance to ensure
that the improvement benefits are realized.
The measurement process needs to be viewed as a process for obtained vital insight into the
progress, products, and/or processes of the change project. This insight will help the decision
maker to make more informed decisions, identifying deviations from plans earlier, thus allowing
mid-course corrective actions when it is least expensive to make them. Measurement should not
155

be viewed as a set of predefined measures that never change throughout the program. Instead,
the measures used need to address the current issues at hand, which may change with time. The
measurement process includes the activities for selecting and specifying the measures,
establishing a measurement plan, planning and executing the data collection and storage,
analyzing the data, reporting the results, and most importantly, taking action.
The measures chosen must provide insight into the identified objectives, constraints, risks, and
issues. As this change, the measures in use need to be re-evaluated for adequacy in providing the
necessary insight and changed, if necessary. The measure remains active only if it has a valid,
justifiable purpose.
Generally peaking, when selecting the Performance Measures five major factors should be
considered. Cycle Time, Cost, Quality, Asset Utilization, and Revenue generated.
8.2.1.5.2.1.1 Cycle Time

The first of which is cycle time. Cycle time can be measured as the how responsive an enterprise
is to the customers needs (i.e., the ability to get a product to the marketplace in a timely
fashion). The term can also refer to the ability to increase or modify capacity to produce a
product or service in response to market needs, as well as the ability to respond more quickly to
changes in the marketplace or business environment.
8.2.1.5.2.1.2 Cost

The second major factor to consider when making the business case is cost. The business needs
to have affordable systems or methods of productions for goods and services.
8.2.1.5.2.1.3 Quality

The third factor is quality. Quality does not simply refer to meeting product specifications (or
standards of excellence), but also includes non-quantifiable attributes of business, such as
whether customers are satisfied that the business is providing them with every means to achieve
their own success. Quality is also measured in terms of the robustness and reliability of the
systems provided. The bottom line of quality is that the customer feels that the system is always
available to provide what the customer needs.
8.2.1.5.2.1.4 Asset Utilization

The fourth factor for consideration is asset utilization. In the case of manufacturing, asset
utilization involves the availability of equipment and other assets to produce a product. In a

156

larger sense, asset utilization is also about the ability of the enterprise to be creative, flexible, and
adaptive. One of the issues the business community faces today is a critical shortage of skilled
personnel resources. Ineffective business processes will quickly waste the few resources that are
available.
8.2.1.5.2.1.5 Revenue Generated

The fifth factor for consideration is revenue generated (or the value of the output product).
Clearly, revenue is not the only measure of output in, for example, a government organization
where output may be the number of missions successfully flown, the form of currency, or the
measure of productivity, for the U.S. Air Force. Any parameter for measuring what an industry
produces can therefore, serve as its revenue. Revenue, then not only considers the costs
associated with producing something, but also the benefits gained by the customer receiving the
product. In the case of the Air Force example above, the customer might be the public.
8.2.1.5.3 Goal Prioritization
Critical business issues must be discovered and identified to drive the Change project for the
enterprise.
8.2.1.6 Step 5 - Document, Plan, and Sell
Document your Change Plan. Create a living plan that reflects the continuous improvement of
your operations and change efforts. Make this plan available to all of your managers and teams
to ensure that goals and approach are communicated throughout your organization.
You must sell your program by:

Aggressively supporting the overall Change Strategy

Meeting the change goals, demonstrating success.
Measuring success in terms of customer satisfaction.
Building feedback loops within the organization and to your suppliers and customers.

8.2.1.7 Step 6 - Create Tiger Teams

A fundamental element of the Change Development is the broad use of multifunctional teams to
rapidly develop new products. These working teams are created from representatives of all the
functional organizations involved in the Change Project.
For meaningful, long-lasting results to be achieved for the Change effort, leadership, ownership,
and participation by cross-functional teams is imperative. These teams can be successful only if
their Change efforts:

Have the approval and support at the highest level of an enterprises management.
Involve those individuals who participate in, and manage, the process.

157

Are conducted within the context of the enterprises culture and values.
Invest in the training, education, and tools to establish an in-house re-engineering and
process improvement capability.

The Change Development leader must remember that the key to success is communication.
Therefore, the number of organization levels must be reduced. Teams must be very democratic,
with participation from all members. The teams must have as much decision-making power as
possible.
More suggestions to improve on success of the teams are:

Clear goals: Explain the purpose of the project to all members as well as what is to be
accomplished and by what date. In addition, it is often advisable for teams to set their
own specific subgoals and statement of purpose.
Familiarity: The members of the group should spend time to get to know one another.
The team must be motivated, and much can be accomplished if all the members identify
with the team.
Group activity: Not all work has to be done by the entire Team, but avoid situations
where members work separately.
Full participation: Since the team members are coming from separate functional areas,
no one group should dominate. Recognize that all team members can make valuable
contributions.
Recognition: Individual recognition is a powerful motivator. Give team members proper
credit and visibility during and at the end of the effort.
Attention to conflict: Many teams fail because they never learn to deal with conflict as a
positive and creative force. Training in conflict resolution is highly advisable.
Leadership skills training: Leadership skills training should be provided in
communication, problem solving, decision-making, creativity, and planning for those
appropriate roles.
In addition, training should include interpersonal skills, influence
skills, meeting management skills, and negotiating skills.

8.2.1.8 Step 7 - Implement

No single correct formula or "canned" solution can be used to achieve the change
implementation. Your implementation will be unique in its details, but in general, it should
move your organization towards satisfying the six criteria listed below:

Exceeding your customers requirements and expectations and being a high-quality

supplier of products and/or services.
Supporting significant state-of -then-art change oriented management systems.
Believing in people, working to eliminate barriers that prevent people from having joy
and pride in their work, and involving everyone.
Tapping the power of individuals, multiplying that power through training and teamwork,
and focusing that power on change management and process improvement.
Making decisions based on data rather than on opinions or emotions, stimulating creative
thinking, and seeking rapid innovation in products, processes, and services.
158

While implementing the changes, one should have a constant eye on the five layers for change:
People, the Business, the Processes, the Information, and the Physical (Technology) layer.
While each change or change element will target one of the layers, it will have influences on the
others.
8.2.1.8.1 People
At the top people, characterized by:

Overall Business Ethics

Team Based/Sharing Culture
Communicated Responsibilities
Education, Training and On-Going Support

8.2.1.8.2 Business
The business itself is characterized by:

Commercial Goals and Objectives

Business Strategy and Change/Arbitration Processes
Business Policy/Investment Appraisal/Risk Management
Contractual/Governmental/IPR Constraints

8.2.1.8.3 Processes
The processes are at the center of the organization and are characterized by:

Defined, Documented and Communicated

Interface Management
Organizational Alignment
Metrics and Clear Responsibilities

8.2.1.8.4 Information
At the heart of the processes is the need for information, characterized by:

Semantic Definitions/Understanding/Language
Project Context Rules for Creation and Use
Fixed Software Processes
Integrity Management

8.2.1.8.5 Technology
At the lowest level, we find the Physical Layer that will enable the changes:

159

Data and Technical Standards

Common COTS Applications
Manual Procedures
Communications

8.2.1.9 Step 8 - Monitor

After the changes have been implemented, the Development team should document the
improved performance and the change process. That documentation allows others to benefit
from the lessons the team has learned, brings recognition for the teams efforts, and provides a
road map for replicating successful techniques.
Recommending follow-up actions or subsequent improvement efforts is also appropriate.
8.2.1.9.1 Evaluate Results
Identifying the existing culture and management style of the organization helps to identify those
vital processes to be targeted for change and provides a baseline measurement for judging
progress. Assessments can take a variety of forms and frequently involve identifying and
surveying the organizations internal and external customers, managers, and employees. The
following key considerations are often probed:

What is the mission of the organization?

What products/services are of high value to your customers?
What products/services are provided?
Who are the internal and external customers?
What Measurement Systems are presently in place?
Does the organization measure its success in terms of meeting customer requirements and
expectations?
How well does the organization communicate with its customers and its suppliers?
How much Change Development emphasis is placed on planning as opposed to "fire
fighting?"
What does the organization reward?
Improvement in profit, product, or individual
performance?
To what extent is teamwork used, encouraged, and recognized?
What is the nature of managements relationship with employees unions?
How well do functional units (Business, Design, Manufacturing, Support) cooperate?
Does the executive leadership have credibility in the eyes of middle and line managers?
Front-line workers?
What type of management style is employed? Is it directive or participative?
How much discretion do employees have in making decisions? Is authority delegated to
the lowest levels possible?
What is the attitude toward training?
What is the attitude toward quality work? Is the focus on quality of the end product or
quality of the process?

160

Are the organizations values, goals, objectives, policies, and procedures clearly stated
and widely known?
Does the organization have an abundance of priorities, or have a vital few been identified
and articulated?

8.2.1.9.2 Recognize Success

The success of Change is determined, in large part, by the degree of importance the organization
places on it. Recognition is one of the most important ways to reinforce a proactive, positive
change in behavior as it relates to the new processes. Recognition is given for the successful
application of reengineering principles and practices.
The goal is to create an environment in which change in the customers interest is encouraged,
and then celebrated when it does occur.
Recognition is a means to demonstrate respect and appreciation for all employees, whether
design guru or janitor, and the value they add to your business.
Recognition and reward are not the same things. Recognition means noticing ("recognizing") a
person or team doing a good job. A manager may notice the good job at any point along its
progress - not only when it is completed. Recognition usually takes the form of praise, either
spoken or written. It may be as simple as a word of approval about the way an employee ran a
team meeting, or as formal as a letter of commendation with copies sent to management.
Recognition provides both motivation and support for employees; people clearly work better
when they know their efforts are valued. Research has shown that such reinforcement can also
have a real and measurable impact on productivity.
To provide effective reinforcement,
recognition should:

Be specific. If Sam is told, "Good job on that product design!" he is left not knowing
which part of the design succeeded so well. Managers stand a better chance of having
desirable actions repeated if those actions are clearly specified.
Be directed at the right person. If the product came from a team, and Sam has been out
of town or on vacation while it was being developed, he is not the person to recognize
even if he is the team leader. Who developed the product?
Be genuine!
Be timely. Reinforcement should be given as close to success as possible.
Recognize the used methods, not just results. The results will be unique to any given
situation. The used processes, on the other hand, are versatile enough to handle a wide
variety of situations. It is the internalization of the Change Development processes you
wish to encourage; therefore, that is what you should reinforce with praise.

Reward is given at the completion of a job. It is tangible, and usually comes in the form of
mementos, merchandise, travel, stock, or cash. Rewards range from a simple plaque to a profitsharing program. Rewards say, "You deserve to share in the tangible assets of your work," and
as such can be powerful motivators.

161

Change Development is bolstered by the effective use of recognition and reward. All managers,
at all levels, should continually identify those teams doing a good job - and then create ways to
tell them so.
Recognition and reward should be woven into the very fabric of Change Development. People
who assume responsibility for continuous growth in meeting customer requirements are in turn
motivated to further growth by honest recognition of the large role their efforts play.
8.2.1.9.3 Adjust
Your Change Development planning and implementation efforts must not be locked in concrete.
As you learn more about your companys strengths and weaknesses, change your Change efforts
to reflect the feedback, and if the results are not as expected, then reexamine the problem and
reengineer the effort, based on what was learned.
8.2.1.10 Change Tools
This Section is not meant to give ALL the tools needed to start the Modernization Program. It
only gives overview of the tools that you probably will need during the first phases of your
Modernization Project.
8.2.1.10.1 Success Stories
To motivate management and co-workers a file of success stories, in- and outside the
organization, might be very useful.
8.2.1.10.2 Compendium - Business Technologies
To ensure that every speaks the same language it is advised to edit a "Management Guide to
Business Technologies"
8.2.1.10.3 Total Cost of Ownership-Models
They will allow you to make the cost trade-offs.
8.2.1.10.4 Business Process Modeling Tools
During the Change Process there is a strong need for means that enable better documentation,
communication, understanding, and learning, especially with regard to development processes
and the inherent process know-how. Business Process Modeling (BPM) tools will help doing so.
Which BPM-tool(s) to choose will depend on your ultimate goals. We identify four distinct set
of user requirements for these tools: business diagramming, business analysis, IT requirements,
and IT process analysis.

162

8.2.1.10.4.1.1 To-Be Business Models

Those models (Business Diagrams) might be of particular interest to create a common
understanding between all stakeholders of the new ways to do business.
A process model helps people to get an overview, to understand what part they play in the game,
and to see who is doing what and when. This is even more necessary when processes are
changing very often (e.g., due to reengineering efforts).
8.2.1.10.4.1.2 Why?

Transparency
Understanding and Learning
Coordination
Better Planning and Management
Documentation and Reusability
Prerequisite for audits
What-If analysis
Basis for Process Assessment
Shorter Development Cycles

8.2.2 Guide for Developing a NATO/Government CALS Concept of Operation

8.2.2.1 Section Summary
The concept of operation is your strategy for the creation, use and management of digital data.
The CALS strategy will require different approaches to planning and contracting for the
acquisition of defense systems. The information developed by contractors in management,
design, build, and support functions for defense systems may migrate to a paperless, digital data
delivery and access system. The planning process for implementing various CALS initiatives
needs to include the development of a strategy for the creation, management, and use of this
digital data.
To provide potential bidders with an understanding of specific user needs for technical
information throughout all life-cycle activities, a NATO/Government CALS Concept of
Operation (NCoO) should be developed.
8.2.2.1.1 Purpose/Scope
The planning process for acquiring any defense system needs to include the development of an
information strategy aimed at taking advantage of automation and integration capabilities.

163

This strategy would employ a computer-based environment for generating and storing unique
data elements only once and yet provide multiple accesses to multiple applications. This
strategy, depicted in the form of an NCoO, identifies typical users needs for technical data
throughout all life-cycle activities of defense systems management, design, manufacture, and
support functions.
8.2.2.1.2 How to Use This Section
This section is intended to be used as a guide for creating an NCoO. A structural approach to
implementing CALS requirements is provided. Some examples of the statements to be used in
the Acquisition Plan (AP) are included in this section in the next paragraph CALS
Implementation strategy. Figure 8-1 shows the relationships of the NCoO to the contracting
process. Figure 8-2 diagrams the process required to determine how CALS should be applied to
the contract deliverables.
Further paragraphs provide the general requirements and
considerations for the process described in figure 8-2, including the specific process for defining
the data types and deliverables, data users, data utilization, user infrastructure, data format,
applicable specifications and standards, and data delivery media.
8.2.2.2 CALS Implementation Strategy
Before developing a NATO/Government CALS Concept of Operation (NCoO), the Acquisition
Plan (AP) should show a clear signal of commitment to the NATO CALS strategy. For this
purpose, the AP should include the following statements:

The [XYZ] program will take advantage of existing and emerging automation and
integration capabilities to establish a computer -based environment for creating,
managing, and storing data elements once for multiple applications across engineering,
design, manufacturing, and logistics functions and processes. The program will stress
continuous engineering, digital data delivery, and on -line electronic information services
in the solicitation process and resulting contract(s).
Continuous Acquisition and
Life-cycle Support (CALS) standards and specifications for digital technical information
exchange will be cost effectively implemented.

The [XYZ] project intends to implement CALS and Electronic Data Interchange (EDI)
initiatives to reduce life-cycle costs, improve product quality, reduce program risk, and
reduce the schedule of the design, development, and production.
The technical
information required in support of the project will be made accessible through on -line
contractor integrated technical information (electronic) services; physical delivery of data
required for sustaining support activities will be in accordance with approved CALS
format standards and specifications. For contract data requirements not evaluated as
cost-effectively delivered to the CALS standards/specifications, delivery will be in
mutually agreeable digital formats. The digital formats for all data users and user
systems will be determined cooperatively between the government and contractor using
the NATO/Government CALS Concept of Operations (NCoO), developed by the project
office, as the basis for selection. The draft and final RFPs will incorporate requirements
for the offeror to address implementation of concurrent engineering and digital
delivery/electronic access of program technical information. Significant weighting will
164

be applied to the CALS and EDI elements in source selection evaluation (not less than 10
percent of the total evaluation/rating).

Offerors will be evaluated on their ability to provide integrated, shared databases

environments for engineering analysis, design, manufacturing and logistic processes; and
their use of CAD/CAM/CAE methods, product models/databases and simulation tools to
improve product design, testing, manufacturing and support system development. The
program will integrate specific program solutions with those developed by the NATO and
Nations infrastructure modernization initiatives and will implement, where value
-effective, joint service CALS and EDI systems for the creation, management and use of
digital technical information.

8.2.2.3 Relationship of the NCoO to Contracting Process

The NCoO generated utilizing this guide will provide potential bidders an understanding of
specific NATO needs for technical information throughout all relevant life-cycle activities of the
defense system. The relationship of the NCoO to the various contracting steps is shown in
Figure 8-1 .

165

Pre-RFP/RFQ Activities

- Acquisition Planning
- Data Gathered
- CDRL Developed
- NCoO Developed

RFP/RFQ Release

- Data Deliverables & Types

- Users
- Users of Data
- Support Infrastructure
- Delivery Modes/Format/Media
- Specifications / Standards
- Evaluation Criteria

Contractor Proposal

- CAC with CITIS PROPOSAL

(If CITIS Required)
- Bidder Suggestion for Most
Effective Interchange

Proposal Evaluation

- CALS Evaluation Criteria

in Management Element
- CAC Evaluation

Negotiation

Contract Award

- Modification to NCoO
- Modification to CAC
- CDRL Modifications

- Develop CALSIP for Approval

- Upgrade Infrastructure (if required)

Figure 8-1 The CALS NCoO in the Contracting Process

8.2.2.3.1 Pre -Request For Proposal/Request For Quotation Activities and RFP/RFQ
Release
The NCoO planning process should start as early in the acquisition process as possible. The
NCoO is a document that is prepared during the acquisition planning and requirements
determination activity for each procurement. It is used to provide information to potential
offerors about NATOs or the NATO nations infrastructure and CALS implementation strategy
for defense systems. The process for gathering the NCoO information should simply be part of
the overall data call conducted during the pre-RFP/RFQ activities. An NCoO survey should be
distributed to the functional organizations to gather the information.

166

Development of a NCoO will help ensure that NATO/NATO nations, referred to, from now on,
as the CUSTOMER, receives the correct version and formats of digital data products needed to
acquire and support a defense system. The NCoO can assist the project manager in determining:

The hardware and software systems the customer has, or is developing, to manage and
use the data;
Data users, types of data, frequency of use, and timeliness of data access or delivery to
each user;
Data use and the review and/or approval processes to support life-cycle functions;
Users locations and their primary functions in support of the defense system;
Data interchange requirements including format, media, applicable standards, and
existing telecommunications capabilities;
Access authorizations and restrictions;
Data acceptance requirements including data format and content of data and the customer
processes for accepting product, processable, or Contractor Integrated Technical
Information Service (CITIS) data.

A flow diagram of the entire process is shown in Figure 8-2 .

8.2.2.3.2 Contractor Proposal
Referencing the NCoO, potential bidders should be required to develop a Contractors Approach
to CALS (CAC) in their prepared responses to the RFP. The CAC is a description of the
contractors approach, experiences, and successes in the creation, management, use, and
exchange of digital information identifying capability in the area of CALS. The customer during
the source selection process can then evaluate the CAC. If CITIS requirements are included in
the RFP, the contractor should address the approach to CITIS within the CAC.
The contractor should state, in the CAC document, its experience and successes
in the creation, management, use and exchange of digital information.
Bidders should be encouraged to identify, within their CAC, a more efficient and more cost
effective data strategy and to propose alternative forms of delivery of digital data products and
information services that reduce life-cycle costs and improve business processes.
8.2.2.3.3 Proposal Evaluation
Information in the CAC is used to gauge the risk associated with the contractors ability to
provide the digital data products and services required by the RFP.
8.2.2.3.4 Negotiation
Differences in concepts of operation between the customer and the bidder selected through the
source selection process become a subject for negotiation. The agreements reached during
negotiation become the basis for a contract that triggers feedback to all involved in the support of
the defense system and subsequent changes to the NCoO and perhaps the CAC.

167

Any selected alternatives proposed by the contractor must also be incorporated into the contract
and appropriate Contract Data Requirements List (CDRL).
8.2.2.3.5 Contract Award
The solicitation and ensuing contract should state that an objective of the acquisition is to require
the contractor to generate information products for development and production functions in an
integrated information system and a shared data environment to the maximum extent practicable.
Ideally, this integration should be achieved as part of a comprehensive concurrent engineering
strategy. The integrated environment will provide for generation, storage, indexing, distribution,
access, and delivery of digital technical data products in support of defense system development
and production functions and processes. The objective is to create each data element once
and use it repeatedly in subsequent processes without manual reentry work and labor
costs.
The contract should require the contractor to generate information products
for development and production functions in an integrated information system
and a shared data environment to the maximum extent practicable.
Developing this integrated environment will most often require a phased approach for
implementation. To facilitate a phased implementation of the CALS strategy, the program
manager may wish to require a CALS Implementation Plan (CALSIP) as a contract deliverable
(typically 60 days after contract award) that is maintained throughout the life of the contract.
8.2.2.4 Background Information for NCOO Development
The NCoO must provide potential bidders an understanding of specific customer needs for
technical information throughout all relevant life-cycle activities of the defense system. The
NCoO must be thoroughly developed for potential bidders to respond with a proper CAC.
Therefore, the acquisition of technical data by the Program Manager requires a detailed
definition of data requirements. The effective definition of these technical data requirements
necessitates the complete identification of data needs and uses. Identification of these data
requirements can be effectively accomplished using a well-defined process described in this
section. A flow chart of the entire process is shown in Figure 8-2.

168

1. Identify what types of

Data are required

2. Identify who will

use the Data.

Product Description Data

ILS/LSA Plans & Reports
Publications
Management & Admin Data

5. Identify the type of

digital data deliverables.

Management
Engineering/Design
Supply
Training
Manufacturing
Maintenance

6. Determine the
required data format.

3. Identify what the user

will do with the data.

4. Identify users
infrastructure.

View only
Comment/Annotate
Update/Maintain
Extract/Process/Transform
Archive

Hardware
Software
Networks

7. Determine what
interchange standards
are required.

Composed Products

Document Image File

Document Image Standards

Processable Data Files

Text File
Graphics Files
Alpha Numeric File
Audio/Visual File
Integrated Data File

Text Standards
Graphics Standards
Applications Unique/
Data Standards

8. Determine the mechanisms and type

of media for data delivery/access.
Hard copy
Physical (Magnetic Tape, Optical Disk)
On-line CITIS Telecommunications

Figure 8-2 NCoO Development Process

8.2.2.4.1 Identify Data Type Deliverables
Data type deliverables are the data requirements specified on the Contract Data Requirements
List (CDRL) for a typical program categorized by program function and type. A survey of
supporting defense system activities during the requirement determination process will establish
data requirements. Sample data types to be digitally developed, accessed and/or delivered, and
maintained are listed in Table 8-1 . Note that this table is not intended to be all-inclusive, nor are
all deliverables listed required for all projects; the list of deliverables must be tailored to the
project requirements.
Table 8-1 Typical Data Type Deliverables
Management and Administration Data
Program Plans
Program Schedules
Engineering Support Plans
Progress and Status Reports/Master
Schedule
Contractual Vehicles
Conference Agendas/Minutes
Reviews and Audits Documents
Technical Data Identification Checklists

ILS/LSA Plans and Reports

Integrated Logistics Support Plan (ILSP)
Logistics Support Analysis Plan (LSAP)
Logistics Support Analysis Record (LSAR)
Safety Assessment Reports
Reliability Assessment Reports
Maintainability Reports
Hazardous Materials/Process Reports
Tailored LSA Tasks

169

Management and Administration Data

Standardization Program Plan
Contract Work Breakdown Structure
(WBS)
Cost Performance Report
Management Information System (MIS)
Plan
Config. Audit Plan/Status Accounting
Report
Data accession list
System Engineering Management Plan
(SEMP)
CALS Implementation Plan (CALSIP)
Technical Data Package
System Specifications
Engineering Drawings and Associated
Lists
Analysis Data
Simulation Data
Test Data
ECP, RFW, and RFD
Product Specification
Software Development Management Plan
Software Test Plan/Description/Report
System Specification Report
System Engineering Analysis Report
Engineering Data

ILS/LSA Plans and Reports

Maintenance Plan/Reliability Plan
Maintainability Plan
Level of Repair Analysis (LORA)
Test and Evaluation Master Plan
Test Reports
Life-cycle Cost Estimates
Configuration Management Plan
Manufacturing Plan
Environmental Impact Report
Technical Report-Study Services
Quality Program Management Plan
Computer Resources Integrated Support
Document
Design to Cost Plan
Publication
Technical Publications
Technical Manuals
Users Manuals
Operations Manuals

Discipline, functional activity, type, or other such groupings to facilitate a standardized approach
to applying the CALS digital data standards and specifications should categorize the data
deliverables.
8.2.2.4.2 Data Users
The data users, as shown in Table 8-3 are the functional organizations that will require access to
the program data. These organizational areas typically include acquisition, engineering/design,
supply, training, manufacturing, and maintenance. In addition to their functional responsibilities,
these organizations are defined by their location and the specific disciplines involved and may be
different from nation to nation.
8.2.2.4.3 Identify Data Use/Processing
The data use requirements are the ways in which the chosen data types may be considered for
processing. The project manager will need to identify the use of the data types by the support

170

organizations chosen for the program. The five defined methods of data processing typical of
most defense systems are described below.

View only - the ability to examine a data file without the ability to change it. This
includes viewing selected portions of one or several documents as well as side-by- side
comparisons of documents.
Comment/Annotate - the ability to evaluate and highlight for future reference or to
make annotations, approvals, and comments without the ability to change the original
file. Annotations are associated with a specific item or location within a document such
that the annotations are displayed whenever that point or area of the document is
displayed.
Update/Maintain - the ability to change data either directly or through controlling
software in the active files on the host computer.
Extract/Process/Transform - the ability to extract and modify the format, composition,
and structure of the data into another usable form.
Archive - the placing of data into a repository to preserve it for future use.

8.2.2.4.4 Identify Data User Infrastructure

The availability of digital data processing and telecommunications technology and approved
standards for creation, storage, transmission, data protection, and integrity of data at the time of
delivery or access are important criteria for acquisition decisions. The current and projected
capabilities of both the contractor and of defense agencies must be assessed with respect to
program needs and schedules.
The NCoO is an excellent vehicle for making these determinations. Project managers should
plan to access or acquire digital data products rather than hard copy unless a clear case can be
made that the costs will outweigh the life-cycle benefits.
Buy digital data that can be reused more easily than paper deliverables.
The data user infrastructure is the computing environment available to a particular user. This
environment establishes the data processing capabilities of that user. The following areas
identify a users infrastructure:

Hardware: Determine the current and planned hardware available to support the program.
Software: This is the most critical element. Interoperability will normally be achieved
using software. Again, determine both present and future software applications and
availability.
Networks: Determine the local- and wide-area networking capabilities and whether
CITIS will be used.

In the case of NATO procurement, it should be noted that different nations might have
different systems.

171

Computer support personnel: Consider the skills and expertise required to establish,
operate, and maintain a functional and reliable computing environment.
Communications: Determine data communication capabilities.

Table 8-2 describes a sample of the data user infrastructure and capabilities.
Table 8-2 Data User Infrastructure and Capabilities

NACMA

Hardware

Word
Processor

Graphics

PCS on
TEMPEST
and nonTEMPEST
LANs

Word
Perfect
Version 6.1

Corel
Draw
Version 5.0

Spreadsheet
MS
Excel
Version
5.0

Databases

MS
Access v.2
Ingres
Version 3.0

SGML

Yes

Acceptable
Means of Data
Delivery
DOS Floppy
3.5 inch
D-ROM
Analogue
Modem
Group 3 FAX

Belgium
France
Germany
Italy

8.2.2.4.5 Identify Type of Data Deliverable

Following are types of digital deliverables supported by delivery and access methods specified
by project managers.

Composed Products: Human interpretable documents in digital image format. These

items cannot be further processed since they are complete, published entities. Examples
of data products that could be delivered or accessed in this format include legacy
engineering drawings, technical reports, and test plans.
Processable Data Files: Machine readable dynamic information that includes revisable
source data for multiple data applications, thus enabling standard and custom documents
to be generated and the source data to be manipulated. Examples of processable files are
LSAR files, files extracted as subsets of computer-aided design files, and technical
manual text files delivered in Standard Generalized Markup Language (SGML) format.

8.2.2.4.6 Determine Data Format

The following data formats are the forms in which each of the types of data deliverables can be
procured. Refer to figure 1-2 for their relationships to the type of data deliverable.

Document Image File

Text File
Graphics File
Alphanumeric File
172

Audio/Visual File
Integrated Data File

8.2.2.4.7 Determine Data Interchange Standards

In order to ensure the proper sharing and exchanging of information across dissimilar systems,
the project manager should consider the possible loss of intelligence when translating
information from one data format to another (whether the format is standard or not). The
following types of interchange standards are used with data formats:

Document Image Standards

Text Standards
Graphics Standards
Application Unique/Data Standards

8.2.2.4.8 Determine Data Delivery and Access Media

The two options that a project manager may use to support digital delivery requirements are
physical delivery and on-line delivery via telecommunications.
Digital delivery and access
requirements are specified through the SOW, the CDRL, and specific Data Item Descriptions
(DID).
8.2.2.4.8.1 Physical Media
Magnetic tape is a mature, stable technology that is able to handle the large volumes of data
typically associated with a major defense system acquisition. Magnetic tape standards are well
defined, and little additional investment cost will be involved. However, other media may be
more efficient and, therefore, preferred. Magnetic disk is also widely implemented on personal
computers and workstations and may be the physical medium of choice for small business
contractors. Several primary de facto magnetic disk formats are available but no official
standard has been accepted. Compatibility problems exist, but can be overcome with only
moderate effort. Optical media is used here as a generic term to include Compact Disk-Read
Only Memory (CD-ROM), Compact Disk Interactive (CDI) and Digital Video Interactive (DVI),
Write Once and Read Many Times (WORM), and erasable optical disk. These media are ideal
for mass distribution and archival purposes for large volumes of data.
8.2.2.4.8.2 Telecommunications
On-line delivery may be achieved via two methods:
1. Delivery of CDRL items from a contractor sending system to a customer receiving
system via telecommunications download; or
2. In-place delivery, which allows data items to be stored and maintained at a contractors
site for retrieval and display via telecommunications using a customer terminal, personal
computer, or workstation.

173

On-line access, as distinguished from on-line delivery, refers to the situation in which an
organization accesses data items through CITIS services, or other similar information
management services, as negotiated in the contract.
Secure, on-line transmission of the full volume of data for defense systems is technically feasible
but severely taxes current telecommunication networks. In the near term, telecommunications
may be limited to electronic mail exchange of high-priority technical data, the use of mutually
agreed EDI transactions, or other clearly defined uses such as CITIS access. On-line interactive
access provides immediate and timely data access for custom report generation, document
generation, and on-line request of information transmitted as composed products and processable
data files. Project managers should give preference to use of CITIS for performing the functions
of updating, storing, controlling, reproducing, and distributing data items.
As an interim
standard, MIL-STD-974 provides information concerning core and tailorable CITIS functions
that should be specified in the SOW and listed as contract line items. In the long term, cost
effectiveness will be essential for successful implementation of a totally integrated defense
system database.
Upon completion of the NCoO, the logistics manager responsible for technical data will be
prepared to enter the solicitation and source selection process with a firm CALS implementation
strategy and knowledge of the needs and capabilities for acquiring and using digital data.
8.2.2.5 Data Acquisition Requirements Method
The identification of information for inclusion in the NCoO is described in the following sections
and shown in Figure 8-2 . The project manager can employ and adapt this methodology to a
specific acquisition to develop the program requirements for digital data delivery or access.
8.2.2.5.1 Identify Data Type Requirements
The project manager will need to gather the data requirements of all the data users and select the
data types that are necessary to accomplish the program objectives. Each of the specific types of
data required will be determined by the unique conditions and constraints associated with a
specific program. The data types selected will ultimately influence data format, interchange
standards, and media considerations. The best method for determining the types of data
deliverables required is to extract the data deliverables list from the CDRL and to categorize the
data types.
The project manager must also be aware of the various infrastructure modernization programs
that are in place, or soon to be in place, to accept, manage and use digital data. Any data
deliverables that will require updating and maintenance throughout the life-cycle of the defense
system (engineering drawings, TMs, LSAR, etc.) are excellent candidates for digital delivery and
making use of the infrastructure modernization programs. Use of these modernization programs
should be seriously considered during NCoO development.
The project manager should certainly take advantage of these programs in place for the
management and use of data deliverables in digital formats.

174

8.2.2.5.2 Identify Data Users

The project manager will need to identify the organization(s) requiring data and the functions of
the organization.
Program-specific conditions and constraints will determine which
organizational areas require data. Once the required organizational areas have been determined,
the name of the organization, the organizations function (what services they provide), the
location of each organization, and the Point of Contact at each organization should be provided.
Table 8-3 is an example of data users for a typical program.
This information provides potential bidders with an understanding of the separation of work
functions and the scope of geographic locations for data transmission requirements or other
modes of data delivery or access. An added benefit from developing the Data Users Table is
provided to the customer in terms of clarifying the functional areas required to support the
defense system acquisition.
Table 8-3 Data Users
Organization

...
...
...

Location

...
...
...

Point of Contact

...
...
...

Disciplines
(Functional Areas)

...
...
...

175

8.2.2.5.3 Identify Data Use/Processing

The project manager will need to consider how the data will be processed to make decisions on
digital data requirements and format. The data use requirements may be influenced by the data
user selected and the supporting infrastructure. For those that need to view the data only, a word
processing file will suffice for most data types in lieu of paper. As users needs become more
sophisticated, such as a need to annotate/excerpt or more importantly, update/maintain or
process/transform the data, standardized digital delivery becomes even more essential. The
project manager will need to match the digital data deliverables to the existing or planned suite
of equipment that makes up the users infrastructure.
To complete this step in the NCoO process, the project manager needs to identify the
deliverables required by the organizations using his data. An added benefit of this task is that as
each organization determines its use of the data, deliverables are often discovered that are no
longer needed and can therefore be dropped from the CDRL, resulting in a cost savings for the
program.
8.2.2.5.4 Identify Data User Infrastructure
To assist the project manager in determining the users infrastructure and how it will affect the
type of data required, a data acquisition questionnaire has to be developed. Responses to the
questionnaire will aid in giving not only potential bidders, but also the customer, a clear picture
of the supporting infrastructure in place to support the defense system. The data users
infrastructure or data processing environment will influence several areas of the data acquisition
process including delivery/access method, data format, interchange standards for the data, and
media for data delivery. Since each supporting activity (data user) may have quite different
infrastructures, the project manager will need to be aware of the various data requirements
imposed by the different infrastructures and make attempts to bring commonality to the suite of
tools available.
8.2.2.5.5 Identify Type of Data Deliverable
The project manager will need to identify the type of each data deliverable. Since composed
products cannot normally be modified, this file type is recommended primarily for legacy data.
Processable data files are the preferred data type for most new deliverables. Table 8-4 is an
example of data deliverable types as well as other information for a program.
Table 8-4 Data Types
DATA TYPE

MANAGEMENT AND
ADMINISTRATION DATA:
Program Plans
Engineering Support Plans
Progress and Status Reports
Contract Vehicles

DATA
DELIVERABLE
TYPE

1, 2
1, 2
1, 2
1, 2

FORMAT

A, B, C, E, F
A, B, C, E, F
A, B, C, E, F
A, B, C, E, F

176

MEDIA

a, b
a, b
a, b
a, b

DATA TYPE

DATA
DELIVERABLE
TYPE

PRODUCT DESCRIPTION
DATA:
Drawings/Associated Lists
ECP, RFW, RFD
Analysis Data
Simulation Data

1, 2
1, 2
1, 2
1, 2

FORMAT

B, D
A, B, C, E, F
A, B, C, E, F
A, B, C, E, F

MEDIA

a, b
a, b
a, b
a, b

1. Composed Products

2. Processable Data Files

3. Media

A. Hard Copy
B. Page Image

C. Text File
D. Graphics File
E. Alphanumeric File
F. Audio/Visual File
G. Integrated Data File

a. Physical (Magnetic Tape

or Disk, Optical Disk)

b. On-line (CITIS)
Telecommunications
(X.25, TCP/IP,
Contractor Specific)

8.2.2.5.6 Identify Data Format Required

The project manager will need to identify the standards to be used and data format(s) for
delivery, which is determined by the type of data deliverable. The chosen formats will affect
interchange standards used and the media used for data delivery. Table 8-4 is an example of
data format as well as other information for a program.
There is little benefit to receiving hard copy deliverables for any use other than view only.
Realizing that most data generated by the contractor now starts out in some digital format (word
processing, graphics development, spread sheets, CAD, etc.), the project manager should avoid
hard copy format whenever possible. As a minimum, document image files (page description
language files) should be considered for distribution in lieu of hard copy.
Most deliverables generated by the contractor can be utilized in their native format (processable
data files) if the customer has a compatible suite of hardware/software or a CITIS environment is
employed.
In addition, text, graphics, alphanumeric, audio/visual, and integrated data file
formats lend themselves to applying the CALS standards for data interchange. .However, it may
not be cost effective to apply CALS standards to these data formats until the final deliverable.
For example: a TM will go through many iterations of authoring, review/comment, editing, and
distribution before the final delivery. Typically, the manual is being developed on a word
processor or desktop publishing system. It may not be cost effective to invoke the CALS
standard until such time that the customer has the infrastructure in-place or takes final delivery of
the document and thereby becomes responsible for its configuration control, archiving, and
maintenance. Therefore, the project manager may want to take advantage of the native file
format during the early phases of the contract if compatible with the existing customer
infrastructure.

177

Specific data formats and delivery modes should be stated on individual CDRL items. Proper
safeguards should be used for classified information. In general, the following formats and
delivery media are recommended for each data type.
Section 9 and Section 10 of this Handbook contain details of applicable standards.

Management and Administrative Data: This data should be available through CITIS. Online management status data should be analogous to that available to contractor program
managers.

Product Description Data: Initial Graphics Exchange Specification (IGES). As digital

format and delivery standards are introduced for additional product description data (i.e.,
intelligent product data, models, etc.), CDRL delivery requirements may be modified
appropriately.

Integrated Logistics Support (ILS)/Logistic Support Analysis (LSA) Plans and Reports:
Mutually Agreeable Commercial Software (MACS) formats. Text-based documents
should be generated in a commonly used, word processing format. Ancillary graphics,
spreadsheets, and other associated data files should be developed in common business
software. These files should be provided as separate files in their native formats as well
as incorporated into a master document. It is preferred that these files be delivered
electronically over the communications network.
Depending on file size and
communication speed, this may necessitate MACS file compression routines or floppy
disk delivery. Relational database formats should be capable of being accessed via
Structured Query Language (SQL) and delivered in accordance with MIL-STD-1840. In
the near term, LSAR data tables should be in accordance with MIL-STD-1388-2B;
NATOs long-term plan is to merge these data into a new international Acquisition
Logistics Standards.

Publications: Publications, manuals, specifications, and other documentation that will be

updated and maintained over the life-cycle of the program should be developed in SGML
with graphics in Computer Graphics Metafile (CGM).

8.2.2.5.7 Identify Data Interchange Standards

Each of the data formats requires certain interchange standards to remain CALS compliant. The
project manager needs to identify the interchange standard required for each data format.
However, these interchange standards will vary depending on the data types selected. User
infrastructure will also influence which standards should be used. The required interchange
standards should be stated in the Statement of Work (SOW) and the CDRL.
8.2.2.5.8 Identify Data Delivery and Access Media
Source: UK CITIS Guide; US Mil Std on CITIS, NCO HB V 1 Section 5
The project manager will need to determine the data delivery/access media or mechanism
required for each data type selected. Interactive access via CITIS should be the preferred method

178

of data delivery. A variety of factors can influence the decision for a CITIS requirement,
including program phase, data type and format, volume of data being delivered, lifetime of the
data, the interchange standards required, and the cost to implement the system. The data delivery
and access media should be specified in the SOW and CDRL.
Telecommunication networks provide an excellent opportunity to exchange and establish
common practices for business type data using commercial Electronic Data Interchange (EDI)
transactions. EDI is the computer application to computer application exchange of business data
in a standard format between trading partners. Currently there are numerous transaction sets that
transfer data in the functional areas to procurement and contract administration; finance and
payment; transportation; supply management; maintenance; fuels; and program management.
Transaction sets have been developed to support project-scheduling reporting, cost performance
reports, cost/schedule status reports, and contractor cost data reporting. The project manager
should consider taking advantage of using EDI for program administration process
improvements UN/Electronic Data Interchange for Administration, Commerce, and Transport
(UN/EDIFACT) will be used for electronic transmission of such data.
The standards for delivery and access media are shown in Section 9 of this Handbook.
8.2.3 Concurrent Engineering
Source: NCOPS 3.2
Concurrent engineering means simultaneously performing both the actual and simulated
processes of designing and developing a product. All phases of a product are considered
concurrently, with the design modified as necessary to make sure the product is useful at all
stages of its life-cycle. The materials and efforts needed to manufacture, maintain, and dispose
of a product are determined while the product is undergoing design. Problems in later life-cycle
stages are anticipated and dealt with before they can arise. Clearly concurrent engineering
reduces the costs involved in solving such problems while a product is being built or after it has
been released in the field. The least expensive changes in a products life-cycle occur in the
design phase, so concurrent engineering concentrates on making changes there. Quality is
improved, products come to market faster, and costs are reduced.
Concurrent Engineering saves time and money but greatly increases the requirement to share
information and to manage product change over the whole of the life-cycle. Concurrent
Engineering is difficult to achieved in practice without a Shared Data Environment.
Concurrent Engineering differs from the traditional approach to defense system development
(e.g., PAPS, see Annex B) in two important respects:

It uses continuous iteration of processes to evolve a satisfactory solution through a series

of repeating steps. For example, an early prototype may be built, deployed, and tested in
the operational environment, simply to clarify the requirement.

It breaks down traditional barriers between functions and between organizations, by

creating and disbanding (as necessary) Multi-Disciplinary Groups that have the necessary

179

skills to solve the problem in hand. For example, a maintainer, a designer, and a parts
supplier may be brought together to solve an in-service problem, even though they
worked for three different organizations.
The Concurrent Engineering approach replaces the traditional sequential approach by a series of
overlapping activities, which progressively evolve, or refine, the design towards a fully
acceptable solution. This is illustrated by the following figure:

Zig-Zag
Problem

Requirements

Design

Implementation

Figure 8-3 Refinement

In this approach, recognition of a problem leads to a first attempt to document the requirement.
This in turn provides more understanding of the problem itself, and hence an improvement in the
problem definition. In a similar way, the emergent requirement may prompt an initial design
solution, which generates new questions as to what is actually needed. The rigid limitations on
completing each phase before the next can start are relaxed. Sequential design is replaced by a
design spiral. Buy a little, deploy a little, test a little becomes a more practical approach.
Source: DND Canada CD
Source: Knox, Rita E. and Russell J. Daty, New Technologies for Concurrent Engineering,
CALS Journal, Volume 3, No. 1, Spring 1994, pp. 63-67.
8.2.3.1 The Key to Concurrent EngineeringShared Data
For concurrent engineering to work, information has to be shared extensively. Instead of having
individuals concentrate on one aspect of a product, or one aspect of its life-cycle, all those
involved need to know about all aspects of the product. In addition, since the design is

180

constantly changing and evolving, they need to be sure they are getting access to the current
version.
Shared information is key, but often implementations of concurrent engineering attempt to
cobble together a number of discrete, specialized applications (CAD, MRP systems, paper-based
systems, release systems, and so on). Information is often difficult to access or share.
The solution is a shared data environment that can store all the information needed by all those
involved, without limiting access based on life-cycle stage.
8.2.3.2 Example Use of an Integrated Database
To demonstrate the benefits of using a shared database for concurrent engineering, consider the
process of designing and creating a computer mouse.
8.2.3.2.1 Design Process
A designer creates the mouse design layout using a split case that snaps together. As in a
traditional system, the design is created on a CAD system. However, each component part is
placed in the integrated database, including information about its materials and vendors.
8.2.3.2.2 Maintenance Analysis
A simulation performed using the mouse design finds some problems and recommends that the
lower half of the case be split into two (to allow access to the track ball) and that the top and
bottom of the case be attached using screws instead of snap locks.
In a conventional system, this finding requires someone to create a change request, on paper or
through electronic mail.
With the integrated database, the change request is entered directly into the database, associated
with the version of the design that posed the problem. The change request contains many details
such as the person asking for the change, the date it was requested, and the approval or
disapproval of the change. The change request remains in the database for future reference.
8.2.3.2.3 Design for Manufacturing Analysis
An analysis shows that the use of screws increases the cost of the mouse.
In a conventional system, the supporting information for this finding exists in paper documents
or text files, and probably cannot be linked easily to the change request that prompted the
comparison of the two methods.
With the integrated database, the change request for the screwed-together case is available to the
testers, who disapprove it, with reasons, and enter a change request for the changed material. A
trail of request/disapproval/reason is established and maintained.

181

8.2.3.2.4 Detailed Design

A designer creates a detailed design for each piece of the mouse.
In a conventional system, pieces are in a separate CAD file, produced by different people. One
designer is often not able to access the design work of another. The CAD files are detached from
other product information.
With the integrated database, individual parts are regularly posted for others to see. All product
information is kept together in a central location.
8.2.3.2.5 Assembly Analysis
Analysis of the mouse shows that it may stick under certain conditions.
In a conventional system, confusion can arise about which version of the mouse caused the
problem. A written report about the problem is generated.
With the integrated database, version control ensures that the test results are applied to the
correct version of the design. Recommendations, along with their reasons and consequences, are
attached directly to a specific version of the product.
8.2.3.2.6 Re -design
The mouse button is modified to eliminate the sticking problem.
In a conventional system, a paper change order is prepared and entered into the review and
approval process.
With the integrated database, the change order is implemented in the database, which can also be
used for review and approval processes. All the steps leading to this change are recorded in the
database from previous activities.
8.2.3.2.7 Release
Individual parts are released for manufacturing, along with bill of materials and information on
assembling the mouse.
In a conventional system, the CAD files are released, often with hard copy drawings.
release forms and bill of materials are prepared on paper.

The

With the integrated database, approvals for release are performed right in the database. All the
current information, including version, quantities, materials, manufacturers, and so on is located
in the central database and available at all times.

182

8.2.4 CITIS - Implementation of Contractor Integrated Technical Information Service

8.2.4.1 Introduction
The Contractor Integrated Technical Information Service (CITIS), as its name implies, is a
service not a product. It is a contractor-developed and maintained service to provide electronic
access and/or delivery of NATO-procured contractually required information.
CITIS is
generally acquired from prime contractors who may also use electronic networks for access and
delivery of information from their suppliers. Thus, the prime contractor is the information
integrator for a specific program/product acquisition.
CITIS exemplifies the CALS philosophy of creating data once and using it many times.
Project managers should give preference to use of CITIS for performing the functions of
updating, storing, controlling, reproducing, and distributing data items. CITIS satisfies one of
the major CALS objectives to furnish a single entry point for authorized access to
contractor-generated data. CITIS exemplifies the CALS philosophy of creating data once and
using it many times. It establishes a set of core information functions to facilitate the CALS
concept of "shared data, and it standardizes functional characteristics of the data to facilitate its
usage by a wide variety of different users.
8.2.4.1.1 The Primary Advantages of Using CITIS
The primary advantages of using CITIS include:

Substantial reduction in the amount of data delivered and stored in paper format;
Improved accuracy and timeliness of data;
Improved management and tracking of review status;
Reduction in review cycle time;
Improved comment collection and correlation;
Consistency of data used by all agencies/activities;
Readily accessible archive/repository of program date;
Facilitated sharing of data within the contractors own enterprise, between the contractor
and the users, and between the users activities and locations;
Reduced lead times and costs for weapons system design, manufacturing, and support
processes;
Technical information accuracy and timeliness.

Although there may be some initial identifiable costs associated with implementing a CITIS,
carefully-selected CITIS requirements should result in substantial savings over the program lifecycle by reducing costs for data generation, delivery, and access/usage. Cost savings should be
realized not only in terms of reductions in paper purchases, copying costs, and actual delivery
costs, but also through a substantial reduction in the labor required to locate, access, and process
information. A CITIS has the potential to greatly improve the efficiency of both the contractors
and the users processes.

183

Contractors already gravitate toward CITIS environments independent of NATO/NATO nations

efforts to achieve effective information management. The project manager should keep in mind
that the usefulness of CITIS will increase as NATO/NATO nations operations are streamlined
and contractor capabilities are developed.
8.2.4.2 The Decision to Acquire CITIS
Project managers considering procuring a CITIS for their programs need to take into account the
number, type, and use of deliverables, the number and locations of the data reviewers/users, and
the cost to develop and implement the CITIS. A requirement for CITIS, part of the CALS effort,
should never be driven by a mandate to implement CALS. The decision to utilize a CITIS
requires careful analysis of the programs data requirements and usage. The data call and NATO
CALS Concept of Operation (NCoO) data collection process provides the best method for
compiling and assessing this type of information.
After the data is analyzed, the possible CITIS functions must be studied to determine which
functions will be beneficial to the program. This type of up-front research is necessary to
prevent the project manager from acquiring a CITIS that is inappropriate for the program. Table
5-1 presents a method of placing a relative value on each of the key questions along with an
overall scoring method to assist the project manager in the CITIS decision process.
Table 8-5 CITIS Decision Scorecard
Program Consideration Question

Value
(#Points)
2

YES/NO

Are there a large number of reviewers and/or

users for most data items?
Are the majority of CDRL items suitable for
3
delivery via CITIS?
Is the infrastructure between locations
1
generally compatible?
Do a majority of CDRL item recipients plan
3
to do more than archive the data?**
Are CDRL item recipient locations widely
1
dispersed?
Is currency of the data very important?
1
Do you currently have any form of electronic
1
communication with contractors or other
activities?
Will data be updated/changed often?
1
TOTAL SCORE
No = zero*
Yes = assigned value**
Note: More than archive means users will view, extract/process/transform,
update/maintain, and/or comment/annotate data
Total Score
Decision

184

SCORE*

Program Consideration Question

0-3
4-6
7-10
11-13

Value
(#Points)

YES/NO

SCORE*

CITIS not recommended

CITIS may be valuable; perform further assessment
CITIS recommended
CITIS highly recommended

8.2.4.2.1 Preliminary Data Collection

The first step in the CITIS decision process is to gather all the data needed to make an informed
decision. Compiling and analyzing the NCoO survey information can best do this. The results
of the NCoO survey will provide the project manager with information on the data requirements
and usage at each of the functional areas, along with their existing infrastructure. All of this
information is critical to the determination of the CITIS requirements. If an NCoO is not being
created, the project manager must find some other means of gathering the data needed to assess
the advantages of a CITIS.
8.2.4.2.2 Number of Data Reviewers and Users
The benefits of a program CITIS are typically directly proportional to the number of user data
reviewers and final users. That is, as the number of user nations and NATO/NATO nations
contractor support personnel that review, generate comments, and process data deliverables
increases, so do the potential benefits of the CITIS itself.
8.2.4.2.3 Recommended CITIS Deliverables
Before deciding on a CITIS, the project manager should first identify typical usage of the CDRL
items (e.g., are they viewed, updated, processed, etc.). This information should be available
from the data gathered during the data call and NCoO development process. The manager
should then determine whether enough deliverables are suitable for on-line delivery/access to
warrant a CITIS. The typical data item usage should be the primary factor for determining
suitability for CITIS inclusion. Any data that is frequently accessed for viewing or processing is
an excellent candidate for inclusion in the CITIS, while data that is only archived and is seldom
accessed is not recommended for CITIS. Keep in mind that inclusion of data in the CITIS that is
rarely accessed will only increase the size of the CITIS database and reduce the speed of data
location and retrieval. In general, very large files (> approximately 30 Mbytes) are not typically
recommended for on-line delivery and access because current telecommunications technology
cannot yet efficiently handle large-volume data operations.

185

DATA TYPE

DATA
CATEGORY

DATA
CHARACTERISTICS

DELIVERY/
ACCESS MODE

Agendas, status,
reports, schedules,
minutes, general
communications

Frequent view &

update.

Programme
Plans

Limited reference
Contractual

CITIS on-line
access

Large volume.

Tape/Disk
delivery

CITIS on-line
access

Short life span.

Programme
Management Data

Product
Description Data

Drawings,
specifications, parts
lists, data lists,index
lists, and TDP
management data

Limited access for

design review.

ECPs analysis &

simulation data

Sort life span

Limited access

CITIS on-line
access

LSAR, LORA,
R&M, Provisioning,
Technical
Documentation

Frequent access,
Users approval

CITIS on-line
access

Provisioning file,
training data, LSA
plans, logistic plans

Large volume,
limited reference,
infrequent update

Operating, maintenance,
inspection & overhaul,
data, software source
code

Large volume

Logistic Support
Data

Technical
Publications

Tape/Disk
delivery

Figure 8-4 CITIS Implementation

8.2.4.2.4 Infrastructure Upgrades and Contractor Compatibility
As part of the data call and NCoO development process, each location requiring access to
program data will identify its computer hardware, software, and network infrastructure. Once
this information is gathered, it should be analyzed and compared to determine whether the
existing infrastructures are generally compatible or whether each location uses a substantially
different system. The greater the disparity in existing systems, the greater will be the cost for
infrastructure upgrades and CITIS development. If any locations are using old equipment (i.e.,
186

far out-of-date with current technology), these locations may require infrastructure upgrades to
be able to access the CITIS.
The ultimate decision on infrastructure upgrades will depend on the amount of funding available
and the program managers own judgment. If some locations have equipment inadequate to
accommodate a basic CITIS, they are probably inadequate for performing many other functions
that could be valuable to the program and should be upgraded regardless of whether a CITIS is
required. If it appears that the existing infrastructures are compatible and state-of-the-art, the
program manager can probably safely acquire a CITIS without having to worry about paying for
extensive NATO/NATO nations infrastructure upgrades.
In general, the contractor should be responsible for modifying its systems to be compatible with
the existing systems used by the NATO/NATO nations, rather than the NATO/NATO nations
modifying its systems. The only time the NATO/NATO nations should need to consider major
upgrades is in the case of outdated equipment. The contractor should propose a CITIS that will
work with the existing NATO/NATO nations infrastructure to the maximum extent possible and
discuss any upgrades that it feels are necessary either in the proposal or in the post-award
CALSIP and/or CITIS planning meetings. The contractor and the NATO/NATO nations should
work closely together to create a CITIS infrastructure that will be the most beneficial to everyone
who will use it.
8.2.4.2.5 Reviewer Locations
One of the main goals of CITIS is to facilitate the movement of data deliverables from one status
to the next, and the more widely dispersed the reviewer locations, the greater will be the benefits
from using a CITIS. When data reviewers are at widely separated locations, a substantial portion
of the review cycle time can be taken up by shipment of the data and review comments from one
location to another. When a CITIS is available, as soon as one reviewer has completed the
review and approved the data item for passage to the next reviewer, that next reviewer can
instantly access the data item and begin his review, regardless of his physical location. The
review cycle time is now simply the amount of time taken by the reviewers to actually review,
comment, and approve/disapprove the data item.
8.2.4.2.6 Data Currency
One of the many advantages of CITIS is improved accuracy and timeliness of data. After data
has been created or revised, it can be made almost instantly available to the NATO/NATO
nations reviewers and/or users who need it. Using current business processes, data items can
take days to travel from the contractor developing it to the NATO/NATO nations personnel who
need it. If rapid access to new data is important to the program, a CITIS may prove to be highly
beneficial.
8.2.4.2.7 Existing Electronic Communication Capabilities
If a program already has some form of electronic communication/data transfer capabilities in
place, either between the NATO/NATO nations and the contractor, or between NATO/NATO
nations activities, the cost and effort to implement a true CITIS may be substantially reduced.

187

Even if a program does not meet some of the other criteria listed above, if it already has basic
electronic data transfer capability with its contractor, a CITIS may be relatively easy and
inexpensive to implement, and could still save a substantial amount of money over the remaining
life of the program.
8.2.4.2.8 Data Revision Frequency
If the CDRL includes a substantial amount of living data that will often be updated, a CITIS
can prove highly beneficial in ensuring the accuracy and consistency of the data used by all of
the CITIS locations. Because all locations have access to the same master data file, the
likelihood of data users possessing outdated or incorrect information is substantially reduced.
The "archive" function of CITIS assumes added importance if a deferred delivery option will
apply to the contract.
8.2.4.2.9 Program Considerations
CITIS becomes more cost effective and beneficial when applied to programs that have
substantial data requirements, are in an early phase of development, and/or have long-term data
requirements. However, CITIS should not be ruled out just because a program does not meet
any of the above criteria; all of the questions shown in table 5-1 should be answered before a
decision regarding CITIS is made. The program manager should evaluate and implement
process improvements wherever economic benefits can be achieved.
8.2.4.2.10 CITIS Functional Requirements Determination
After the questions in Table 8-5 have been answered and a CITIS has been determined to be
beneficial to the program, the program manager should review the NCoO questionnaire
responses to determine which CITIS functions apply to his program.
Program managers should bear in mind that the greater the number of CITIS functions and
services required, the greater the potential cost of CITIS development and implementation. After
determining program-specific CITIS requirements, the program manager should weigh the
estimated cost of the service against available funds and potential benefits. If the estimated cost
of the CITIS services selected exceeds existing budgetary estimates, the program manager
should tailor the CITIS requirements and functions as necessary.
8.2.4.3 CITIS Functionality
The CITIS functionality can range from basic data interchange functions to extensive interactive
capabilities. The program/project manager must specify which, if any, of the CITIS tailorable
functions are desired in the SOW, CDRL and acquisition contract.
8.2.4.3.1 CITIS Services and Functions
Table 8-6 provides supplemental details on CITIS services and functions. Information provided
includes potential problems, lessons learned, and other issues to consider when determining the
CITIS requirements for the SOW, CDRL.

188

Table 8-6 CITIS Services and Functions - Supplemental Details

Service/Function
CITIS Services:

CITIS
Management
Information Services:
Availability and Accessibility

Users Furnished
Information (UFI)

Multi-user Access

Considerations
Services typically required with CITIS

SOW requires advance notice of events affecting

CITIS operation.
SOW specifies hours of operation.
SOW can specify amount of notice required (hours,
etc.) prior to each event.
SOW and NCoO should specify size, format, and
content of UFI - advance notice of format and
software tools used to create UFI are extremely
important.
SOW should specify which functions are required for
UFI.
SOW specifies the number of concurrent CITIS
users.
The greater the number of users, the slower will be
the CITIS performance (speed). SOW can specify
the acceptable level of degradation.

Electronic Mail

SOW can specify the number of users and the

applicable protocols.

Data Dictionary

Intent of this requirement is to ensure that users can

consistently and easily locate data of interest

Interface Compatibility

May require extensive planning and can be difficult

to satisfy because of the potentially large range of
NATO/NATO nations users receiving systems.
NATO/NATO nations may want to specify/select a
limited number of receiving systems to reduce
complexity of CITIS.

Communication Protocols

NATO/NATO nations are responsible for obtaining

any waivers needed for use of a non-standard
protocol.

189

Service/Function
Training Support

Telephone Support

On-line Help
Data Configuration
Management

CITIS Security

Access Controls
Contamination Control

Data Item Index

Data Exchange Standards

Core Functions:

Acknowledge

Approve or Disapprove
Comment

Considerations
SOW specifies form(s) of training: documentation,
contractor visits to CITIS user sites, number of
training sessions, etc.
SOW can specify frequency of CITIS training/
documentation updates (e.g., after major system
changes, every six months, etc.)
SOW specifies hours of telephone support (may be
different from CITIS hours of operation).
Telephone support most advantageous for large and
varied groups of CITIS users.
CITIS users will not be able to replace contractor or
UFI data.
SOW specifies user data access privileges (i.e.,
access to working data - neither contractor nor
NATO/NATO nations - is not granted unless
specified in the SOW).
Contractor should obtain written approval from
cognizant security officer before including classified
data in CITIS.
SOW can address protection of business sensitive or
proprietary data by both contractor and the
NATO/NATO nations.
Primary contamination control typically provided by
allowing only authorized users to access CITIS data
SOW can require the contractor to scan all CITIS
data for viruses prior to incorporation or can specify
intervals at which all CITIS databases are scanned
SOW specifies any indexing elements
Include any COTS software formats when specifying
data transfer methods.
Core functions automatically required with CITIS
Core function tailoring should only be done after
rigorous cost and effectiveness analyzes.
Can be provided via either E-Mail or CITIS
capabilities.
Can be manually input, automatic confirmation by
receiving computer, etc.
Can be provided via E-Mail or CITIS capabilities.
NATO/NATO nations may consider allowing use of
E-Mail for this function.

190

Service/Function
Notice of Delivery
Receive
Search

Store

View

Tailorable Functions:
Applications

Archive

Combine

Download

Edit

Considerations
Can be provided via E-Mail or CITIS capabilities.
SOW specifies any additional elements desired as
search criteria (will be included in the data item
index).
SOW should specify the length of time a data item
will be stored/available through CITIS.
Function allows users to request that short-term data
be retained on CITIS past its normal lifetime.

SOW specifies required tailorable functions.

Can cause licensing problems.
NATO/NATO nations should identify and grant
access to applications only to specific personnel (not
everyone); number of personnel requiring access
should be specified in SOW, if known
SOW can specify length of time between archival
data request and availability of data on CITIS.
SOW can specify whether data requester should be
notified of data availability.
SOW can require creation of an archival data index.
NATO/NATO nations should periodically review
CITIS data to identify data to be archived (this
should improve CITIS performance).
Can cause data CM problems - SOW should specify
disposition of combined data (how long to retain it,
how to tag and index it, how to notify CITIS
administrators, etc.).
CITIS must ensure that combination of data does not
affect original data files.
SOW can specify maximum file size for data
downloads to avoid telecommunications/networkloading problems.
Files larger than approx. 30 MB are recommended
for delivery via magnetic media.
Max.
Download file size specification may be
especially important if many CITIS user sites
possess only limited CITIS access capability.
If maximum size is specified, SOW should specify
how CITIS users can gain access to large data files
(e.g., on-line request for data on tape).
Can cause data CM problems - requires same
considerations as for the Combine function.
191

Service/Function
Forward

Package

Query
Sort
User Groups

Considerations
SOW should specify whether data will be forwarded
to other CITIS users, non-CITIS users, or both
Function is useful for facilitating the review and
approval/ disapproval of data items.
SOW must define this function - specifically:
How should the package be stored, tagged, and
indexed?
Is the package temporary or permanent?
Is it accessible by all authorized CITIS users, and
how can they be authorized?
Must the other CITIS functions be able to act on the
package?

SOW should specify frequency and location of user

group meetings.
SOW should specify disposition of information
generated during the meetings.
SOW should specify who is responsible for taking
minutes and tracking action items.
User groups most beneficial with large numbers of
varied CITIS users.

8.2.4.3.2 Printing Capabilities

The ability of the CITIS to print file contents should be considered by the NATO/NATO nations
and the contractor. Although the goal of CITIS and CALS in general is to migrate from
paper-based information to digital formats, real-world practices indicate that paper is still a
popular medium for information distribution. The program manager should determine whether
CITIS users would be allowed to print portions of CITIS data without having to download the
entire file to their computer. If this service is desired, the program manager needs to require the
contractor to incorporate a printing capability into CITIS.
The NATO/NATO nations also needs to specify the desired print options such as printing out a
specific range of pages or portion of a document in addition to printing the entire document. It is
very important that the NATO/NATO nations include printing capability requirements in the
contract so they can be appropriately priced, because the cost and effort to implement these
capabilities may be significant.
Printer compatibility issues cause problems for many
information management programs because current technology can be restrictive in terms of
what types of files will print out correctly on various types of printers (e.g., non-Encapsulated
PostScript files do not print well on PostScript printers).

192

8.2.4.4 Contracting for CITIS

A key element in the contracting process for CITIS and CALS in general is the development of
the NATO/NATO nations Concept of Operations (NCoO). This NCoO is provided as User
Furnished Information (UFI) with the Request For Proposal (RFP).
8.2.4.4.1 NATO/NATO Nations Concept of Operations
A well-developed NCoO is an extremely important part of the acquisition process. The NCoO
benefits both the NATO/NATO nations agency preparing it and the contractors using it to
respond to an RFP. Development of the NCoO will help ensure that the NATO/NATO nations
can access or receive the correct version and formats of digital data products needed to acquire
and support a specific program. The NCoO includes ni formation on the data types to be digitally
accessed/delivered, who will use the data and where they are geographically located, how the
data will be used (e.g., view, comment, etc.), the data users infrastructure (hardware, software,
networks), the type of digital data deliverables (processable or not), the data formats, relevant
data interchange standards, and mechanisms/media for data delivery/access. An unexpected
benefit to the NCoO process is that analysis of the NCoO information can result in identification
of areas for internal improvements, such as elimination of data that is no longer needed, or
upgrades for outdated software or equipment. A detailed discussion of the NCoO development
process can be found in section 1 of this handbook.
The NCoO should be part of the RFP package because it often contains more detailed
information than is contained in the SOW and RFP. Such details as data user locations and
specific NATO/NATO nations hardware, software, and networks are extremely important to the
contractor when preparing the CITIS portion of its proposal. Inclusion of the NCoO also
encourages early interactive planning between the NATO/NATO nations and the contractor.
In its response to the RFP (in the CAC if one is required), the contractor should specify any
CITIS requirements that it believes are important in defining the CITIS but were not included in
the NCoO or SOW. The RFP response should contain a CITIS development plan that shows the
order in which the various services and functions will be implemented along with a proposed
schedule for their availability.
The contractor has the opportunity, through the CAC, to propose any alternative processes,
procedures, or systems that may be more efficient or cost-effective than those set forth by the
NATO/NATO nations in the NCoO and SOW. Any limitations in the CITIS system that will
affect a NATO/NATO nations requirement should be specified as well (e.g., UFI file size limits).
Any additional responsibilities identified by the contractor and not specifically addressed in the
NCoO or SOW, such as hardware, software, and/or network installations, should also be
included in the proposal.
8.2.4.4.2 Solicitation
The solicitation defines the scope of work, schedule, conditions, clauses, instructions, evaluation
criteria, and deliverables to be provided.
The CALS RFP elements should address the

193

requirements for electronic (on-line/CITIS) services, digital data delivery, and functional
integration.
8.2.4.4.3 CITIS Contract Line Item Number
Use of a CITIS Contract Line Item Number (CLIN) provides a standard methodology for
acquiring CITIS-type services and will simplify the evaluation of CITIS portion of the RFP
responses because all offerors responding to the RFP will have their cost for developing a CITIS
clearly priced. When pricing elements are subdivided, the evaluation team will be able to verify
that the contractor has included pricing to cover all aspects of the CITIS specified within the
SOW. The individual pricing elements will also provide a consistent method for later auditing of
the CITIS costs. If desired, the tailorable CITIS functions may be priced as alternative or
optional CLIN(s) to allow cost/benefit assessment.
When subdivision of CITIS pricing elements is required, typical costing areas can include system
development and installation, equipment lease, access/connect times, equipment purchase,
telecommunications, data storage, data delivery, infrastructure upgrades, data conversion,
software licenses, system maintenance, and security. The system development task includes
software development and hardware/software/ network integration, which typically requires the
greatest effort, and thus the greatest cost. The access/connect time cost includes the cost for the
contractor to connect with the NATO/NATO nations computer systems; it could also include
the connection charges for NATO/NATO nations to utilize a hotline to access CITIS, if one has
been required.
The telecommunications costs could include the cost to install and maintain dedicated modem
lines, high-speed optical lines, or a hotline number. The data storage costs could include any
service center-type costs associated with storage of large amounts of digital data (e.g., costs for
data administration, backups, and maintenance). The cost of data delivery is essentially an
application of the standard connection cost-per-minute to an estimate of the amount of data
projected to be delivered via CITIS. The infrastructure upgrade pricing element could include
the cost of any hardware and software upgrades, network (LAN and/or WAN) purchase and
installation, and costs for the purchase of data storage devices (e.g., very large hard drives,
optical drives, CD ROM jukeboxes, etc.) that will be needed to store all the CITIS data.
Software license costs can include purchase of individual and/or site licenses. Security costs
could include the costs of any special measures required for the CITIS to handle classified data.
Cost to develop the data to be included in CITIS (excluding data conversions) is not included in
the CITIS line item.
8.2.4.4.4 Sample CITIS Statement of Work
The following sections contain the language that could appear in a SOW for development of a
CITIS. Text appearing as [times new roman] is provided as the language that would be used in
the actual SOW. Text appearing as [small caps] within the actual SOW text indicates
information input by program managers relevant to their programs. Text appearing as [times
roman] at the end of each paragraph is provided as supplemental information that would not be
used in the actual SOW.

194

8.2.4.4.4.1 Scope
The contractor shall establish a digital technical information system to provide automation and
integration of the generation, delivery, and uses of [ XXX PROGRAM] technical information.
Unless otherwise specified within the contract, all, or any portion of, the technical information
specified herein shall be developed and delivered in a digital form compatible with requirements
stated herein. Unless specifically stated herein, the following requirements do not replace or
amend requirements for delivery of technical information in non-digital forms specified
elsewhere in the contract.
8.2.4.4.4.2 Applicable Documents
[List all documents that apply.]
8.2.4.4.4.3 Spe cific Requirements
The contractor shall provide a Contractor Integrated Technical Information Service (CITIS) in
accordance with the specific requirements as identified herein. The contractor will deliver in
place all data associated with this procurement and identified within this SOW and the attached
CDRL, unless otherwise noted. This data shall be maintained in an electronic form, and made
available to authorized NATO/NATO nations users and reviewers, and their assigned
representatives, in accordance with the requirements described below.
8.2.4.4.4.4 CALSIP
The contractor shall prepare a CALSIP that describes the ways in which CALS techniques are to
be applied throughout the life of the contract to satisfy requirements for service, infrastructure,
media, and format. The CALSIP shall be a living document to explore CITIS opportunities and
technology as contractor-NATO/NATO nations infrastructure evolve over time. The CALSIP
shall be updated every [365 DAYS ] throughout the life of the contract. The CALSIP updates shall
define implementation plans for the upcoming period in greater detail, resolve outstanding
strategy issues, respond to strategic and technology changes, and recommend specific
alternative approaches for continuation of CALS and CITIS in the next period. CALSIP
contents, as a minimum, shall include:

CALS support hardware and software architecture, reference documents, points of

contact
Contractors approach and experience in creation, management, use, and exchange of
digital information
Contractors capabilities for integrating applications and databases
Procedures to improve product quality and eliminate data redundancy
Proposed CITIS on-line access capabilities
Information system and relationships with NATO/NATO nations receiving systems
Outline of proposed actions and capabilities to be pursued in subsequent life-cycle
phases
Telecommunications data protection and integrity, including system security

195

[The program manager is not required to contract for a CALSIP, but it is highly recommended.
The CALSIP is the only standard way we have of gaining the data required by the instructions
for ensuring the requirements have been met. In todays acquisition world, the attitude is: if it is
not considered a requirement, it will not be done.]
8.2.4.4.4.5 CITIS Site Implementation Priorities
CITIS shall be made available to [ALL] locations listed in the NCoO. [ ..... ], shall serve as the
primary installation and testing site. After acceptance of each version of the CITIS software at
the primary site, [ ALL] other sites shall be allowed access to the current CITIS version.
[If CITIS will not be provided to all locations listed in the NCoO, the exceptions or inclusions
should be specified here (whichever list is shorter). A copy of the table of locations from the
NCoO may be included here, if desired. Selection of a primary installation site is not required,
but is highly recommended. If an NCoO is not being provided with the RFP, a table of
NATO/NATO nations locations is needed here.]
8.2.4.4.4.6 CITIS Period of Performance
The [ XXX PROGRAM] CITIS period of performance shall begin on [1 JANUARY 1996] and continue
until [1 JANUARY 2001] at [ ...... ]. CITIS service shall be available to [ ALL] other locations on
[1 FEBRUARY 1996] or after CITIS acceptance at the primary site, whichever is later, and
continue until [1 JANUARY 2001].
[The CITIS period of performance specifies the date when the CITIS is to be made initially
available to the NATO/NATO nations; it is assumed that the CITIS development phase will
begin immediately after contract award and the basic CITIS will be installed and functional by
the beginning period of performance date. The period of performance may be specified to be the
same for all locations, or it may be different for each location.]
8.2.4.4.4.7 CITIS Installation
Any peculiar software that must be resident on NATO/NATO nations access terminals or
computers will be provided and maintained by the contractor. It will also be installed by the
contractor if complexity of the software warrants/requires special installation and testing
procedures.
8.2.4.4.4.8 CITIS Data Residency and Storage
Data shall be available through CITIS for a period of [ONE YEAR] after its creation or revision
unless otherwise requested by the NATO/NATO nations. Exceptions include short-lived data
such as meeting agenda, meeting minutes, trip reports, status reports, etc., which will be stored
on CITIS for a period of [ 60 DAYS ] after creation or revision. All data shall be archived after
its CITIS storage time has expired, unless it has been specified for either deletion or further
retention on the CITIS by the NATO/NATO nations.

196

[If desired, the NATO/NATO nations may break down the CITIS data availability further by
specifying the residency period for each type of data (e.g., engineering drawings shall be
available via CITIS throughout the life of the contract). If the archive function is not being
required, the program manager must specify the disposition of the data after its CITIS storage
time is expired. Note that specification of a storage period is not required; the program manager
may specify that all data is stored on CITIS throughout the life of the contract.]
8.2.4.4.4.9 Data Classification
The CITIS shall be required to handle [ UNCLASSIFIED] data only.
[Specify each level of classification that the CITIS will be required to handle]
8.2.4.4.4.10 Functions and Services
The contractor shall develop a CITIS that incorporates all CITIS services and core functions and
the additional requirements specified below. The CITIS shall also include the following
tailorable functions: [ ARCHIVE, DOWNLOAD, SORT, AND USER GROUPS].
8.2.4.4.4.11 Availability and Accessibility
The CITIS shall provide [24-HOUR] on-line service [EVERY] day of the week. Users shall be
notified [24] hours in advance of any scheduled maintenance or other events affecting CITIS
accessibility.
[For the standard, unclassified CITIS, 24-hour on-line service is a reasonable requirement.
When classified data is contained on the CITIS, the NATO/NATO nations will probably need to
specify the hours and days for which the classified data should be available. Sample language
could be: CITIS shall provide 24-hour on-line service every day of the week for unclassified
data. Classified data shall be available between the hours of 7:00 a.m. and 7:00 p.m., on normal
working days only (no weekends or holidays).]
8.2.4.4.4.12 User Furnished Information
The contractor shall provide data users with access to UFI via the CITIS. The NATO/NATO
nations shall provide approximately [25] data items that will include [TECHNICAL MANUALS ,
TECHNICAL REPORTS , AND ENGINEERING DRAWINGS ]. All UFI will be provided in [DIGITAL]
formats. The technical manuals and reports will be provided in [ RASTER FORMAT AND STANDARD
WORD-PROCESSING FORMATS ], and the engineering drawings will be provided in [STANDARD CAD
FORMATS ]. The maximum file size for any data item is [ 5 MB]. UFI shall be included in the data
item index, and CITIS users shall be able to, as a minimum, [ SEARCH FOR, VIEW, AND DOWNLOAD]
all UFI.
[Specify the approximate number, type, and formats of User Furnished Information (UFI) to the
extent possible. If the specific software applications used to create the data are known, they can
be listed here. Specify the CITIS functions required for the UFI (not all are appropriate). ]

197

8.2.4.4.4.13 Multi-user Access

The CITIS shall provide simultaneous access to [10] users.
8.2.4.4.4.14 Interface Compatibility
The CITIS shall be compatible with [all systems (hardware and operating systems)] listed in the
NCoO. [compatibility with every software application is not required.]
[If the systems listed in the NCoO cover a wide range of hardware and operating systems, the
NATO/NATO nations may choose to require compatibility with only the most prevalent of the
systems in order to reduce the cost of CITIS development. The contractor should develop the
CITIS to be compatible with the predominant software used by the NATO/NATO nations, but
not necessarily every software application (especially if the NATO/NATO nations is using older
applications). ]
8.2.4.4.4.15 Communication Protocols
Communication of data between sites via CITIS shall utilize the [ TRANSMISSION CONTROL
PROTOCOL/INTERNET PROTOCOL (TCP/IP)] and shall be in accordance with [...].
8.2.4.4.4.16 Training Support
The contractor shall provide CITIS training through development of a [CITIS USERS MANUAL]
that shall instruct users on how to gain access to CITIS, how to locate data, and how to utilize
the various CITIS functions. [THE CONTRACTOR SHALL TRAVEL TO THE PRIMARY CITIS SITE TO
PROVIDE HANDS -ON TRAINING AFTER INSTALLATION OF THE COMPLETED CITIS .] [ALL OTHER CITIS
LOCATIONS] will receive the CITIS USERS MANUAL and will have access to contractor
telephone support for assistance with CITIS installation, access, and usage. The contractor shall
update the USERS MANUAL [AFTER EACH MAJOR SYSTEM CHANGE], and minor changes can be
accumulated and a revised document generated when they impact operation significantly.
[If contractor travel to CITIS user sites for training is desired, specify each or all of the sites to be
visited. If there are a large number of CITIS locations, the NATO/NATO nations may also want
to require the contractor to develop a CITIS Operators Manual that will provide detailed
information on CITIS installation, trouble-shooting, and access.]
8.2.4.4.4.17 Telephone Support
The contractor shall provide telephone support between the hours of [7:00 A.M. AND 6:00 P.M.].
8.2.4.4.4.18 Data Configuration Management
[The contractor shall devise a standard file naming scheme that shall be employed by all
organizations contributing data to the CITIS. This scheme shall allow the CITIS user to rapidly
identify desired files. All file names shall comply with the maximum name length allowed by the
most restrictive operating system used at a CITIS location. If dos is one of the primary operating

198

systems used by the NATO/NATO nations, all file names will comply with the 8.3 (8 character
name plus 3 character file extension) naming convention.]
[All requirements listed above are optional.]
8.2.4.4.4.19 Security
The contractor shall establish a security system and enforce data protection and integrity
standards. System security engineering principles as outlined in [ ... ] shall be used. Controls
to prevent unauthorized access shall be established and detailed in the System Design Document.
The plan shall be based on the results of documented data protection and integrity, threat and
vulnerability analysis, risk assessments, and tradeoff analyzes. Vulnerabilities that remain after
security system design shall be identified. The plan shall include disaster recovery provisions.
Security requirements that must be complied with by NATO/NATO nations personnel will be
identified to the NATO/NATO nations in the security section of the System Design Document.
[If higher data classifications will be required, include information regarding any special security
provisions .]
8.2.4.4.4.20 Core Functions
The core functions shall be implemented in accordance with [ ... ]. [the acknowledge function
shall be satisfied through automatic confirmation of data transfer by the receiving computer.]
8.2.4.4.4.21 Tailorable Functions
The tailorable functions [ARCHIVE, DOWNLOAD, SORT, AND USER GROUPS] shall be implemented in
accordance with [ ... ] and the additional requirements described below.
8.2.4.4.4.22 Archive
[The contractor shall create and maintain an archive of data whose CITIS storage time has
expired. The contractor shall determine the method/media for this archive. The contractor shall
track and index all archived data, and shall provide access to this data upon request. The
contractor shall provide an on-line capability for users to request that archived data be made
available through the CITIS. All requests for archived data shall be acknowledged and an
approximate time frame for availability provided. Requested data should be made available
through CITIS within 24 hours during the normal work week. An electronic message shall be
sent to the data requester when the data becomes available on the CITIS. If the requested data
file is found to be larger than 30 MB in size, it will not be made available on the CITIS, and the
requester will be notified and queried regarding the preferred physical media for data delivery.]
[All requirements listed above are optional.]

199

8.2.4.4.4.23 Download
[The maximum file size that shall be downloaded is 30 MB in order to reduce potential
telecommunications problems. The contractor shall provide on-line capability for users to
request physical delivery of data files too large to download. Users shall be provided with a list
of possible media from which they may select the preferred delivery method.]
[All requirements listed above are optional.]
8.2.4.4.4.24 User Groups
[CITIS user groups shall be conducted on a quarterly basis, and meetings shall alternate
between the contractors and the NATO/NATO nations primary site. Advance notice of
meetings shall be distributed through the CITIS E-Mail system. The contractor shall be
responsible for preparing meeting agendas and minutes. Meeting minutes shall include a list of
action items and their dispositions, and shall be made available through the CITIS to all CITIS
users.]
[All requirements listed above are optional.]
8.2.4.4.4.25 Printing Capabilities
The CITIS shall include the capability for users to print information locally and shall allow users
to specify a [SINGLE PAGE, A RANGE OF PAGES, OR THE FULL DOCUMENT] for printing. This
capability shall be independent of the printer being used.
[Specify the document printing options desired.]
8.2.4.4.4.26 Licensing
The contractor shall be responsible for obtaining any licenses required for CITIS users to access
the commercial-off-the-shelf (COTS) software applications used to perform the CITIS functions.
The NATO/NATO nations will assist the contractor in obtaining permission to include any
applications developed by other contractors and/or owned by the NATO/NATO nations in the
CITIS.
8.2.4.4.4.27 Subcontractor Data
The contractor shall provide access to appropriate subcontractor data via the CITIS. The
contractor shall determine the method by which the subcontractor shall provide this data and the
manner in which it is incorporated into the CITIS.
[The contractor will determine whether the subcontractors shall be linked to the CITIS network
or whether they will simply provide their data in digital formats, and the prime contractor will
then load it into CITIS.]

200

8.2.4.4.4.28 Program Data Repository

The contractor shall propose an [ XXX PROGRAM ] working data repository scheme in the System
Design Document. Direct access to all contractor and subcontractor databases is the preferred
method, but it is not required.
[The program manager should not typically specify the data repository scheme because the
contractor will need to assess the compatibility of the suppliers and subcontractors
infrastructures with the proposed CITIS before deciding whether to incorporate them into the
CITIS network. NATO/NATO nations specification of a data repository scheme without prior
knowledge of the infrastructures involved could result in substantial unnecessary costs and
effort.]
8.2.4.4.4.29 Equipment and Telecommunications
The NATO/NATO nations shall utilize its own hardware, software, and networks to access the
CITIS. The NATO/NATO nations shall be responsible for installation and maintenance of any
dedicated modem and/or high-speed optical lines, if needed, at NATO/NATO nations CITIS user
facilities. The contractor shall provide a hotline number accessible by a maximum of 10
concurrent users. This hotline shall be available during the hours specified in this SOW.
[The program manager should specify who will provide CITIS equipment (e.g., computer
terminals, modems, etc.) and telecommunications (e.g., dedicated modem or high-speed optical
lines). Either the contractor or the NATO/NATO nations or both may be responsible for
providing this equipment/service.]
8.2.4.4.4.30 CITIS Acceptance and Testing
CITIS acceptance includes acceptance of the service and CITIS CLIN, assurances of adequate
acceptance testing, and electronic data transfer service acceptance. Acceptance of the service
and the CITIS CLIN, if utilized, is a verification that the contractor has provided the service as
specified. Provision of the CITIS functional requirements specified in the SOW will be verified,
including such capabilities as core and tailorable CITIS functions, service availability, and
maintenance response. Assurances of adequate acceptance testing for CITIS shall be obtained
via contractor demonstration of the service. The test shall include demonstration of functional
capabilities and verification that the CITIS will handle representative data required to be
formally delivered through CITIS without alteration of the data product. Such a test is not
required for each delivery, but shall be rerun if major maintenance or modifications have been
performed or the sending or receiving systems have been changed enough to warrant additional
tests. If specific test data is deemed necessary for adequate testing of a CITIS, that test data
shall be provided and results reviewed at the primary CITIS site. On-line access service shall be
accepted when it is demonstrated that a person with proper authorization can utilize the
contractually required core and tailorable CITIS functions from a terminal or workstation at the
primary site or as otherwise agreed. Electronic data transfer service acceptance shall occur
when a single instance of transfer of the specific deliverable type can be achieved, including
successful download and retrieval of data into the NATO/NATO nations system. This data may
be real product data or test data, as appropriate.

201

8.2.4.4.4.31 Final Disposition of Data

Upon completion of the initial CITIS contract, the NATO/NATO nations will decide whether the
contractor, the NATO/NATO nations, or a third-party contractor will continue maintenance of
the CITIS.
[If the final disposition of the data is known, it should be specified here. The program manager
will typically want to wait for the CITIS to be developed and its usefulness determined before
deciding who, if anyone, should maintain it after the initial contract is completed.]
8.2.4.4.5 Deliverables
Some of the possible deliverables for the CITIS development task include:

CALSIP
System Design Document
Program Management Plan
Configuration Management Plan
Users Manual
Operators Manual
System Test Description and/or System Test Plan.

The System Design Document should include complete details of the specific hardware,
software, and network configurations used/planned for CITIS, along with a detailed description
of the CITIS security features. If desired, this document can also contain a data element
dictionary that lists field names and descriptions of all data elements in the CITIS database(s).
The key element of the Program Management Plan is a detailed schedule that includes the
implementation of the various CITIS services and functions and estimated preliminary
installation and test dates for the primary site. The System Test Description should include the
types of tests to be conducted, the test procedures, the test schedule, and the locations of the
tests.
8.2.4.5 CITIS Development
The primary requirement for creating a successful CITIS is preliminary planning. The contractor
and the NATO/NATO nations must discuss and agree upon a large number of issues before the
CITIS development is begun. Both sides must understand exactly which functions are required
and how the NATO/NATO nations intend to utilize them.
They must discuss the hardware, software, and networks that will be used, how the CITIS should
handle data in different formats, and how the contractor should handle major changes in the
NATO/NATO nations computer infrastructure. The contractor also needs to decide, with the
help of the NATO/NATO nations, how and to what extent to include supplier/subcontractor data
and what type of data repository method makes the most sense for the program.

202

Creation of a successful CITIS requires continuous communication between the CITIS

developers and the CITIS users. Otherwise, the developers may create a system that satisfies the
requirements, but does not meet the users actual needs. This is especially a problem if the
requirements are not well defined in the contract.
8.2.4.5.1 CITIS Strategy
During the planning phase of the CITIS development process, contractors must determine their
strategy in terms of the location/distribution of the program-specific data repository, the extent to
which their suppliers/subcontractors will be included in the CITIS, and CITIS data availability.
8.2.4.5.1.1 CITIS Program-Specific Working Data Repositories
A major decision that must be made early in the planning process is where the data will reside.
This decision does not have to be made prior to solicitation release. If the NATO/NATO nations
has already decided on the form of its program-specific data repository, it should be specified in
the SOW, but if not, the contractor should propose a solution after contract award in the CALSIP
and/or the System Design Document. The main options for program-specific data repository
strategies include:
Option 1: database repository resides with the prime contractor as a single physical
integrated database.
It is the simplest option to implement, with all data residing in a single database at a single
location. However, this option could result in extensive duplication of data, since data is copied
from wherever it originated and loaded into the database. Another potential drawback to this
method is reduced accuracy-timeliness of data, since physical copies of updated information
must be sent to and loaded into the main database.
Option 2: database repository resides with the prime in the form of distributed multiple
databases with a navigator.
It allows for distributed databases within the prime contractor that are accessed via a navigation system.
With this option, each functional area (e.g., logistics, engineering, technical publications, etc.) maintains
its own database and data, which is accessible by the CITIS users through the central navigator. There is
no single physical database with option 2. This option is an improvement over the first option because it
significantly reduces the amount of redundant data within the databases. It also improves data accuracy
through the timeliness of incorporation of data updates into the database. The navigator system will
simply be a pointer to the location where each particular piece of data is stored. Supplier/subcontractor
data, if desired, is provided by the supplier and loaded into the CITIS (no direct access to supplier
databases).

Option 3: database repository resides with the prime; existing information systems are
interfaced to extract CITIS data in a central repository.
It involves a program-specific data repository that resides with the prime contractor and is made up of
multiple databases. This option differs from option 2 in that even though the databases are distributed,
they contain duplicate information that allows data to be easily linked together (i.e., a relational database

203

management system). The central data repository typically contains basic information about each
functional area, program, or type of data that is used to interface with more extensive databases
containing related information. This method can also be easily used to identify, for example,
parts/equipment used on more than one system. Another benefit to data linking is that when information
is changed in one location, the CITIS system can be designed to reflect that change in any other
databases containing that same data. Supplier/subcontractor data, if desired, is provided by the supplier
and loaded into the CITIS (no direct access to supplier databases).

Option 4: database repository resides with the prime and suppliers (many), with a navigator
(gateway processor) to pass requests/access to supplier databases.
Option 4 is the most extensive of all four options, because it allows direct access not only to contractor
databases, but to supplier and subcontractor databases as well. This option is typically the most difficult
to implement, since CITIS could be required to interface with a potentially large number of different
systems. This option would require suppliers to be responsible for their own data, thus improving the
accuracy of the data available to the CITIS users. One of the drawbacks to the all-encompassing CITIS is
the problem of proprietary data rights and privileges. Another potentially major drawback to this type of
CITIS network is the possibility of suppliers/subcontractors utilizing their own data management/storage
systems that are not compatible with anyone elses. Using current technology, the cost and effort to set
up a CITIS system that can interface with all the different data management systems could be prohibitive.
Before making a decision on whether to provide CITIS access to supplier/subcontractor databases
directly, the contractor should identify the hardware and software used by each candidate system to
determine the complexity, and thus feasibility, of incorporating it into the CITIS network.

8.2.4.5.1.2 CITIS and Suppliers/Subcontractors

If supplier/subcontractor data is included in the CITIS, the contractor must develop a supplier
data input strategy. This input method should be based on the extent and complexity of the
CITIS. The four methods for incorporation of subcontractor data into the CITIS include:

Method 1: subcontractor delivers data on paper - prime scans it in and adds it to CITIS in
raster format.
Method 2: subcontractor delivers data via physical media in digital format - prime loads it
into CITIS.
Method 3: subcontractor downloads its data directly into CITIS databases.
Method 4: subcontractor becomes member of CITIS network and users have access to all
of its data.

Method 1 is almost never recommended because of the cost and effort required to scan in the
data. In addition, the resultant raster data is in a non-processable format, which will significantly
reduce the usefulness of the subcontractor-supplied data.
Methods 2 and 3 are both reasonable options when a relatively basic (lower cost) CITIS is
desired, because they allow for reasonably simple incorporation of data into the CITIS databases.
Digital delivery of subcontractor data to the prime contractor for download into CITIS would
eliminate the need to interface with a potentially large number of different subcontractors
information management systems.
If, however, a robust CITIS is planned,

204

suppliers/subcontractors should be a part of the CITIS network, and their data should reside
in-house.
Method 4 should provide the greatest subcontractor data accuracy and timeliness, but these
benefits may be outweighed by the typically higher cost and effort to implement the robust
CITIS. In general, methods 2 and 3 should be the simplest, least costly methods to implement
for incorporation of subcontractor data into the CITIS.
8.2.4.5.1.3 Data Availability Factors
For most defense programs, a large volume of technical data will be created by the contractor in
support of the program. Before this data can be released for access through the CITIS, it must
meet the programmatic requirements and pass the contractual restrictions. Only that data that
meets all the requirements and restrictions should be made available through the CITIS.
8.2.4.5.1.4 Acceptance of Data Delivered via CITIS
The contract must address the questions of what constitutes data delivery, and who in the
NATO/NATO nations will receive, inspect, and accept the data. The NATO/NATO nations will
specify in the contract the delivery methods for each CDRL item, and if delivery includes CITIS,
this delivery may be in the form of either in-place delivery, in which the data item is considered
delivered once it becomes available on the CITIS, or it may be in the form of a physical data
download by the NATO/NATO nations from the CITIS.
The NATO/NATO nations contracting officer should decide, and the decision should be
specified in the contract, whether the data inspection and acceptance can be performed
electronically (e.g., some form of electronic signature or other means of indicating approval or
disapproval), or whether it should be done in a traditional method. If an organization will serve
as the approving official responsible for taking receipt of the data and then coordinating the
inspection and acceptance, that organization should be identified in the SOW.
8.2.4.5.2 Hardware, Software, and Networks
The selection of hardware and software used to create the CITIS is critical and must be
thoroughly analyzed before any attempt to develop CITIS is begun. The CITIS configuration
should be determined only after analysis and comparison of the NATO/NATO nations,
contractors, and subcontractors (if included in CITIS) infrastructures.
Some important
considerations include compatibility of operating systems, file formats, and hardware and
telecommunications options. The CITIS designer should also consider future impacts to the
CITIS system should NATO/NATO nations users upgrade their hardware or software.
8.2.4.5.2.1 Operating System Considerations
One of the basic problems between different operating systems (e.g., DOS vs. UNIX) is the
allowable length of file names. DOS is restricted to the 8.3 (8 character name plus 3 characters
for the file extension) file naming convention, while UNIX allows much larger file names.

205

Because of this problem, close attention should be paid to indexing and file management
schemes.
8.2.4.5.2.2 File Format Considerations
Before any CITIS development is performed, the contractor must determine how CITIS will
handle data in different formats. A matrix should be developed during the CITIS planning stage
showing which software tools will be used and how the NATO/NATO nations and contractor
data will be stored and displayed. An ideal CITIS would be able to display and process data in
any format, regardless of the software tool used to develop it. However, this ideal CITIS may be
economically prohibitive and technologically challenging. In practice, the two primary options
for data handling are:

All CITIS data is translated from native formats into a single agreed-upon format;
CITIS is used to launch multiple applications to display the data in various native
formats.

The primary drawback to the first option is that the system operators may be required to
reprocess data that has already been created. This translation process introduces the potential to
lose data and/or format information. If the data has been created with a wide variety of
applications, conversion to a single format is a serious weakness that may have a significant
economic impact. Composite documents (which may include text, graphics, databases, and/or
spreadsheets) are especially difficult to convert into a single format because some software
packages may not reproduce the information accurately, and in some cases, not at all.
The drawbacks to the second option include greater complexity of the CITIS system and the
necessity for CITIS users to be trained on and become familiar with a variety of viewing/editing
tools. The greater the number of formats the CITIS data viewer/editor must handle, the more
complex and difficult to develop the system will be. Depending on the number of applications
launched, software licensing costs could also become a major consideration.
The solution to the data format problem may be the use of a neutral file format that allows data
created with a variety of different software applications to be saved in a format that can be read
by anyone possessing the associated file reader software.
8.2.4.5.2.3 Neutral Data File Options
Depending on the expected CITIS data usage (view, process, comment, etc.), the contractor may
choose to translate appropriate data into a neutral format rather than attempting to retain
information in its original file formats. These neutral formats, in general, can be created for files
developed with a variety of different applications and can then be read by anyone possessing the
associated reader software.
Textual data (e.g., technical manuals and reports, graphics, spreadsheets, etc.) is particularly well
suited for conversion to neutral file formats; databases and some engineering drawing formats
should be retained in their original format or converted to a standardized format (e.g., convert

206

from specific CAD format to IGES).

Some examples of neutral file formats include
platform-independent files and Standard Generalized Markup Language (SGML) files.
Several industry-developed software products for creating platform-independent files have
recently become available that allow users to save information created in a variety of software
applications and formats, including text, graphics, and spreadsheets, into a platform-independent
file format, which can then be viewed and printed by anyone possessing the associated reader
software.
Many applications also allow reader-software users to annotate data and copy information that
can then be pasted into other word processing programs. Because of their flexibility in handling
a wide range of software packages, contractors may want to explore these platform-independent
file applications when determining standard CITIS file formats.
SGML is the CALS standard for the exchange of text material for technical documents. It is a
non-proprietary format that is not bound to any system software or platform. SGML can handle
both text and graphics. A number of SGML authoring software packages are currently available
as COTS software. As with the platform-independent files, SGML reader software is required to
utilize data in an SGML format.
Most SGML readers allow the user to, as a minimum, view, annotate, and print data. One of the
current considerations when selecting SGML formats is that it is not yet widely used because of
the present lack of Document Type Definitions (DTD) and Formatting Output Specification
Instances (FOSI), which are needed to create or translate data into SGML formats.
The neutral format reader software discussed above is especially appropriate for data that will be
viewed and printed only.
Some SGML readers, and the authoring versions of
platform-independent file and SGML applications should allow users to perform most of the
other data functions such as processing and updating the data.
8.2.4.5.2.4 Hardware and Telecommunications Options
When determining the infrastructure for CITIS, the program manager must decide whether the
contractor or the NATO/NATO nations or both will provide the hardware and
telecommunications for the NATO/NATO nations to interface with CITIS. Typically, the
NATO/NATO nations will use its own computer hardware, including modems, and software to
access the CITIS data, with the contractor providing only the software necessary to access
CITIS. However, the program manager may choose to have the contractor provide computer
hardware (e.g., complete PCS, terminals, etc.) and/or software to be located at NATO/NATO
nations facilities and used exclusively for CITIS access. This option may be especially attractive
for locations that could otherwise require infrastructure upgrades to access CITIS.
Telecommunications involves the physical connection to CITIS via telephone or other type of
lines. The CITIS access can be via regular phone lines, dedicated modem lines, high-speed
optical lines, or networks, and will typically be a combination of these methods.

207

If any new lines or networks will be required, the program manager must decide whether the
NATO/NATO nations or the contractor will be responsible for line installation and maintenance.
The NATO/NATO nations will typically pay for its own connection time charges (e.g., phone
line usage) for use of its own telecommunications lines. The NATO/NATO nations however,
may require the contractor to establish an 800-number hotline that can be used by the specified
number of concurrent CITIS users.
8.2.4.5.2.5 Infrastructure Changes
Because of the rapidly changing computer hardware and software technology, it is reasonable to
assume that at some point during the life of the CITIS, the NATO/NATO nations users will
upgrade either their hardware or software or both. This upgrade can cause major problems for
the CITIS developers if the existing CITIS has been created to be compatible only with
NATO/NATO nations systems as they were at the beginning of the development effort. The
NATO/NATO nations and the contractor should agree up-front as to what technology
refreshments the NATO/NATO nations can expect the contractor to incorporate after the CITIS
has been implemented. The NATO/NATO nations may also want to state explicitly that CITIS
shall be upgraded to be compatible with any major changes in hardware and/or network
configuration.
Problems can occur when a CITIS user facility reconfigures its networks and then finds that it
can no longer communicate properly with the CITIS. Obviously, there needs to be some control
over and planning for the number of anticipated changes the contractor is required to
incorporate/handle. Ideally, the CITIS will be developed to operate independently of users
operating systems and specific hardware and software. In reality, however, the hardware and
software compatibility problems described above can and will occur. CITIS user group meetings
can serve as an excellent forum for discussion of compatibility problems, technology
advancements, and the advantages and disadvantages to upgrades to the CITIS.
It is highly recommended that the NATO/NATO nations designate at least one person who is
knowledgeable in computer hardware, software, and networks to be its CITIS administrator.
This person will be trained in the specifics of how the CITIS system works and how it is set up at
their facility. Ideally, a CITIS administrator would be selected for each of the NATO/NATO
nations CITIS locations.
The CITIS administrator(s) should filter NATO/NATO nations
complaints and issues before bringing them to the contractor, and should be responsible for
making upgrades to local hardware and software work with CITIS. When a hardware or network
incompatibility problem arises, it is often due to a change in the users PC or network
configuration. The local CITIS administrator should attempt to solve compatibility problems
before contacting the CITIS developers, who may simply direct the problem back to the
NATO/NATO nations as an internal facility problem.
8.2.4.6 CITIS Issues
When CITIS is being considered and/or developed, the program manager must be aware of some
of the legal issues accompanying the use of a CITIS.

208

8.2.4.6.1 Legal Issues

Because CITIS can involve extensive sharing of data between contractors, subcontractors, and
NATO/NATO nations activities, a significant number of legal issues have been raised and are
still being debated. Some of the most prevalent issues include the questions of proprietary data
rights (who owns the data when), software licensing, warranties and liabilities, and international
data exchange.
8.2.4.6.1.1 Proprietary Data Rights
NATO/NATO nations, in consequence of the delivery of a data item, should not acquire
ownership of the data item or any rights or license to use, copy, or disclose such data item. The
extent and nature of rights that the NATO/NATO nations may acquire to use, copy, or disclose
data items shall be as expressly stated in the contract. When dealing with intellectual property,
there is an increased risk of misuse of proprietary and business sensitive data in digital form. No
NATO regulation currently exists to assess liability on third parties for copyright or patent
infringement. Even with access limitations, proprietary markings, such as proprietary legends
and restrictive distribution statements, may be inadvertently deleted. The problem could be
compounded if the CITIS network includes access by other contractors and subcontractors in
addition to the prime contractor, because the release of proprietary data to widely accessed
databases could amount to abandonment of secrecy with a resultant loss of rights. Finally, there
is the potential problem where Contractor A does not want Contractor B to have access to its
data, but it can be difficult to prevent that access on a robust CITIS network. All of these issues
should be considered and discussed by the NATO/NATO nations and the prime contractor in the
early stages of CITIS planning.
8.2.4.6.1.2 Software Rights/Licensing
Potential third party licensing problems can arise whenever CITIS is used to launch/access other
applications.
If the applications being accessed are commercial software packages, the
contractor will need to investigate the licensing policies of the software development company.
In some cases, they may need to either purchase individual licenses for the maximum number of
concurrent CITIS users or purchase a network or site license that allows specified or unlimited
usage of the software. If the applications being accessed were developed by either the prime or
other contractor, the CITIS developers will need to verify that the application has been released
for general use. If access is restricted, those restrictions must be incorporated into the CITIS
access rule set that will deny access to anyone without the proper authorization.
Care should be taken to identify and grant access to both commercial and contractor-developed
applications only to people who actually require that access in order to avoid excessive license
purchases and proprietary data conflicts (i.e., do not just automatically grant all CITIS users
access to all applications).
8.2.4.6.2 Warranties and Liabilities
The contractor warrants that the data provided by them via the CITIS is accurate and complete,
but the question of who is responsible for warranting data products created by CITIS users with

209

ad-hoc queries has not yet been answered. The contractor can (and should) be held liable for
providing defective data to the NATO/NATO nations, but unfortunately, lack of statutory laws
results in the contractor also being held liable for misuse of any data they provide. Until existing
laws are changed, the contractor is liable for damages when data provided through CITIS is used
incorrectly.
8.2.4.6.3 International Data Exchange
International data exchange is complicated by differences in treatment of intellectual data from
nation to nation. Some nations do not recognize or protect intellectual property. Export
licensing of technical data also creates a barrier to international CITIS implementation. Any data
to be released internationally needs prior NATO/NATO nations approval.
8.2.5 Applying CALS to the Acquisition Logistics and Operational Logistics Processes
8.2.5.1 Acquisition Logistics and Operational Logistics

Mission
Need

Manage
Continuous
Acquisition
Process and
Data

Engineering Data
Contract

Define,
Design & Test
Defence
System

Qualified
Engineering
Data

Produce
Defense
System

Defence
System

Figure 8-5 Acquire Defense System

The life-cycle of a weapon system begins with the identification of a perceived need, which is
then analyzed and translated into detailed requirements. Those requirements constitute the input
to the design process, which is followed by the production of the prime equipment of the weapon
system, together with its associated support equipment. The system is then fielded and, after its
useful life, it is phased out (Figure 8-5).
Within the life-cycle of a weapon system, Acquisition Logistics is the process managed within
the specification, definition, and production of defense equipment, which concurrently identifies

210

the support elements that will be required during the useful life of the equipment.
elements of the Acquisition Logistics are:

The basic

Integrated Logistic Support (ILS)

Logistic Support Analysis (LSA)
LSA Record (LSAR)
Initial Provisioning
Technical Documentation

Operational Logistics covers those functions that support the equipment through its useful life
(from the utilization process onward to its withdrawal from service). The operational logistics
basic functions include:

Configuration Management
Order Administration
Invoicing
Delivery
Stock Management
Equipment Maintenance

8.2.5.2 ILS, LSA, and LSAR Introduction

Within the United States, the application of the 1388 series of mil standards has been rescinded.
However, the basic activities these standards proscribed and managed remain integral parts of the
acquisition process. Additionally, many organizations have invested heavily in processes and
tools that are structured to provide 1388 compliant LSA materials and will continue to utilize
these methods while transitioning to a performance based environment. Therefore, this LSA and
LSAR discussion is presented retaining references to the 1388 series.
8.2.5.2.1 The Integrated Logistics Support
The Integrated Logistics Support (ILS) includes all those coordinated and iterative management
and technical tasks required to:

Make sure that the support is taken into consideration in the requirements concerning the
defense system and its design;
Specify and define the support system;
Implement the support system as defined above;
Maintain it throughout the equipment life-cycle

It is an organized, planned effort that provides for support and maintenance considerations that
influence the design of systems acquired by the Defense. The planning of the ILS effort is the
key in fitting all of the logistic support elements together in a timely manner.

211

8.2.5.2.2 Logistics Support Analysis

Logistics Support Analysis (LSA) is a systematic and comprehensive analytical process that is
conducted on an iterative basis through all life-cycle phases of the system/equipment. LSA is for
quantifying and measuring supportability objectives.
LSA information consists of all data
resulting from the analysis tasks and is intended to be the primary source of validated, integrated,
design-related product support information pertaining to an acquisition program.
The Logistics Support Analysis process ties the ILS efforts together following the full life-cycle
of the end item. The LSA process is a subset of systems engineering effort. It performs a
planned series of tasks to:

Examine all elements of a proposed system to determine the logistic support resources
required to keep that system usable for its intended purpose;
Influence the design so that both the system and support can be provided at an affordable
cost.

LSA process was formerly centered on MIL-STD-1388 that used to be a US Department of

Defense standard. Its major strengths are the presentation of a disciplined process of LSA (a
philosophy not specific to nation or application) and the description of a set of LSA data
elements that may be handled in computer database to derive LSA outputs to other processes.
For this reason, the process is already in international use, and beyond defense. The weakness of
the standard for NATO use is its in-built specific instructions and references only applicable to
the US DoD. The studies in progress on the subject involve several agencies and nations and
will provide a neutral data model that encompasses the three major logistics business standards
(MIL-STD-1388, AECMA S2000M and AECMA S1000).
While waiting for the completion and agreement by the nations of the neutral model, the
following guidelines could be used in the interim:

For LSA processes, any commercial or government implementation of a MIL-STD-13882B relational database can be used directly or can be used as a model when determining
data requirements.
For initial provisioning, order administration and other operational logistics support
processes, AECMAs Spec 2000M should be followed.

8.2.5.2.3 Logistics Support Analysis Record

The Logistics Support Analysis Record (LSAR) is a subset of LSA data that resides in an
approved format in an approved database system (Figure 8-6).

212

Integrated Logistics Support (ILS)

Maintenance

Planning
Manpower&Personnel
Supply Support
Support Equipment
Technical Data
Training/Training Support
Computer Resources Support
Facilities
Packaging, Handling,
Storage & Transportation
Design Interface

Logistics Support Analysis (LSA)

MIL-STD-1388-1A

100 - Programme Planning

& Control;
200 - Mission and Support System
definition;
300 - Preparation and evaluation of
alternatives;
400 - Determine Logistic Support
Resource requirements
500 - Supportability Assessment

LSA Record (LSAR)

MIL-STD-1388-2A
15 Data Records
115 Data Cards
547 Data Elements
80 Std Report Formats
MIL-STD-1388-2B
104 Relational Tables
518 Data Elements
48 Std Report Formats

Figure 8-6 LSA/LSAR Relationship

8.2.5.2.4 ILS Summary
ILS data may be presented in any form or characteristic including, but not limited to, hard copy,
audio/visual displays, magnetic tape, disc, and other electronic media.
ILS data normally
consists of plans, reports, and analyzes performed in support of development, deployment, and
support of a specific Defense system. ILS data will be created in a processable data format
consisting primarily of text.
An ILS program interfaces with and produces processable data related to:

Maintenance Planning
Manpower and Personnel
Supply Support
Support Equipment
Technical Data
Training and Training Support
Computer Resources Support
Facilities
Packaging, Handling, Storage, and
Transportation Design Interface

8.2.5.2.5 LSA Summary

LSA information is generated as a result of the analysis tasks and consists of all data resulting
from the analysis tasks and is intended to be the primary source of validated, integrated,
design-related product support information pertaining to an acquisition program.
LSA information is developed and maintained as a result of design, support, and operational
concept development and is updated to reflect changes. Changes can occur because of the

213

availability of better information from testing, configuration changes, operational concept

changes, and support concept changes during the acquisition process. Iterated versions of LSA
information and data can provide an audit trail of supportability and supportability-related design
analyzes and decisions.
8.2.5.2.6 LSAR Summary
LSA Record (LSAR) data is a subset of LSA information and is a structured means of
aggregating LSA data. It is available for use by all services and ILS element functional areas.
Because each element of LSAR data is defined and has a specified data structure, the LSAR has
evolved as the primary means of storing logistic support data in digital media. The LSAR
database (created as a processable database) shall serve as the center of the ILS technical support
database, which can interface with other materiel acquisition programs to satisfy the support
acquisition.

LSA Documentation
Mil Std
1388-1A

Logistics Support Analysis

Tasks
Tailoring Guidance

Mil Std
1388-2B

Logistics Support Analysis Record

Data Elements
Relational Tables
Report Formats
Tailoring Guidance

Figure 8-7 LSA Documentation

Simply put, the LSAR is that portion of the LSA information consisting of the detailed data
pertaining to the identification of Logistics Support resource requirements of a system or
equipment. The LSAR is not an end product but is intended to be used and updated throughout
the acquisition life-cycle of the system or equipment.
8.2.5.2.7 MIL-STD-1388-2B Summary
MIL-STD-1388-2B contains relational table areas, which are further divided into 104 relational
data tables. MIL-STD-1388-2B satisfies a wider range of logistic product requirements and

214

promotes the use of relational database management systems for LSAR automated data
processing (ADP) systems.
Just like MIL-STD-1388-2A, MIL-STD-1388-2B provides
information pertaining to technical characteristics of a system or equipment and provides data
directly related to the supportability of that system or equipment. MIL-STD-1388-2B Appendix
A provides guidance for fulfilling the requirements of a relational database system.

X Tables: Cross Reference Requirements

A Tables: Operations and maintenance Requirements
B Tables: RMA Data, FMECA and Maintainability Analyzes
C Tables: Task inventory, Task Analyzes, Personnel and Support
E Tables: Support Equipment and Training Material
F Tables: Facilities considerations
G Tables: Personnel Skill considerations
U Tables: Unit Under Test Requirements and Description

The interrelationships and data hierarchy among tables is established only through common data
element keys and data values. MIL-STD-1388-2B provides the media options of the LSAR
relational tables being delivered. This provides the capability to subsequently produce any of the
LSA reports, other data files, and ad hoc reports via the query capability of a validated LSA
relational ADP system.
8.2.5.2.8 AECMA SPEC 2000M Summary
AECMA SPEC 2000M is designed to cover all material management activities in support of
military aircraft. It is a multi-national military aerospace standard developed specifically to
support the military end customers manage their spares acquisition. It is not designed to transmit
design data. It is currently being implemented in five European countries (France, Germany,
Italy, Spain and UK).
Before completion and agreement by the nations of the neutral data format, AECMAs Spec
2000M should be followed for initial provisioning, order administration and other operational
logistics support processes.
8.2.5.2.9 AECMA SPEC 1000D Summary
AECMA SPEC 1000M is used within the European Aerospace industry to provide a controlled
environment for the management of data elements from which technical documents, in whatever
form, can be produced. Its background is in multi-national air projects and this has led to the
specification having generic principles embedded in air specific application of the principles.
8.2.5.3 LSA DATA Activities
8.2.5.3.1 LSA Data Creation Activities
The first level of activity during the acquisition phase of a program is the creation of the data.
The acquisition project manager is the primary focal point during the creation phase. Of utmost

215

concern to the project manager from a CALS perspective, should be the assurance that the data is
developed once and then used many times. The ability to review and/or access LSA data by all
areas involved in the design process ensures early identification and quantification of support
systems requirements as well as the best design for supportability. The project manager must
ensure that the internal contractor product development team members, as well as NATO/NATO
nations reviewing agencies, have access to current and relevant LSA data.
The ability to access and review digital data is driven by the availability of appropriate
infrastructure. The project manager should ensure all functional areas are addressed in the
NCoO and that the appropriate infrastructure is in place or will be phased-in as the acquisition
progresses prior to contract placement.
Of equal importance, the project manager should ensure that support activities are aware of LSA
data access, review and approval methodologies, and the roles and responsibilities each activity
will play.
8.2.5.3.2 Follow-on LSA Data Modification
In addition to concerns associated with the creation of LSA data, the project manager should
consider future requirements to modify the data. It is of particular importance to ensure that all
Front-End Analyzes studies, as well as the LSAR database, are made available on digital media
to the depot or support agency in a usable format. By doing this, the depot and/or support
agency will be provided not only with the LSAR database that supports the design, but also with
analyzes and studies used to arrive at the design.
8.2.5.3.3 LSA Data Management
The second level of activity is associated with the management of LSA data during both the
acquisition and operational phases. It should be noted that "LSA data management" will be
afforded the same management controls as any other technical data acquisition, but with the
emphasis being on digital delivery or electronic access.
The project manager must consider the specific NATO/NATO nations infrastructure program
that will manage and store the digital data during both phases. The data delivered must be
compatible with the existing digital NATO/NATO nations systems in place or being developed.
If changes to the digital NATO/NATO nations infrastructure systems are required, they must be
fully justified and coordinated with the personnel responsible for the management and
configuration control of LSA data.
During the operational phase, the LSA data is typically assigned to a support organization such
as a Depot or organic NATO/NATO nations Data Repository. Of primary importance here
would be making data available to potential users and maintaining configuration control.
8.2.5.3.4 LSA Data Uses During the Acquisition Process
The final level of activity is associated with the use of LSA data.
Process, LSA data is typically used in three ways:

216

During the Acquisition

First, the logistic support analysis (MIL-STD-1388-1A) Front End Analysis 200 and 300
series tasks are used to influence and provide a basis for the design of the system (both
the hardware and the support elements required for deployment and use).

Secondly, the LSAR database is used to capture the systems configuration and
maintenance/ support requirements and procedures.

Finally, the LSAR database is used as a cornerstone for the developing ILS element
products that include technical data, training data, supply support data, etc.

Paramount to ILS product development is the timely access to current and accurate LSA data.
The following are just a few of the considerations the project manager should make when
contracting for LSA data:
Technical Data: Since the technical data functional area has access not only to LSAR data, but
also to technical drawings and associated supply support data, the project manager must ensure
this data is closely managed for the development of data products such as Technical Manuals
(TM). The LSAR task analysis (LSA-Task-401) is a basis for, and/or a direct input to the
systems TM(s). The project manager should ensure that the development of the TM(s) and the
detailed LSA task analysis are orchestrated in such a manner as to eliminate duplicate efforts.
Training and Training Support (T&TS) Data: This functional area takes information from the
LSAR and uses it as source data to develop the training plans and various other training
products. An important CALS-related consideration would be to ensure the training-related LSA
source data for the training development are in a usable digital format.
Supply Support: Supply support and initial provisioning efforts take direct advantage of the data
contained within the LSAR database.
Support Equipment: Support Equipment Recommendation Data (SERD) information is typically
generated during the LSA process and captured within the LSAR database.
8.2.5.3.5 LSA Data Uses During the Operational Phase
A major concern to the project manager is the accuracy of the LSA data during the operational
phase of a program. The project manager should ensure that both LSA Front End Analysis data
and the LSAR database are made available and/or maintained by the support organization for
both configuration control and evaluation of potential Engineering Change Proposals (ECP)
during the operational phase.
One additional area of major importance concerns the end users. The end users perform a vital
feedback function with LSA Task 501. Knowledge of actual usage of the data when fed back
into the LSA process is invaluable in correcting design and support system deficiencies. The
project manager must not overlook this vital source of data and should consider the end users
when acquiring digital data and feedback methodologies. In conclusion, the project manager

217

must include in the decision making process the infrastructure that exists at all user sites being
considered.
It is counterproductive to generate and make available to the end users digital data that they do
not have the capability of using. The project manager cannot assume the infrastructure exists
and will be used. The end users specific environment must be determined.
8.2.5.3.6 CALS-Related Questions
Questions that must be asked and answered include:

What systems are available in the field and at support organizations?

How is the data to be used by the field/support organizations?
For specific users, what data media and formats are compatible with what
equipment/systems they already have or are planning to acquire?
How will they acquire the new equipment and software needed if existing systems are
inadequate?
How will these new systems be supported?
The answers to these and similar questions will provide a comprehensive plan for
implementing and using the digital data that is acquired. The answers are dependent on
the individual users in the specific acquisition program.

8.2.5.4 LSA Process in a CALS Environment

The four prime factors that govern system acquisition programs are cost, schedule, performance,
and supportability. The LSA process provides direct input into the supportability and cost
factors associated with a system/equipment and, therefore, provides significant input into
system/equipment decisions.
The CALS environment offers the opportunity through digital
application of the LSA process for reductions in LCC. The ability to create data once (including
LSA, engineering, and ILS data) and use it many times impacts the cost of the LSA process and
the follow-on support costs. If the LSA data and associated analyzes are created in a digital
format, then digital data required for the LSA can be linked and fed to the LSAR database in an
automated fashion. The initially created LSA data is then available for use in all technical data
products.
The project manager must consider the digital format, media, HW/SW issues, required
framework, architecture, and NATO military customers infrastructure when developing the
NCoC concurrently with selecting LSA tasks.
Harmonized MIL-STD-1388-2B/AECMA
2000M/AECMA 1000D, when completed, should be required for all new procurements. In
addition, the instructions to offerors could indicate that the digital application and delivery of
LSA data will be weighted strongly in the evaluation of the offerors "Contractors Approach to
CALS (CAC)" response.

218

8.2.5.4.1 Potential Sources of LSA Data

The digital application of data must start with the onset RFP/RFQ process. Project managers
should begin by providing Customer Furnished Information (CFI), including the LSA strategy
and ILS planning information, in digital form to the contractor. Digitizing these products will
help reinforce the NATO/NATO nations commitment to CALS, as well as reduce costs and
improve communications.
Populating the LSAR database can be aided by a well-defined LSA Plan (LSAP). The project
manager should require that this plan define not only who in the Contractors organization is
responsible for generating and receiving LSA source data, but also in what form the data should
be developed, and how the Contractor plans to import this data into the LSAR database.
Populating the LSAR database would be simplified if the LSA data existed in a digital format
and data needed could be easily extracted for input. The amount of preparation and maintenance
of the LSAR database is directly related to the complexity of the hardware and software end item
design.
8.2.5.4.2 Managing/Maintaining LSA Data
The project manager will decide whether the weapon systems data will be maintained under a
Contractor Integrated Technical Information Service (CITIS) arrangement or other digital means
of delivery to the NATO military customer. (See Section 5 of this Handbook for more
information on CITIS.)
In either event, the decision process in determining the LSA data required will be the same.
Considerations must be made that encompass all life-cycle phases from design to disposal. The
project manager must be aware of the infrastructure systems available that will be affected and
possibly use the LSA digital data created.
The project manager must keep abreast of
NATO/NATO nations programs that may create and/or use LSA data.
8.2.5.4.3 Using LSA Data in the CALS Environment
This subparagraph will focus on the current capabilities of CALS to employ and use the data that
exists in the LSA database. Distinctions between MIL-STD-1388-2A and MIL-STD- 1388-2B
will be discussed only where relevant to digital data interaction. Emphasis will be placed on
creating the data once and using it many times. The unique effects of a shared digital
environment on the current use of the LSAR database will be investigated and discussed.
8.2.5.4.4 CALS Effects on LSAR Report Requirements
In the past, the completeness and accuracy of the data has typically been verified by the
contractor demonstrating the ability to produce various output reports from the LSAR database.
The project manager is encouraged to shift emphasis from the delivery of the LSA reports to the
delivery of, and/or preferably the access to, the LSAR database itself. In doing this, the
verification of the database and its accuracy and completeness can be more easily and accurately
assessed.
However, prior to using this approach, the project manager must ensure that
infrastructure is in place to accept, process, manage, and validate the LSA data.

219

8.2.5.4.5 Interaction of LSA Data with Concurrent Engineering/Integrated Design

The LSA process is iterative in nature. The LSAR database provides a structured, uniform, yet
flexible/tailorable approach to the documentation of the data that results from accomplishing
various LSA tasks. As such, the LSA process is an effective tool to aid in the application of
concurrent engineering initiatives.
To be effective, the systems engineering LSA process must be initiated early in the acquisition
life-cycle, and must be updated through LSA process iteration to reflect changes in the hardware
design and support concept, and must be tailored to be commensurate with individual program
requirements, constraints, and characteristics.
This is consistent with concurrent
engineering/integrated design as all life-cycle support considerations are being considered at
each phase of the development process.
8.2.5.4.6 Specific CALS Considerations Affecting Data Acquisition
During the analysis of the supportability portion of the LSA process, LSA data is used as a
primary source for the development of data products associated with ILS elements such as
provisioning lists, personnel and training requirements, and technical data products. This assures
compatibility among ILS element products and permits common use of data that apply to more
than one logistic element.
The CALS infrastructure available to the project manager when he is ready to issue an RFQ/RFP
must be considered. Delivery of the LSA/LSAR data/database may be via digital media
(magnetic or optical media) or can be made available under a CITIS requirement. The media
selected will be driven by factors including infrastructure and data access needs.
8.2.5.4.7 Migration of LSA Data into ILS Element Products
For the proper migration of LSA data to be complete and in full support of all ILS element
products, the concurrent engineering concept must also be implemented. The project manager
must task the contractor to support the movement of LSA data into the design process and vice
versa. The LSA tasks and LSA data captured is driven by the requirements as set forth in the
acquisition contracts.
The LSA data and resulting LSAR database is then used as input data for decisions to develop
various ILS element products including training programs, support equipment, facilities, supply
support, manpower and personnel lists, environmental impact, parts control, and so on. It is
essential that coordination and interfacing of engineering disciplines and ILS functional elements
be effected to maximize the usage of data developed by each program element, thereby realizing
the economy of consistent and accurate information, and avoiding the generation of incompatible
ILS products. Again, we want to create the data once and use it multiple times.

220

8.2.5.5 Sample CALS and LSA Tasks Statement of Work

When requiring LSA tasks in an RFQ/RFP Statement of Work (SOW), specific requirements for
CALS should be included. The following subparagraphs offer ideas for specific language to be
included as part of a solicitation package.
8.2.5.5.1 MIL-STD-1388-1A 100 Series Tasks
The primary purpose of the 100 Series LSA tasks of MIL-STD-1388-1A is the management and
control of the LSA program. The project manager should include CALS as a factor when
performing Task 101, Development of an Early Logistics Support Analysis Strategy, when
deciding which of the LSA tasks and subtasks will provide the NATO/NATO nations with the
best return on investment. The following statement may be included in the SOW:
The contractor shall include as part of Task 102, Logistics Support Analysis Plan, a description
of how CALS (the digital management and flow of data) is being integrated into the LSA tasks
and shall identify how CALS will be used in interfacing the data developed from the LSA process
with other ILS and system-oriented tasks and data.
8.2.5.5.2 MIL-STD-1388-1A 200 Series Tasks
The 200 Series LSA tasks of MIL-STD-1388-1A are to establish supportability objectives and
supportability-related design goals, thresholds and constraints through comparison with existing
systems and analyzes of supportability, cost, and readiness drivers. CALS should be included as
part of the objectives, considerations, and comparisons.
The following statements may be included in the SOW when requiring a contractor to perform
one of the 200 Series LSA tasks of MIL-STD-1388-1A in which CALS should be considered:
The contractor shall perform Task 201, Use Study, to identify and document the pertinent
supportability factors related to the intended use of the (name of new system or equipment). This
study shall include the contractors intended use of CALS as one of the pertinent supportability
factors.
The contractor shall perform Task 202, Mission Hardware, Software, and Support
Standardization, to provide supportability and supportability-related design constraints for the
(name of new system or equipment) based on existing and planned logistic support resources
that have benefits due to cost, manpower, personnel, readiness, or support policy considerations
and benefits. Identification of existing and planned logistics support resources shall include
CALS as one of the potential benefit factors to be considered.
The contractor shall perform Task 203, Comparative Analysis, to select or develop a Baseline
Comparison System (BCS) representing characteristics of the (name of new system or
equipment). This analysis shall include any past CALS implementation of the design and support
of the existing system. The analysis may be a factor in which judgments can be made in
determining the feasibility of the supportability parameters. This analysis shall also include the
identification of areas for improvement in which CALS may be targeted.

221

The contractor shall perform Task 204, Technological Opportunities, to identify and evaluate
design opportunities for improvement of supportability characteristics and requirements of the
(name of new system or equipment). These opportunities shall consider implementation of CALS
into the design objectives and techniques. The identity of CALS implementation in design
improvements to logistic elements during development should also be considered.
8.2.5.5.3 MIL-STD-1388-1A 300 Series Tasks
The 300 Series LSA tasks of MIL-STD-1388-1A are to optimize the support system for the new
item and to develop a system that achieves the best balance among cost, schedule, performance,
and supportability. CALS should be considered as part of the functional requirements and/or a
support system alternative. The following statements may be included in the SOW when
requiring a contractor to perform one of the 300 Series LSA tasks of MIL-STD-1388-1A.
The contractor shall perform Task 301, Functional Requirements Identification, to identify the
operations, maintenance, and support functions that must be performed in the intended
environment for each (name of new system or equipment) alternative under consideration. The
identification shall include the contractors intended use of CALS as one of these functional
requirements.
The contractor shall perform Task 302, Support System Alternatives, to establish viable support
system alternatives for the (name of new system or equipment). The contractor shall include
support concepts that foster CALS utilization when developing alternatives to the system level
support concept.
The contractor shall perform Task 303, Evaluation of Alternatives and Tradeoff Analysis, to
determine the preferred support system alternative(s) for each (name of new system or
equipment) alternative. For each evaluation and tradeoff to be conducted under this task, the
contractor shall include the utilization of the intent of CALS as one of the criteria of evaluation.
8.2.5.5.4 MIL-STD-1388-1A 400 Series Tasks
The 400 Series tasks of MIL-STD-1388-1A are to identify the logistic support resource
requirements of the new system in its operational environment(s) and to develop plans for postproduction support. CALS considerations should have been identified as part of Task 303.
Task 401, Task Analysis, provides the detailed identification of requirements for all elements of
ILS to operate and support the new system/equipment. The results of task 401 are documented
in the Logistic Support Analysis (LSA) Record (LSAR) as described by MIL-STD-1388-2.
Although automation of the LSAR data is not mandatory, it is strongly encouraged and should be
a consideration in implementing a CALS environment since this data has a structured format
dictated by a standard. Commercial Off the Shelf (COTS) approved LSAR data software
packages are readily available. LSAR data is also suited for CITIS. The following statement
may be included in the SOW when requiring a contractor to perform Task 403 of
MIL-STD-1388-1A.

222

The contractor shall perform Task 403, Post Production Support Analysis, to assess the expected
useful life of the ( name of new system or equipment ). The assessment shall include a plan with
discussions that support the difficulties due to the use of CALS and digital data and the
modifications to the data during the remaining life of the system/equipment.
8.2.5.5.5 MIL-STD-1388-1A 500 Series Tasks
The 500 Series tasks of MIL-STD-1388-1A are to assure that specified requirements are
achieved and deficiencies corrected. The following statement may be included in the SOW
when requiring a contractor to perform the 500 Series Task of MIL-STD-1388- 1A.
The contractor shall perform Task 501, Supportability Test, Evaluation, and Verification, to
assess the achievement of specified supportability requirements, identify the reasons for
deviations from projections, and identify methods of correcting deficiencies and enhancing
system readiness. The assessment shall include CALS supportability cost and readiness drivers.
These CALS related drivers should have been identified in Tasks 203 and 303.
8.2.5.6 Future Considerations for the LSA Process in a CALS Environment
This paragraph will present some thoughts on where CALS is headed and how that might affect
data use in the future. The influence of infrastructure developments in NATO/NATO nations,
and even in the international community will all affect the potential environment in which the
LSA data acquired now may have to be used in the future.
8.2.5.6.1 Integrated Weapon Systems Database
8.2.5.6.1.1 Future Trends
Future trends must lead to and support the fundamental objective of CALS, which is to lower
costs to the Government, improve quality, and shorten lead times. The electronic sharing of data
allows it to be created once and then used by multiple users, multiple times. The integration of
functional processes will start with the integration of data. The acquisition strategy must
specifically address the automation and integration of technical information systems and
functional processes.
8.2.5.6.1.2 Effects on LSA Data and LSAR Databases
The process for determining LSA data and LSAR database requirements is an extension of the
process currently used for determining data requirements, selecting appropriate data items, and
developing the Contract Data Requirements List (CDRL) that identifies the requirements.
The LSA/LSAR databases are the building blocks that are necessary to support an IWSDB. The
process for determining LSA data and LSAR database requirements may evolve as the
requirement for access to the data intensifies. There is significant potential for reduction of data
requirements in that, with query capability, the Government can generate data, reports, and
products on demand rather than having the contractor prepare and deliver them. As digital data
utilization evolves, the media on which the data is delivered will also evolve.

223

8.2.5.6.2 Contractor Integrated Technical Information Service

8.2.5.6.2.1 Future Trends
Access to digital data will become the standard by which all acquisitions will be measured.
Because Contractor Integrated Technical Information Service (CITIS) provides access to
contractor-managed, functionally-integrated information, it must play a significant role in
improved Government operations and the streamlining of processes.
An effective CITIS
program will require foresight and added coordination efforts on the part of contractors,
Government sponsors, and potential CITIS users. Functional integration approaches, as well as
CITIS performance, must be considered. Measures should be developed to motivate contractors
with top-level commitments to produce overall, functional integration and an effective CITIS
implementation.
8.2.5.6.2.1 Effects on LSA
An effective LSA program will be planned, integrated, developed, and conducted in conjunction
with the requirements of the overall acquisition program objectives. The LSA process will be
established consistent with the type and phase of the acquisition program. To maximize the use
of the plans, procedures, front-end analyzes and reports developed from selected LSA tasks, it is
necessary to establish a viable communication link with the contractor. Providing an early-on
CITIS capability (including the front-end analyzes and documentation generated from the 200
and 300 series tasks of MIL-STD-1388- 1A) will enhance the LSA process and the overall
design effort.
8.2.5.6.2.2 Effects on LSA Databases
There are several considerations facing contractors when they are tasked with providing CITIS to
support LSA databases. Areas of consideration include the following:

Type of DBMS or languages: The number and disparity among database management
systems, programming languages, data models, data descriptions or data organizations,
and interface and access languages;
Data element format: The number of discrete techniques for re formatting data to be
presented to the user in a predefined, standard format including conversion of units of
measure, translation into standard format, and other agreed upon translations or
conversions;
Source or location of data and applications: The user must know the differences
concerning location, hardware, operation system, programming language, and access
methods for specific systems;
Relationship and dependencies: The degree to which the user must keep track of data
relationships and dependencies within and across integrated data sets;
Version knowledge and control: The degree to which the user must ensure that data
retrieved from more than one system and database are consistent in terms of data values,
version or status, and context.

224

8.2.5.6.3 NATO CALS Efforts

8.2.5.6.3.1.1 Objectives
8.2.5.6.3.1 Acquisition Workshop
The Acquisition Workshop Stage 1 (AWS1), held in April 1994, provided the outline of an
improved acquisition process and the recommendation for further work. A Study Management
Group (SMG) was chartered by the NCMB to conduct the second stage of the Acquisition
Workshop (AWS2). AWS2 was accomplished by bringing together 52 experts from industry,
governments, and NATO Agencies (senior officers and civilians). The workshop was sponsored
by the NCMB and the NATO Industry CALS Group (NICG) and was held at the French CALS
Office in Paris from 06 - 24 November 1995.
The objective of AWS2 was to refine the definition of an improved acquisition process in order
to identify data requirements to conduct business in a multinational environment. This included
the consideration of legal and contractual issues in a CALS environment and the development of
a management oriented advocacy plan for promotion of the workshop results.
8.2.5.6.3.1.2 Workshop Results

AWS1 stated that multidisciplinary groups (MDGs) will perform acquisition in the future
through continuous processes, in a shared data environment (SDE) and controlled through
project, quality, configuration, and data management. AWS2 refined and further decomposed
the "acquisition To-Be model" from AWS1 to arrive at an improved NATO reference acquisition
activity model. This being the basis, the data necessary, the way it should be used and shared,
and the information flows were considered; the corresponding generic data model was developed
as far as possible within the available time.
Within the acquisition processes, project life-cycle plans will enable the elimination of
unnecessary milestones by use of checkpoints and continuous control, to identify and mitigate
risks and to reduce delays and other impacts of external controls such as necessary financial
milestones. Ownership of data and responsibilities for activities must be defined in contracts.
Shared resourcing of the continuous controlling processes (Program-, Quality-, Configurationand Data Management) allows control aspects to be resolved within a program without delays
arising from separate customer audits, reviews and other external approvals. Benefits are the
early identification of risks and the reduction of lead-time.
The improved acquisition processes will exploit the following disciplines:
System Engineering and Multidisciplinary Groups
System engineering is an interdisciplinary collaborative approach to derive, evolve, and verify a
system solution to satisfy customer expectations. This concept encompasses a life-cycle oriented

225

approach, multidisciplinary teaming, concurrent engineering, and the recursive application of the
systems engineering processes on each level of development. MDGs are established by the
Program Manager and formed with resources shared between industry and government, their
composition is dynamic and adapted to the current activities. The main benefits are better
information (in quantity and quality) with the involvement of the right skills at the right time,
thus reducing the risk, and the quicker reaction in the decision-making processes throughout the
life-cycle.
Shared Data Environment (SDE)
A SDE is the information infrastructure that allows data to be shared electronically between all
industrial and governmental participants in a project. The building of the SDE starts at the
beginning of the program and evolves through the life-cycle of the defense system.
Consequently, the architecture must be very flexible and dynamic. An empowered MDG can
operate effectively in a SDE. Within the framework contractually agreed between governmental
and industrial participants the SDE provides different levels of data access as needed with
respect to tasks and responsibilities. It also permits many concurrent levels of executive
oversight. The integration of program and product data provides easier consistency of quality
and configuration management activities and enables through life traceability and experience
feedback. Reduced error rates and data acquisition costs in conjunction with faster data
exchange are the advantage of such an environment.

8.2.5.6.3.2.1 Objectives
8.2.5.6.3.2 Operational Logistics Workshop
Stage 1 of the Operational Logistics Workshops (OLWS 1) was led by Germany and was
accomplished by bringing together experts teams made from 67 logisticians (senior officers and
civilians from government and industry). It was held at the Universitat der Bundeswehr
Mnchen from 5-20 December 1995.
The OLWS Terms of Reference defined Operational Logistics as the process of managing the
logistics support for defense equipment during its in-service life, using the data and the
infrastructure acquired during the acquisition, acquisition logistics, and operational phases of its
life-cycle.
The objective of Stage 1 was to develop a TO-BE Activity Model which describes more
efficient processes and provides a basis for a common data model
8.2.5.6.3.2.2 Workshop Results

The result of the workshop was the definition of a TO-BE Activity Model and a glossary, which
describe a more efficient process to be carried out during the operational phase of a defense
systems life-cycle. The improvements were aimed at reducing costs, improve quality, improve
226

service to the customer, and, finally, improve interoperability among NATOs Armed Forces.
The developed TO-BE Model will serve as a reference point, or baseline, for future work by
NATO nations and industry. The final report of the OLWS 1 was published in January 1996.
Having completed OLWS 1, the following objectives remain from the Operational Logistics
Workshop Terms of Reference:

Develop a data model for the TO-BE activity model in accordance with the Acquisition
Data Model;
Make recommendations for transition into a future NATO Operational Logistics
environment allowing tailored national implementation.

8.2.5.7 Summary and Conclusions

As stated in the introduction to this handbook, CALS is a Defense strategy that will enable
creation that is more effective, exchange, and utilization of digital data. The underlying purpose
of this strategy is to move from a paper-intensive environment to a digital environment in an
effort to reduce weapon-system acquisition time, support costs, and improve both data and
product quality.
Given the current state of the Defense budget and the likelihood that Defense money will
continue to shrink in the foreseeable future, it is even more imperative that project managers
maximize the use of CALS as a springboard to reduced acquisition and downstream Operational
costs. The efficient utilization of the LSA process during a systems early life-cycle (design and
early development) is the cornerstone to reducing the overall system Operational costs. But in
addition to simply applying the LSA process during a design phase, the project managers must
implement an effective and logical approach to the overall acquisition and management of all
data including data associated with LSA, ILS, and engineering and program management
through the entire life-cycle of a system.
It is no longer acceptable to procure and reproduce data when, in fact, the only difference is the
format.
Significant cost savings can be realized by both buying and utilizing previously
procured data in a logical and controlled manner. The implementation of a CALS strategy will
allow the project manager to provide the foundation to electronically share the data that is
developed from his/her program with multiple users, multiple times.
Future CALS-related modernization efforts, including those presently underway, will help
improve and consolidate both data acquisition and data management. However, until these
efforts are completed, it is the individual project managers responsibility to apply CALS to the
maximum benefit of both his/her program and the NATO/NATO nations in general.
8.2.6 Applying CALS to the Creation, Management, and Use of Technical Data Packages
8.2.6.1 Introduction
Technical data packages (TDP) contain the information necessary to describe a defense system
and its components in terms of design, engineering, manufacturing, and logistics support.
227

Applying CALS to the creation, management, and use of TDPs will aid in accomplishing the
transition from paper-intensive defense system acquisition and support processes to an
automated and integrated digital process. It should be noted that the application of CALS-related
technologies to Defense processes should be seen as a means of improving and streamlining
these processes by providing better methods of creating, managing, and using data, not as a
method of replacing business practices.
8.2.6.1.1 Scope
It is recognized that each defense system program is unique with individual constraints and
access to a distinct set of infrastructure systems. This section is intended to provide the Defense
project manager with an overview of NATO business practices for the creation, management,
and use of TDPs in a CALS environment. Specific implementation of this process follows the
completion of the NATO/Government CALS Concept of Operation (NCoO) and may be
tailored.
8.2.6.1.2 Purpose
The planning process for the creation, management, and use of TDPs in a CALS environment
needs to take advantage of the capabilities provided by the automation and integration of
information systems. Various data content, media, and format options are available for the
delivery of digital TDPs needed to define and support a defense system. The intent of this
section is to:

Describe the various deliverable content, format, and media options for TDPs;
Explain the benefits for the available options;
Examine the life-cycle considerations for all options;
Describe the infrastructure of documentation and systems available to support the various
options;
Provide guidance for specific contract language required to support the selection of the
options;
Describe contractor validation and NATO/NATO nations verification procedures.

This section contains ordering information for the deliverable media and digital data format for
TDPs. The Contract Data Requirements List (CDRL) guidance contained in this section applies
to all TDP elements.

228

8.2.6.2 General Considerations

The development of an acquisition strategy for TDPs needs to be carefully examined to
maximize the value for a specific defense system program. Program development elements such
as technology, costs, end-item quantities, and schedules have a profound effect on the delivery
requirements for supporting TDPs. Therefore, project managers must consider the life-cycle of
the procurement and the existing and planned Defense infrastructure to support the TDPs for
their program.
Technical data packages (TDP) contain the information necessary to describe a defense
system and its components in terms of design, engineering, manufacturing, and logistics
support.
The following paragraphs discuss topics of consideration that must be addressed:

TDP Data;
TDPs in the CALS Environment;
Life-cycle Considerations;
Infrastructure Development;
Data Uses.

8.2.6.2.1 TDP Data

TDP data consists of: TDP elements, TDP management data, and TDP intelligent product data.
The same TDP data may be re-grouped in terms of data construction as: Engineering drawings
(without or with integral parts lists), Illustrated text documentation, or Intelligent product data.
8.2.6.2.1.1 Engineering Drawings and Integral Parts Lists (PL)
These data mainly consist of illustrations that describe a product or process interspersed with
small amounts of text that help explain the features of the product or process. However, in terms
of digital data delivery, all of these data may be delivered by either of the following methods:

Raster image files;

Processable data files, which in this case refers to vector data files, e.g., native Computer
Aided Design (CAD);
Initial Graphics Exchange Specification (IGES).

Types of engineering drawings (without or with integral parts lists) are as follows:

Conceptual Design Drawings and Integral PLs;

Developmental Design Drawings and Integral PLs;
Product Drawings and Integral PLs;
Commercial Drawings and Integral PLs;
Special Inspection Equipment (SIE);

229

Drawings and Integral PLs;

Special Tooling Drawings and Integral Pls.

8.2.6.2.1.2 Illustrated Text Documentation

Illustrated text documentation is data that mainly consists of text. Sometimes graphics are
present, but they usually consist of simple illustrations, figures, or tables. However, in terms of
digital data delivery, all of these documents may be delivered by any of the following methods:

Raster image files;

Processable data files, which in this case means text files;
Contractor Integrated Technical Information Service (CITIS).

Types of illustrated text documentation are as follows:

TDP Elements:
Conceptual Design Separate PLs;
Data Lists (DL), or Index Lists (IL);
Developmental Design Separate PLs;
DLs, or ILs Product Separate PLs;
DLs, ILs Commercial Separate PLs;
DLs, ILs Special Inspection Equipment (SIE) PLs;
DLs, ILs Special Tooling Separate PLs;
DLs, ILs Specifications Software and Software Documentation;
Test Requirements Documents;
SIE Operating Instructions;
SIE Description Documentation;
SIE Calibration Procedures;
Preservation, Packaging, Packing, and Marking Data;
TDP Management Data:
Source control drawing approval request;
Drawing number assignment report;
Proposed critical manufacturing process description;
TDP quality control program plan;
TDP validation report
Quality engineering planning list.
8.2.6.2.1.3 Product Description
Data Product description data or intelligent data includes 3-D information, such as product
models that contain the digital information required for full product definition.
Intelligent
product data are the totality of data required to completely define a product throughout its entire
life-cycle. Engineering drawings make up a very small portion of intelligent product data and

230

provide only the human interpretable information for a system. Standards are currently being
developed to define more completely this form of data for the following.
Types of product description data are as follows:

VHSIC hardware description language;

Electronic Design Interchange Format (EDIF);
IPC-D-350;
Native CAD format;
Gerber data.

8.2.6.2.2 TDPs in the CALS Environment

The CALS strategy provides the project manager with a framework of standards, specifications,
and systems to create, manage, and use information in a digital environment. The project
manager should recognize the importance of requiring digital data deliverables. The benefits
associated with using digital data far exceed what is being discussed in this section.
For TDPs, two benefits of digital data include:

Improving the handling and reducing the storage of TDP data, primarily engineering
drawings, with electronic filing and archiving, ideally creating a data repository.
Reducing the costs associated with printing and distributing TDP data, especially during
the development stages, by providing on-line access (CITIS) (see Section 5 - CITIS) to
contractor databases, so that the NATO/NATO nations procuring agency could access
specific TDP data required.

Please note that this section does not consider delivery of a TDP in other than digital format
justifiable. References to non-digital data deliverables are only made in conjunction with the
delivery of a digital product and for the sole purpose of verifying the quality and accuracy of the
digital transfer of data between the various digital systems.
A brief discussion of both non-digital and digital data deliverables is provided. The non-digital
deliverables will not be addressed again in this section since their importance in a CALS
environment is minimal. The digital deliverables will be mentioned here providing a brief
overview of options available to the project manager.
8.2.6.2.2.1 Paper, Mylar Hardcopy
Paper or Mylar Hardcopy has long been the traditional medium for delivery of Defense product
data and related information. TDPs delivered on this medium may have originated from many
sources including other existing hardcopy documentation, microfiche, microfilm, or any of the
digital data formats described in the following sections. Converting the data content of paper to
a digital data format requires infrastructure systems that include scanning hardware and software
to support the conversion of both text and graphics from hardcopy to electronic. Todays project

231

manager should accept hardcopy TDP deliverables only for the purpose of verifying the digital
deliverables.
8.2.6.2.3 Digital Data Deliverables
Digital data deliverables available in the CALS environment are extensive. Digital data provides
the project manager with a variety of digital data content, formats, and media option (Table 8-7).
Table 8-7 Digital Data Deliverables

Data Content: Drawing data

Data Product Description
Illustrated Text Documents
Illustrated Parts Catalogues
Data Formats: Text:
a. Raster
b. Unintelligent Text (ASCII)
c. Intelligent Text (SGML tags, Illustrations, etc.)
Image Data:
a. Raster
b. Native CAD
c. Vector
d. Neutral (STEP)
Media:

Magnetic tape
Magnetic disk
Optical disk
CITIS - interactive on-line access
CD-ROM

8.2.6.2.4 Life -cycle Considerations

As a defense system develops through its life-cycle, TDP deliverable requirements may vary. In
addition, the availability as well as the volume and format of the data generated by the contractor
changes. The project manager must be prepared to adjust the contract data requirements to meet
the needs of all organizations involved in the procurement and support of the defense system.
The project manager must anticipate the upcoming contract and be prepared to alter the data
requirements in the procurement documents.

232

The project manager must also consider the information volume and typical use of the particular
TDP element selected. To take advantage of the CALS strategy, data must be created and/or
obtained in a digital form during the earliest possible program phase. By starting early, product
information may be used repeatedly throughout the life-cycle. Failure to develop data in a digital
form early in a program can lead to requirements for costly data conversion and will deny
potential benefits from digital data exchange.
8.2.6.2.5 Infrastructure Development
Effective acquisition of digital data can only be done with full consideration of the ability of
Defense activities to receive, store, distribute, and use the digital data that complies with the
CALS standards. The project manager must establish the uses for which the data is required and
the infrastructure modernization programs available to support this data.
The evolution of infrastructure is a key consideration in implementing the CALS strategy on any
given acquisition. Deficiencies in program related infrastructure may require cost investments to
effectively implement the CALS strategy.
The availability of digital data processing and
telecommunications technology and approved standards for creation management, storage
management, transmission, data protection, and integrity of data at the time of delivery or access
are important criteria for acquisition decisions.
The current and projected capabilities of both the contractor and NATO Armed Forces
components must be assessed with respect to program needs and schedules. The NATO/NATO
nations Concept of Operation (NCoO), its Contractors approach to CALS Implementation
counterpart, and CALSIP (when required), are excellent vehicles for making these
determinations. Project managers must plan to acquire and/or access digital data products. The
data user infrastructure, the computing environment available to a particular user, must be
considered when acquiring digital data.
This environment establishes the data processing
capabilities of that user.
The following areas identify a users infrastructure:

Hardware: Determine the current and planned hardware available to support the defense
system program.
Software: This is the most critical element. Interoperability will normally be achieved
using software. Again, determine both present and future software applications and
availability.
Networks: Determine the local- and wide-area networking (LAN and WAN) capabilities
and whether CITIS will be used.

8.2.6.2.6 Data Uses

The project manager will need to identify the use of the data by all organizations involved in the
acquisition program.
Identification and establishment of data requirements are generally
determined by conducting a data call. The project manager must consider how data will be
processed in order to make good decisions on digital data requirements. The five categories of
data processing typical of most defense system programs are:
233

View only: The ability to examine a data file without the ability to change it. This
includes viewing selected portions of one or several documents as well as side-by-side
comparisons of documents.
Comment/Annotate: The ability to evaluate and highlight for future reference or to make
annotations, approvals, and comments without the ability to change the original file.
Annotations are associated with a specific item or location within a document and are
displayed whenever that point or area of the document is displayed.
Update/Maintain: The ability to change data either directly or through controlling
software in the active files on the host computer.
Extract/Process/Transform: The ability to extract and modify the format, composition,
and structure of the data into another usable form. Archive: The placing of data into a
repository to preserve it for future use. The interchange of text type data that traditionally
has been conveyed on paper can be transmitted or communicated electronically using the
established rules and formats of Electronic Data Interchange (EDI).

8.2.6.3 Specific Considerations

8.2.6.3.1 TDP Delivery
The purpose of this section is to determine the status and/or existence of a TDP and ultimately to
lead the project manager to a decision as to the specific type of digital data and media format
required to support the program. In addition to the immediate TDP requirements (acquire and/or
develop an end item or system), the project manager should consider the potential long term
engineering and support functions and requirements for technical data when selecting TDP
formats.
Utilization of existing legacy data is quite common when new systems use features of older
systems. The project manager should be aware that, even on completely new defense system
programs, some portion of the TDP may pre-exist. An important point to remember here is that
acquisition of the proper level and type of digital data is most cost effective when defined early
in the programs life-cycle.
8.2.6.3.2 Potential TDP Delivery Options
While actual delivery may include a mixture of options, TDP information falls into three
distinctly different delivery forms:

Document (drawing image): Hard copy or digital images (raster).

Processable Data Files: CAD data and Computer-aided Engineering (CAE) systems
create vector graphic files that define the geometry and associated data attributes of
defense systems assemblies, subassemblies, and components. Data generated in this
manner is capable of being updated; hence, the files containing data are processable. In
defense system development contracts, digital delivery of processable data files is
preferred and should be considered the standard of communication between the
contractor and the NATO/NATO nations.

234

CITIS interactive access: See section 5 (CITIS) for interactive access/delivery options.

8.2.6.3.3 Raster
Raster data is a binary representation of an image. Raster may be thought of as the electronic
version of a paper document. It contains no "intelligence" and must be reviewed through human
interpretation. There are two types of raster data, tiled and untiled. Tiled raster is the preferred
format because of smaller file size. A tiled raster image resembles a two-dimensional grid with
each "tile" or set of pixels representing a portion of the image. Text and graphics in raster data
formats are stored digitally, which allows more rapid and consistent access to the stored images
than paper. In addition, raster data can be sent via electronic means to remote sites.
Raster files can be edited in several ways:

Raster Edit: The manipulation of individual pixels or pixel groups;

Vector Overlay: Hybrid editing where vectors are overlaid onto a raster file (both the
raster and vector are stored as the final image);
Raster to Vector Conversion: Conversion of pixel groups to vector primitives.

Raster documents may be converted to processable text via Optical Character Recognition
(OCR) technology. With the advent of raster scanning technologies, the ability to convert
existing TDPs to digital data files has become available. However, the quality assurance process
(by human interpretation) required to verify the data contents may increase costs substantially.
In addition, raster image files require a large amount of memory storage due to their file structure
and contain no additional information other than each tiles position on a grid. Because of these
drawbacks, the project manager should consider processable data forms before considering raster
unless the TDP will not be used for competitive reprocurement.
8.2.6.3.4 Processable Data Files
Processable data files provide the majority of options available for digital TDP delivery.
Processable data files can be broken down into two additional categories, drawing and product
description data files and text data files. These categories are considered processable, because
the data can be manipulated by the user, interpreted by the computer, and reprocessed into an
updated or new form as specified by the user.
8.2.6.3.4.1 Drawing and Product Description Data Files
Drawing data files, the output of CAD systems, comprise vector data, and as the name "vector"
implies, the image produced is composed of vectors, a sequence of line segments. Vector data
provides geometrical and physical representation of objects in both two and three dimensions.
Vector data files are stored digitally allowing rapid retrieval and integration into other
compatible systems.
Because the data consists of a sequence of line segments and
patterns/symbols that represent entities with specific orientation and location, vector data can be
translated to code interpreted by some automated machine tools.

235

Drawings delivered in this format must conform to IGES Class II (MIL-D-28000) unless the
native vector CAD files are available in an agreed-to, compatible format. (The user of native
vector data must have the same type of CAD system or must have a direct translator from the
source system to the destination system.) The native CAD format is the preferred format during
early development phases in the defense system programs life-cycle, because the translation to
IGES will invariably exclude some of the data inherent in the native CAD files. If vector data is
not compatible between the user and the source, then the IGES standard should be delivered, as it
does allow dissimilar CAD systems to manipulate vector data. Final delivery, however, must be
in IGES. CAD2 supports vector data in IGES formats.
NOTE: There are no commercial or NATO/NATO nations standards for preparing 3-D CAD
models. As a result, repository systems may not have the capability to store usable 3-D CAD
products.
Project managers should consider acquiring any portion of the drawing package developed from
3-D modeling. Product description data is the most comprehensive form of digital data. Product
description data contains all information needed to describe a product completely, and a large
portion of this information can be directly interpreted by a computer. Product description data
allows the simulation of systems modifications prior to implementation and evaluation of form,
fit and function performance of components. In addition, product description data with its
inherent intelligence can be used to drive manufacturing processes.
8.2.6.3.4.2 Illustrated Text Data Files
Illustrated text data files provide a dynamic form of source data with two possibilities:

Separated files for text, graphics, alphanumeric, and audio/visual data;

Integrated files consolidating some or all of these different data representations.

Text data files include word processing and desktop publishing applications. Such data files can
provide the source data for multiple data applications that allow creation of standard and custom
documents as well as manipulation of the data for annotate/excerpt or update/maintain purposes.
Text data files can also import generic text [ASCII, SGML, etc.] and graphics [raster, CGM,
IGES, etc.] from other sources that may be otherwise incompatible. In addition, there are Page
Description Languages (PDL), sometimes called text presentation metafiles, which are used to
drive output devices such as printers. There may be instances when obtaining text data files
involves obtaining more than one format of graphical data. This may be due to multiple graphic
sources. This is an acceptable and highly likely situation. The project manager must be aware of
this possibility and be prepared to develop/modify the defense system contract requirements
accordingly.
8.2.6.3.4.3 Text Formats
There are three possible text formats available for consideration when invoking the option
specifying text data files. They are American Standards Code for Information Interchange
(ASCII) and tagged ASCII, Standard Generalized Markup Language (SGML), or raster. They
are described below.
236

ASCII was developed as a method of translation for computer processors to interpret

alphanumeric characters and symbols through binary representation. ASCII is the basic
text information used by most word processing applications and contains no formatting
information other than line feed and/or carriage returns. Word processing applications
can import ASCII text from other word processing applications, and some word
processing applications can translate formatted ASCII from other word processing
applications into their own format. This makes ASCII text ideal for most interim
deliverables since it can also be imported into an SGML application where it can be
SGML-tagged to become a CALS-compliant deliverable.

SGML is a standard that defines a language for document representation that formalizes
markup and frees it of system and processing dependencies. It provides a coherent and
unambiguous syntax for describing whatever a user chooses to identify within a
document. In the SGML scheme, the document contains only generic tags identifying
such structural elements as paragraphs, sections, etc., but no typesetting markup.
However, SGMLs tagging of ASCII text is a rather cumbersome proposition and may be
best suited for final data deliverables rather than interim deliverables. When considering
SGML as a deliverable format, the project manager must determine whether the
necessary computer environment is available and in place to accept the SGML
documentation.
Additional features associated with SGML are: Document Type
Definition (DTD), Output Specification (OS), and Formatting Output Specification
Instance (FOSI).

8.2.6.3.4.3.1 Graphics and Illustration Formats

There are many possible graphic image formats available for consideration when invoking the
option of specifying text data files. Two suggested formats described below are Computer
Graphics Metafile (CGM) and raster. CGM data is a two dimensional vector presentation used
primarily for charts, figures, and simple drawings. See 8.2.7.2.1.1 for a discussion of raster
data.
8.2.6.3.4.3.2 Standard Page Description Language

A PDL file is executed by an interpreter that controls a raster printer or other output device. A
PDL can be used to ensure that the composed document produced by an electronic publishing
system (which may impose additional processing limitations, such as font variations, kerning, or
hyphenation) would produce nearly identical hardcopy output on the widest possible spectrum of
printer devices. Standard Page Description Language (SPDL) document image files can be
acquired as interim deliverables or as final deliverables in addition to (but not in place of) other
digital data deliverables.

237

8.2.6.3.4.3.3 Neutral Data Files

Several industry-developed software products for platform-independent neutral data files have
recently become available that allow users to save information created in a variety of software
applications and formats, including text, graphics, and spreadsheets, into a platform-independent
file format. These files can then be viewed and printed by anyone possessing the appropriate
reader software. Many applications also allow reader-software users to annotate data and copy
information to paste into other word processing programs. Because of their flexibility in
handling a wide range of software packages, the NATO/NATO nations may want to consider
these platform-independent file applications when determining standard file formats, even
though they are not part of the CALS standards.
8.2.6.4 Decision Guidelines
8.2.6.4.1 Maintenance and Control of the TDP
The project manager must consider whether the NATO/NATO nations plan to maintain and
control the TDP internally. This deals with the underlying issues of who will maintain and
control the TDP once it has been delivered to the NATO/NATO nations and how will they do it.
It is assumed that the TDP will be developed in a digital environment, i.e., in a CAD/CAE
environment. The key point to remember is that if the NATO/NATO nations plan to maintain,
update, and/or produce various configurations of the TDP in the future, the TDP should be
delivered in an "intelligent" format, i.e., in processable data files including CAD/CAE files
versus document image files such as raster format. Conversely, if the NATO/NATO nations
does not plan to "update or maintain" the TDP, it is recommended that the project manager
consider a raster-format-only delivery. Delivery of a TDP in raster format does not eliminate
on-line or electronic type review via the comment/annotate option during the TDP development
cycle.
8.2.6.4.2 Competitive Reprocurement
The project manager must consider whether competitive reprocurement of the system, spares,
and follow-on support is planned.
This prompts the project manager to consider future
requirements for the TDP. Competitive procurements, as addressed in the Acquisition Plan, can
be significantly enhanced with the availability of "intelligent" digital information such as
Government Furnished Information (GFI) to the prospective bidders. If future acquisitions are
not anticipated, cost associated with delivery of the TDP in a processable data file format may be
unwarranted. If competitive reprocurement is planned, delivery of an "intelligent" format such
as processable data files is recommended. If competitive reprocurement is not planned, delivery
of an "intelligent" data format may not be cost effective, and a raster format is recommended.
8.2.6.4.3 TDP Modification/Revision Determination
Next, the project manager should consider whether the NATO/NATO nations anticipate revising
and/or modifying a significant portion of the TDP in the future. This applies only to the nondigital portion of the TDP. This prompts the project manager to determine whether the non-

238

digital portion of the TDP would serve the defense system program better in a digital format. If
future manipulation of the data is not anticipated, raster delivery is the most suitable option. If
the NATO/NATO nations do plan to revise and/or modify the TDP, additional digital data
considerations must be addressed.
8.2.6.4.4 Digital System/Environment
The project manager should now determine whether the contractors native digital
environment/system is known at this time. This is focused at determining the most economical
and efficient format for the various TDP components. (It is assumed that the NATO/NATO
nations has previously completed an NCoO and identified the applicable NATO/NATO nations
in place infrastructure.) Obviously, for competitive procurements prior to source selection, the
contractors digital environment will not be known. This is, of course, unless all prospective
contractors have identical digital environment/systems. If the contractors digital environment is
not known, consider the delivery of 2-D and 3-D CAD/CAE data files versus the delivery of a
more comprehensive set of product description data files.
8.2.6.4.5 System/Environment Compatibility
Next the project manager must determine whether the contractors and the NATO/NATO
nations digital environments/systems are compatible.
This focuses on the potential of
transferring processable data files directly between two similar systems versus the transfer of
data through a neutral data format. Since the transfer of data between similar systems is
typically less time consuming and is more accurate, this type of transfer is recommended.
However, where the two systems are not similar, the transfer of data via a neutral format is
recommended and/or quite necessary.
If the digital environments are compatible, it is
recommended that the transfer of data between the contractor and the NATO/NATO nations be
in the contractors native format.
If the digital environments are not compatible, it is
recommended that a neutral format, be used to transfer data between the contractor and the
NATO/NATO nations.
8.2.6.5 Sample CDRLs
8.2.6.5.1 Raster Delivery Option
The raster delivery option, which is described in section 3.3.3, allows the project manager to
obtain TDP data in a digital format. The data uses of the raster deliverable are somewhat limited
but do provide for view, archive, and comment/annotate capabilities. Suggested delivery media
options include: (1) Optical disk or CD-ROM, (2) magnetic disk, or (3) 9-track magnetic tape, all
in accordance with MIL-STD-1840. Paper documentation may be requested in addition to the
raster deliverables but only for verification of the raster data content.
The information contained in the contract vehicle should be tailored to meet the requirements
of the specific defense system program
Drawing master raster graphic tape shall be IAW MIL-R-28002, MIL-STD-1840, and the
following requirements. Data shall be on a 9-track magnetic tape. Raster graphics shall be type

239

1 untiled raster data, 512 X 512 in size. Each delivered 9-track tape shall include an ANSI label.
Raster image density shall be 200 PELS/Inch. The minimum number of PELS per line and
minimum number of scan lines shall be IAW MIL-R-28002. Raster image orientation shall be
PEL path of 90-line progression of 270. Acceptance of this data item shall be based upon: selfmerit/content, prior acceptance and validation of drawing trial raster data, and visual
comparative agreement with drawing originals or reproductions, if ordered.
The information contained in the contract vehicles should be tailored to meet the requirements of
the specific defense system program. The CDRL(s) must include language that specifies exactly
how data will be delivered (including media, format, and content) under the contract. CALS
standards and specifications should be invoked whenever possible.
8.2.6.5.2 Product Data File Delivery Option
Product data files consist of a variety of data delivery options including product data files, text
data files, and Product Data Exchange using standard for the Exchange of Product [STEP]
(PDES) data.
These data deliverables provide all the data uses including view, archive,
comment/annotate, update/maintain, and extract/process/transform.
Suggested delivery media
options include: (1) Optical disk, (2) magnetic disk, or (3) 9- track magnetic tape, all in
accordance with MIL-STD-1840. Paper documentation may be requested in addition to the
digital data deliverables but only for verification of the digital data. The CDRL must include
language that specifies exactly how data will be delivered (including media, format, and content)
under the contract. CALS standards should be invoked whenever possible.
Drawing master product data shall be IAW VHDL ANSI/IEEE 1076, EDIF EIA 548, and
IPC-D-350 and the following requirements. Data shall be on MIL-STD-1840 magnetic tape
format optical disk, CD-ROM, or magnetic disk with a mutually agreed upon format. Data shall
be organized as one drawing per file with multiple sheets permitted. Entities unsupported or
unspecified by the appropriate standards or specifications (VDHL, IPC, etc.) shall not affect the
data transfer integrity of the product information delivered under the contract. Format version
"(X)" shall be used. Acceptance of this data item shall be based upon: self-merit/content and
visual comparative agreement with drawing originals or reproductions, if ordered. Validation
here means determination of acceptable transfer and translation of data from the contractors
CAD/CAE system to the _____(add applicable interfacing system).
8.2.6.5.3 Native CAD/CAE Data File Delivery Option
CAD/CAE data files in native format consist of a variety of data delivery options including
native CAD data files, text data files, and PDES. These data deliverables provide all the data
uses including view, archive, comment/annotate, update/maintain, and extract/process/transform.
Suggested delivery media options include: (1) Optical disk, (2) magnetic disk, or (3) 9- track
magnetic tape, all in accordance with MIL-STD-1840.
Drawing master native CAD/CAE data shall be as follows. The data file format shall be
compatible with and delivered on a 9-track QIC tape, CD-ROM, or magnetic disk, compatible
with _____ (insert vendor product name). CAD/CAE system media shall be clearly labeled to

240

describe the media format method, content, and media density. Data shall be organized as one
drawing per file with multiple sheets permitted.
Data format shall be compatible with _____(insert vendor application package name, version
number) format, using the native binary format supported by the _____ (insert vendor product
name) CAD system.
All information necessary to open and manipulate the data files, including: libraries, logical
name definitions, and other supporting files shall be delivered with drawing files.
Non-vendor-supported "Utilities" (i.e., software product) shall not affect the data transfer
integrity of the product information delivered under the contract.
Acceptance of this data item shall be based upon: self-merit/content and visual comparative
agreement with drawing originals or reproductions, if ordered. Validation here means
determination of acceptable transfer and translation of data from the contractors CAD/CAE
system to the _____(add applicable interfacing system)
CDRL must include language that specifies exactly how data will be delivered (including media,
format, and content) under the contract. CALS standards should be invoked whenever possible.
8.2.6.5.4 Product Data File Delivery Option (IGES Format)
Product data files in IGES format consist of a variety of data delivery options including IGES
files, text data files, and PDES. Suggested delivery media options include: (1) Optical disk, (2)
magnetic disk, or (3) 9-track magnetic tape, all in accordance with MIL-STD-1840. Paper
documentation may be requested in addition to the digital data deliverables but only for
verification of the digital data.
Drawing master STEP CAD/CAE data shall be as follows. Data shall be delivered on a 9-track
tape, QIC tape, or magnetic disk. Data shall be organized as one drawing per file with multiple
sheets permitted. Unsupported or unspecified "volunteer" entities shall not affect the data
transfer integrity of the product information delivered under the contract. Data product files
shall be written in ASCII compatible forms.
8.2.6.6 Advantages and Disadvantages of Delivery Options
Table 8-8 lists some of the comparative advantages and disadvantages of TDP delivery as paper,
raster, vector, or processable data files.

241

Table 8-8 Advantages and Disadvantages of Delivery Options

Type

Paper

Raster

Vector

A
D
V
A
N
T
A
G
E
S

1. Already a
deliverable
form.
2. Can be copied
and distributed
easily.

1. Importable into
documents
2. Already a
deliverable form.
3. Electronic indexing,
filing, and
archiving.
4. Nearly exact
fidelity for
illustrations
providing format is
standard.
5. Files can be
compressed to
reduce size.

1. Easily edited,
maintained,
updated.
2. Electronic
indexing, filing,
and archiving.
3. Small file sizes
compared to raster
equivalents.
4. File information
compatibility
between editing,
sending, and
receiving systems.
5. Files contain
intelligent data.

D
I
S
A
D
V
A
N
T
A
G
E
S

1. Cannot be
edited or
changed.
2. Not importable
(must be
scanned to
digitize).
3. Bulky filing
system.
4. Originals can
be easily lost
or destroyed.
5. Originals
deteriorate
over time.

1. Editing is extremely
tedious.
2. Relatively large file
sizes.
3. Induced errors from
incompatibilities of
hardware even
when using an
agreed to standard.
4. Raster quality
dependent on
original and chosen
pels/inch standard.
5. Raster quality also
dependent on
accuracy of
equipment and
method used to
scan original
image.

1. Not directly
importable into
documents, must be
converted to a
raster format.

Processable
Data Files
1. Easily
edited,
maintained,
and updated.
2. Electronic
indexing,
filing, and
archiving.
3. Already a
deliverable
form.
4. Files accept
generic text
and raster
data from
other
sources.
1. International
standards not
fully
developed.
2. Drawing
data limited
to imported
raster images

8.2.6.7 Contract Validation

8.2.6.7.1 Contractor Validation
The contractor should be required to validate that the TDP and associated elements conform to
the contractual requirements. In those instances where materiel has been developed or produced,
the contractor shall validate that the TDP and associated elements accurately depict the materiel
developed or produced under the contract. Use of the TDP in producing, inspecting, and testing

242

satisfactory materiel is considered acceptable evidence that the validation requirement has been
met. When specified in the contract or purchase order, the contractors validation shall be
documented in a TDP validation report.
8.2.6.7.1.1 Validation by Contractor Physical Configuration Audit or Verification Reviews
The NATO/NATO nations may require the contractor to validate the TDP through Physical
Configuration Audits (PCA), Configuration Item Verification Reviews (CIVR), or by other
methods through specific work tasks in the statement of work of the contract or purchase order.
Unless such tasks are included in the contract or purchase order, the method of validation shall
remain the contractors option.
8.2.6.7.1.2 TDP Validation Report
A TDP validation report is used by the NATO/NATO nations to review the procedures and
evaluate the results of the contractors validation of the TDP as conforming to the data
requirements in the contract or purchase order.
8.2.6.7.2 Government Verification
8.2.6.7.2.1 Digital Data Product Acceptance
The unique aspect of CALS digital data deliverables is that they will be subject to inspection and
acceptance on several levels. The lowest level of acceptance is the data content and format. The
acceptance process at this level is identical to acceptance of the data product provided on paper.
This level of acceptance will be accomplished by viewing the data either through use of a
computer video screen or by viewing a paper printout of the data product. The next level of
acceptance is adherence to the specified CALS data exchange format. This will usually be
compliant with the CALS standardization documents or other national or international data
exchange standards. Automated tools may aid this level of acceptance. The next level of
acceptance is applied to the MIL-STD-1840 digital data format if it has been specified. Again,
automated tools may be used to verify compliance. Finally, the physical media may have
acceptance criteria to be applied. This level of acceptance will not be used if data has been
formally delivered by the CITIS. The means of inspection to be used should be provided to the
contractor as soon as these means have been determined. Any or all levels of acceptance may be
performed at the contractors facility or at a NATO/NATO nations facility, as required. In
addition to digital data acceptance, CITIS requires that additional acceptance requirements be
applied.
8.2.6.7.2.2 CITIS Acceptance
Acceptance of the service and the CITIS Contract Line Item Number (CLIN), if utilized, is
verification that the contractor has provided the service as specified. MIL-STD-974 and the
particular statement of work define the CITIS functional requirements. A checklist of CITIS
functional requirements may be prepared to assist in tracking contractor compliance. These
functional requirements may include service availability, maintenance response, provision for
core information functions, provision for value-added information functions, and the like.

243

Assurances of adequate acceptance testing for CITIS should be obtained via contractor
demonstration of the service. The test should include demonstration of functional capabilities
and verification that the CITIS will handle the data required without alteration of the data
product. Such a test is not required for each delivery but may be rerun if major maintenance has
been accomplished or if the sending or receiving systems have been changed enough to warrant
an additional test. If specific test data are deemed necessary for adequate testing of a CITIS, that
test data should be provided and results reviewed on-site at a customer facility. On-line access
service should be accepted when it is demonstrated that a person with proper authorization can
perform the contractually required core and value-added functions from a terminal or
workstation at the customers facility or as otherwise agreed. Electronic data transfer service
acceptance should occur when a single instance of transfer of the specific deliverable type can be
achieved including successful download of data into the customers system when contractually
required. This data may be real product data or test data, as appropriate.
8.2.6.7.2.3 CALSIP Acceptance
The original contract baseline requirements for CALS-compliant product(s) are subject to change
and redefinition, by mutual agreement, throughout the duration of the contract.
The
NATO/NATO nations verifies and controls, in part, the adequacy of the CALS product change
and redefinition process via the approval of the original and revision(s) of the CALS
Implementation Plan (CALSIP) along with the final acceptance of the CALSIP at contract
completion.
8.2.7 Applying CALS to the Creation, Management, and Use of Technical Manuals (TM)
8.2.7.1 General Consideration
Technical manuals are any technical publication or other form of media used to install, operate,
maintain, test, repair, overhaul, or provide logistic support of ships, aircraft, defense systems, or
defense material. They are the operating and maintenance instructions for military technicians.
They contain a combination of textual narrative and illustrative graphic images presented in a
formal, structured, page-oriented format governed by specific functional standards.
These manuals have traditionally been prepared and delivered in hard copy form as
camera-ready copy, which in turn are printed in large lots. However, TM data may be presented
or delivered in any media including, but not limited to, hard copy, audio and visual displays, online access, magnetic tape, discs, and other electronic devices.
The implementation of automated data processing technology offers numerous improvement
opportunities in both preparation of technical manuals and in the delivery, storage, distribution,
and maintenance of these manuals. Technical manual data in digital form can be stored on
magnetic or optical media, transmitted and shown on computer terminals, and printed on
demand. Acquiring technical manual deliverables in digital form allows the military user to
view required information without printing it on paper.
Acquiring processable data files provides the opportunity to tailor outputs for particular uses and
users.
Data can be reformatted into systematic trouble-shooting formats for maintenance

244

personnel, it can be adapted to expert system diagnostic programs, or it can be used to generate
training aids.
The development of a CALS strategy for TMs needs to be carefully examined to maximize the
value for a specific defense system program. Program attributes such as technology, costs,
quantities, and schedules have a profound effect on the delivery requirements for TMs. The
technical manual manager must consider the life-cycle of the procurement and the infrastructure
in place or being developed to support the TMs for their program.
The CALS environment will reduce or eliminate the need for conventional forms of media
such as paper, microfiche, and microfilm.
The benefits associated with using digital data for TMs include:

Improved handling and reduced storage of TM data with electronic filing and archiving;
Reduced costs associated with printing and distributing TMs by providing on-line access
to the TM data, so that naval personnel could access the data repository from their field
activity and view and/or print the specific TMs they require;
Improved accuracy and timeliness of the TM data, due in part to the simplified
incorporation of changes.

The acquisition guidance provided in this section applies to the three major TM categories:
Description, Operation, and Maintenance with Illustrated Parts Breakdown; Installation
and Checkout Procedures; and Technical Repair Standards.
For TMs the benefits of digital data include: improved handling, reduced storage, reduced
costs, improved accuracy and timeliness
The following paragraphs discuss various considerations that must be addressed:

Identify/Establish the Requirement for the TM

Identifying the TM Users Infrastructure
TMs in a CALS Environment
Life-cycle Considerations

8.2.7.1.1 Identify/Establish the Requirements for the TM

The project manager will first identify the requirement to procure a TM through the development
of overall supportability goals and the initial maintenance philosophy. This is brought about
through the Logistic Support Analysis (LSA) process.
The LSA process will quantify and define requirements such as the need to operate or perform
maintenance on equipment. The Logistic Support Analysis Record (LSAR) will contain the
necessary task narratives for the operation and maintenance of equipment and will be used as the
primary source for the development of technical manuals of various types.

245

8.2.7.1.2 Identifying the TM Users Requirements

The project manager must now identify the intended TM users infrastructure.
The users include:
Those involved in system acquisition, review, and approval;
The TM management infrastructure;
The end user.
The project manager should consider for each user:

The existing and planned infrastructures;

Available CALS data exchange standards;
The various digital data deliverable options in terms of media, format, and access.

The expected infrastructure will be documented in the NATO CALS Concept of Operations
(NCoO), and will include:

The hardware and software systems the NATO/NATO nations have, or is developing, to
manage and use the data;
Data users, types of data, frequency of use, and timeliness of data access or delivery to
each user;
Data use and the review and/or approval processes to support life-cycle functions;
Users locations and their primary functions in support of the defense system;
Data interchange requirements including format, media, applicable standards, and
existing telecommunications capabilities;
Access authorizations and restrictions;
Data acceptance requirements including data format and content of data and the
NATO/NATO nations process for accepting product, processable, or Contractor
Integrated Technical Information Service (CITIS) data;
Digital data resources or source data (libraries of historical data, standards, and
specifications) available to support program acquisition and logistics processes.

Acquisition requirements for user hardware and software to support a fielded defense system
must be considered during the CALS implementation strategy and planning process.
8.2.7.1.2.1 Infrastructure Development
Effective acquisition of digital data can be done only with full consideration of the ability of the
NATO/NATO nations to receive, store, distribute, and use digital data that complies with the
CALS standards. The project manager must establish the uses for which the data is required, and
the infrastructure modernization programs that must be available to support this data.
User data infrastructure is the computing environment available to a particular user.

246

The evolution of this infrastructure is a key consideration in implementing the CALS strategy on
any given acquisition. Deficiencies in the infrastructure modernization will jeopardize the effort
to implement the CALS TMs strategy effectively.
The availability of digital data processing and telecommunications technology and approved
standards for creation, storage, transmission, data protection, and integrity of data at the time of
delivery or access are important criteria for acquisition decisions. The current and projected
capabilities of both the contractor and NATO/NATO nations must be assessed with respect to
program needs and schedules. The NCoO, Contractors Approach to CALS (CAC), and CALS
Implementation Plan (CALSIP) are excellent vehicles for making these determinations.
The data user infrastructure, which is the computing environment available to a particular user,
must be considered when acquiring digital data.
This environment establishes the data
processing capabilities of that user. The following areas identify a users infrastructure:
Hardware: Determine the current and planned hardware available to support the defense system
program;

Software: This is the most critical element. Interoperability will normally be achieved
using software. Again, determine both present and future software applications and
availability.
Networks: Determine the local and wide-area networking capabilities and whether CITIS
will be used.

8.2.7.1.2.2 Data Uses

The project manager will need to identify the use of the data by all organizations involved in the
acquisition program in order to make good decisions on digital TMS requirements. The five
defined categories of data processing are:

View only: The ability to examine a data file without the ability to change it. This
includes viewing selected portions of one or several documents as well as side-by-side
comparisons of documents;
Comment/Annotate: The ability to evaluate and highlight for future reference or to make
annotations, approvals, and comments without the ability to change the original file.
Annotations are associated with a specific item or location within a document such that
the annotations are displayed whenever that point or area of the document is displayed;
Update/Maintain: The ability to change data, either directly or through controlling
software, in the active files on the host computer;
Extract/Process/Transform: The ability to extract and modify the format, composition,
and structure of the data into another usable form;
Archive: The placing of data into a repository to preserve it for future use.

247

8.2.7.1.3 TMs in the CALS Environment

The project manager should be aware that it is possible to acquire TMs in a variety of forms
depending upon the needs of the users. Documents such as maintenance manuals may be highly
beneficial when procured as Interactive Electronic TMs (IETM). The IETM user would be the
technician whose main concern is finding the desired maintenance-related information quickly
and easily without being burdened in the field with the entire maintenance manual.
Primary considerations for the project manager to address are the media, format, and content of
TM data deliverables and their respective end users.
Description, operation, and maintenance, and installation and checkout manuals, however, may
be procured best in raster or Page Description Language (PDL) since these manuals are not used
as often. Obviously, it is better to leave these decisions up to the individual program office since
each defense system program is unique in its requirements. Primary considerations for the
project manager to address when applying CALS to the creation, management, and use of TMs is
the media, format, and content of TM data deliverables and their respective end users. Paper,
microfiche, and microfilm have been included in this discussion of CALS because much of the
current inventory is still available on these media. The CALS initiatives will reduce or eliminate
the need for these forms of media in the future.
8.2.7.1.4 Non Digital Data Deliverables
8.2.7.1.4.1 Paper
Paper or final reproducible copy has long been the traditional media for delivery of product data
and related information. TMs delivered on this media may have originated from many sources
including other existing paper documentation, microfiche, microfilm, or any of the digital data
formats described in the following paragraphs.
The project manager should accept paper deliverables only for the purpose of verifying the
digital deliverables.
No digital data infrastructure requirements are necessary for TMs delivered on paper. However,
converting the data content of paper to a digital data format requires infrastructure systems that
include scanning hardware and software to support the conversion of both text and graphics from
hardcopy to electronic format.
8.2.7.1.4.2 Microfiche/Microfilm
Microfiche and microfilm are other traditional media for delivery of data. They are not
recommended media for obtaining new data, but are mentioned here since legacy data in this
form already exists. Converting the data contents of microfiche or microfilm to a more flexible
digital data format requires additional infrastructure requirements that include scanning hardware
and software to support both text and graphics.

248

8.2.7.1.4.3 Digital Data Deliverables

The project manager must choose from a variety of digital data formats and media options. For
TM delivery, the list includes:
8.2.7.1.4.3.1 Data Formats

Raster
Illustrated Text Data Files:
a) Text:
1) American Standards Code for Information Interchange (ASCII);
2) Standard Generalized Markup Language (SGML)
b) Illustrations:
1) Computer Graphics Metafile (CGM)
2) Initial Graphics Exchange Specification (IGES)
3) Raster
c) PDL
d) Neutral data files
Interactive Electronic Technical Manual (IETM)
8.2.7.1.4.3.2 Media

MIL-STD-1840 magnetic tape

Magnetic disk
Optical disk
CITIS - interactive access
8.2.7.1.4.4 Life -cycle Considerations
TMs are generally not required until the later acquisition life-cycle phases of a defense system
program. TMs available during the earlier phases may be preliminary copies that have not been
verified or have not received final acceptance but are useful for test verification, training, and
operation. Preliminary versions may be delivered in mutually agreeable word-processing format
while the FRCs should be in SGML format. Final Reproducible Copies (FRC) are available in
the later phases. The project manager must consider the information volume and typical use of
the data generated during each of these phases to determine the appropriate TM deliverable
format. Note that the deliverable format may be different for each phase.
Preliminary versions may be delivered in mutually agreeable word-processing format while the
FRCs should be in SGML format.

249

8.2.7.1.4.5 TM Contract Requirements

Delivery of defense system data in digital form requires changes to NATO solicitations and
contracts including their attachments and enclosures. These changes should be made with full
consideration of the ability of NATO to make cost effective use of digital data deliverables or
access.
Each defense system program may include unique requirements for which additional programspecific tailoring will be needed. Most of the applicable CALS standards and specifications
contain contract-negotiable options from which the project manager must choose to satisfy
program-specific requirements including multiple classes or types of data formats.
The TM Contract Requirements (TMCR) will identify the types of TMs required and include
language that specifies exactly how data will be delivered (including media, format, and content)
under the contract. SGML should be invoked whenever possible for digital delivery of TMs.
The media for delivery such as magnetic tape, optical disk, or on-line (networks, telephone
modems, CITIS) should be compatible with NATO/NATO nations receiving system capabilities.
Some digital interim deliverables may be efficiently acquired by agreeing on a common word
processing package in the contract and specifying the appropriate and compatible physical media
such as magnetic disk, magnetic tape, etc.
8.2.7.2 Specific Considerations
Once the general considerations have been reviewed, the information contained in this section
can be used to select the options best suited for the defense system program objectives. The
options must be evaluated for usefulness with respect to each phase of the defense systems lifecycle and whether the defense system programs infrastructure can support a particular option.
Once the most suitable options have been selected, the process to validate and verify these
options should be determined.
The following paragraphs discuss additional considerations that must be addressed:
8.2.7.2.1 TM Delivery Format Selection
The purpose of this paragraph is to determine the status and/or existence of the TM and
ultimately to lead the project manager to a decision as to the specific type of digital data and
media format required to support the defense system program. In addition to the immediate TM
requirements (acquire and/or develop a TM), the project manager should be concerned with the
potential long term engineering and support functions and requirements when procuring the TM.
8.2.7.2.1.1 Raster
Raster data is a binary representation of an image. Raster may be thought of as the electronic
version of a paper document. It contains no intelligence and must be reviewed through human
interpretation. There are two types of raster data, tiled, which is the preferred format, and
untiled. A tiled raster image resembles a two-dimensional grid with each "tile" or set of pixels

250

representing a portion of the image. Text and graphics in raster data formats allow more rapid
and consistent access to the stored images than paper. In addition, raster data formats can be sent
via electronic means to remote sites. Through a difficult process, raster files can also be
converted to digital (word processor or desktop publishing) documents and edited through
manipulation of individual pixels.
A tiled raster image resembles a two-dimensional grid with each "tile" or set of pixels
representing a portion of the image.
With the advent of raster scanning technologies, the ability to convert existing paper TMs to
digital data files has become available. Raster conversion is the easiest and most cost-effective
method for digitizing the existing paper TMs. However, the quality assurance (QA) process by
human interpretation required to verify the data contents may increase costs substantially. In
addition, raster image files require a large amount of memory storage due to their file structure
and contain no additional information other than each tiles position on a grid. Technologies are
evolving that will be able to convert the raster images to other digital forms (such as vector) for
processing, but the project manager should consider other processable data forms first unless the
TMs required are legacy data.
8.2.7.2.1.2 Illustrated Text Data Files
Illustrated text data files provide a dynamic form of source data with two possibilities:

Separated files for text, graphics, alphanumeric and audio/visual data; or

Integrated files consolidating some or all of these different data representations.

Text data files include word processing and desktop publishing applications. Such data files can
provide the source data for multiple data applications that allow creation of standard and custom
documents as well as manipulation of the data for annotate/excerpt or update/maintain purposes.
Illustrated text data files can also import generic text and graphics from other sources that may
be otherwise incompatible. In addition, there are PDLs, sometimes called text presentation
metafiles, which are used to drive output devices such as printers. Finally, project managers may
want to consider the new software products for creating platform-independent neutral data files
that allow users to save information created in a variety of software applications and formats into
a platform-independent file format, which can then be viewed and printed by anyone possessing
the appropriate reader software.
There may be instances when illustrated text data files include more than one format of graphical
data. The project manager must be aware of this possibility and be prepared to develop/modify
the defense system contract requirements accordingly.
8.2.7.2.1.3 Text Format
There are two possible text formats for consideration. They are the ASCII and tagged ASCII or
Standard Generalized Markup Language (SGML). They are described below.

251

ASCII
ASCII was developed as a method of translation for computer processors to interpret
alphanumeric characters and symbols through binary representation. ASCII is the basic
text information used by most word processing applications and contains no formatting
information other than line feed and/or carriage returns. Word processing applications
can import ASCII text from other word processing applications, and some word
processing applications can translate formatted ASCII from other word processing
applications into their own format. This makes ASCII text ideal for most interim
deliverables since it can also be imported into an SGML application where it can be
SGML-tagged to become a CALS-compliant deliverable.
SGML
SGML is defined as "A standard that defines a language for document representation that
formalizes markup and frees it of system and processing dependencies. It provides a
coherent and unambiguous syntax for describing whatever a user chooses to identify
within a document."
In the SGML scheme, the document contains only generic tags identifying such structural
elements as paragraphs, sections, etc., but no typesetting markup. However, SGMLs
tagging of ASCII text is a rather cumbersome proposition and may be best suited for final
data deliverables rather than interim deliverables.
When considering SGML as a deliverable format, the project manager must determine
whether the applicable Document Type Definitions (DTD) and Formatting Output
Specification Instances (FOSI) exist and whether the necessary computer environment is
available and in place to accept the SGML documentation. Any TMs that will be
maintained throughout the life-cycle of a defense system should be delivered in SGML
format.
8.2.7.2.1.4 Graphics and Illustration Formats
The three possible graphics formats for consideration are Computer Graphics Metafile (CGM),
Initial Graphics Exchange Specification (IGES), and raster. These formats are described below.
CGM
CGM data is a two-dimensional vector presentation used primarily for charts, figures, and
simple drawings. Many types of TMs contain illustration data in this category. CGM is
the preferred format for incorporating graphical digital data into TMs.
Graphical
enhancement has been added to the format, including complete integration of tiled
compressed raster.
Application structuring is currently in the process of being added to the CGM format.
Extensions will allow CGM generators to tag "objects" of application significance. It
will therefore serve to meet the needs of leading edge and future applications of hypertext
and hypermedia documents, multimedia documents, IETMs, network-distributed
graphical applications, and graphic object databases. (See Section 9 for a more complete
discussion on CGM).
252

IGES
IGES data is a three-dimensional vector presentation used primarily for engineering
drawings. IGES may be the preferred choice for graphical data if a CAD database was
used as the source. (See Section 9 for a more complete discussion on IGES)
Raster
See 8.2.7.2.1.1 for discussion of raster.
8.2.7.2.1.5 Page Description Language
A Page Description Language (PDL) file is executed by an interpreter that controls a raster
printer or other output device. A PDL can be used to ensure that the composed document
produced by an electronic publishing system (which may impose additional processing
limitations, such as font variations or hyphenation) would produce nearly identical hardcopy
output on the widest possible spectrum of printer devices.
PDLs are currently not standardized, and a Standard Page Description Language (SPDL) is still
being developed.
MIL-STD-1840 requires that a system must provide portability of files
(PostScript or Impress PDL specifications). PDL document image files can be acquired as
interim deliverables or as final deliverables in addition to, but not in place of, other digital data
deliverables developed in accordance with the CALS standards.
8.2.7.2.1.6 Neutral Data Files
Several industry-developed software products for creating platform-independent neutral data
files have recently become available that allow users to save information created in a variety of
software applications and formats, including text, graphics, and spreadsheets, into a platformindependent file format. These files can then be viewed and printed by anyone possessing the
appropriate reader software. Many applications also allow reader-software users to annotate data
and copy information to paste into other word processing programs. The NATO/NATO nations
should consider these applications cautiously since they are not part of the CALS standards.
8.2.7.2.2 Interactive Electronic Technical Manual
An Interactive Electronic Technical Manual (IETM) is a computer-based collection of
information needed for the diagnosis and maintenance of a defense system. It is optically
arranged and formatted for interactive presentation to the end user on an electronic display
system. Unlike other optical systems that display a page of text from a single document, IETMs
present interrelated information from multiple sources tailored to user queries.
An IETM is essentially a hypertext document, which consists of a collection of "interconnected
writings. These interconnections allow a user to browse through a document by selecting points
of interest or hotspots that may be connected to other related text, hotspots, or menus. The user
could then continue to follow along these "paths" to other cross-referenced points in that
collection of writings. This creates a "pageless" document that, depending on the source
database, can contain a collection of information from a variety of sources. Also, rather than

253

limit these documents to pure text, we may incorporate graphics, audio, video, and/or computer
programs into the content of the document, creating what is known as a hypermedia document.
The information in an IETM is visually arranged and formatted for interactive presentation to
the end user on an electronic display system. Unlike other visual systems that display a page of
text from a single document, IETMs present interrelated information from multiple sources,
tailored to user queries in a hypertext format. This hypertext document consists of a collection
of interconnected writings that allow a user to browse through a document by selecting points
of interest or hotspots that may be connected to other related hotspots or menus.
By streamlining access to the desired information and by providing multiple paths to other
related information, the IETM offers a more efficient and more comprehensive method of using
technical information.
Unrestricted by the page-oriented display and the use of sole-source information, the IETM
duplicates on the Personal Computer (PC), the research environment available in a wellequipped multimedia library; displays only the actions appropriate for resolving a specific
problem; provides fault-isolation tables and diagrams; and guides the technician through the
troubleshooting process via a user-friendly query method. IETMs permit the user to locate
information more easily and to present it faster and more comprehensively in a form that requires
much less storage than paper.
Derived from the LSAR and CAD data, the IETM will inherently become an integral part of the
defense system from the outset. Data created throughout the defense systems life-cycle will
contain all of the information needed to create and revise the necessary IETMs for the program.
IETMs require a computer environment with the appropriate presentation systems and software
to invoke them.
8.2.7.2.3 IETM Viability
The project manager should consider whether the TM will ultimately be used in an interactive
computer environment, the IETM. The IETM format offers the user distinct advantages over the
traditional TM.
Some IETM benefits include:

Reduction in the false removal rate of Line Replaceable Units (LRU) or Weapon
Replaceable Assemblies (WRA);
Reduction in troubleshooting time;
Reduction in the TM support costs associated with distribution, management, and
storage;
Allowing training activities to concentrate more on generalized training versus system
specific training.

254

The project manager should first determine whether the end item or defense system program is
currently in the early phases of design, whether the life-cycle requirements for the TM exceed
five years, and whether the Technical Data Package (TDP) or LSAR database is available.
If any of these considerations can be answered "NO," then an IETM is not recommended. If all
considerations can be answered "YES," then a business case analysis should be performed to
determine the economic feasibility of the IETM. If results from this analysis recommend
pursuing an IETM or quality readiness and/or support factors lend adequate credence to the need
for an IETM, development of an IETM should be pursued.
8.2.7.2.4 IETM Development
If IETM development has been selected, the project manager must first determine whether this
effort will be associated with an existing IETM in terms of either the modification of an existing
IETM or the creation of a supplement to an existing IETM. If this is indeed the case, then the
project manager must determine whether an existing infrastructure and display device will be
used in conjunction with the IETM and whether this infrastructure uses a proprietary format. If
all of the above conditions are true, then the final IETM developed should remain in the existing
proprietary format. However, if any of these conditions is not met, then it is advised that the
IETM be developed using the new IETM standards.
8.2.7.3 TM Development
Utilization of existing TMs and legacy data is likely in the development of completely new
systems with similar features. The project manager should be aware that even on completely
new defense system programs, some portion of the TMs might exist in both digital and nondigital formats. This is most relevant when a program is entering the earlier life-cycle phases.
An important point to remember here is that acquisition of the proper level and type of digital
data is most cost effective when defined early in the programs life-cycle.
An important point to remember here is that acquisition of the proper level and type of digital
data is most cost effective when defined early in the programs life-cycle.
8.2.7.3.1 TM Availability
Another consideration the project manager must address is whether existing off-the-shelf TMs
will satisfy the programs TM requirements. If more than 90 percent of the TM conforms to the
technical requirements and supports the maintenance concept of the equipment, the TM may be
used. However, if more than 10 percent of the proposed TM fails to meet the necessary
requirements to support the equipment, a new TM should be developed.
8.2.7.3.1.1 TM Development
Once it has been determined that a TM will satisfy the technical requirements and maintenance
concept of the equipment, the project manager must determine the present format of the TM and
whether change pages and/or a TM supplement will be required. If the "basic" TM si available
in a word processor format, the TM may be delivered in its present format providing that this is

255

mutually compatible with the existing infrastructures. If it is not, the TM should be delivered in
raster format. Also, if change pages and/or a TM supplement will be required in addition to, or
instead of, the "basic" TM, then the development of these items is the same as that required for a
new TM except that the format and style of the newly developed items may remain the same as
the "basic" TM.
If more than 25% of the existing TM is affected by changes, complete revision of the TM is
recommended
The project manager must now determine how well the existing military TMs cover the
maintenance concepts of the equipment. Changes to the hardware configuration or equipment
components of the defense system may impact the accuracy of the TMs information. If more
than 25 percent of the existing TM is affected by these configuration changes, complete revision
of the TM is recommended.
8.2.7.3.1.2 TM Permanent Change Page Development
If less than 25 percent of the TM needs revision, only change pages will be developed.
Once it has been determined that less than 25 percent of the TM needs revision, only change
pages will be developed. The basic TM will be converted to raster if it is not already digitized.
Change page development will follow the same decision path as the development of a new TM,
but the newly created change pages will retain the format and style of the original TM.
8.2.7.3.1.3 TM Update Revision Development
Once it has been determined that more than 25 percent of the TM must be changed, the project
manager must decide how the final product will be delivered. The decision process follows the
same basic path as that stated for a newly developed TM; the difference is the revised TM may
retain the format and style of the original TM.
8.2.7.3.2 New Technical Manual or Complete Revision
8.2.7.3.2.1 Source and Legacy Data Considerations
The project manager must now consider whether any of the TM source data presently exists as
legacy data. Legacy data developed from existing defense systems or from the creation of LSA
data may contain enough information to warrant inclusion into the new defense system program.
For newer defense system programs, this legacy data may exist in both digital and Non digital
formats. If legacy data does exist in a digital format, the project manager should address
life-cycle considerations. If no legacy data is to be procured for the defense systems TMs or no
digital legacy data exists, the project manager should consider whether configuration changes
and/or multiple configurations are anticipated for the end item or defense system.

256

8.2.7.3.2.2 Defense System Configuration Considerations

Configuration differences may play an important part in the acquisition of defense system TMs.
The differences may be as small as printed circuit card modifications or as large as entire
equipment changes. The project manager must determine whether multiple configurations will
exist, and whether different TMs will be procured for each configuration. Another consideration
is whether future changes to the TM are anticipated.
If multiple configurations and/or
configuration changes are anticipated, conversion of the source or legacy data to digital format is
recommended. Specific conversion format may be based on an economic analysis that may
recommend that some paper legacy and source data simply be scanned into a raster format and
other illustrations be recreated/converted to a vector format. If this is not the case, the defense
system program should consider delivery of the TM in raster format for both text and graphics.
8.2.7.3.2.3 Program Life -Cycle Considerations
The project manager must now consider the current phase of the end item or defense system
program and the anticipated requirements for the TMs. If the end item or defense system
program is currently in the later phase(s) of its life-cycle and the TM requirements are
anticipated to be fewer than five years, the need to deliver SGML-formatted TMs is not
recommended, especially since most of the data for the TMs may be in hard copy or proprietary
digital format.
If this is indeed the case, delivery of both review and Final Reproducible Copies (FRC) of the
TMs in a mutually agreeable format is recommended. If the TM requirements are anticipated to
be at least five years and this TM development process is concerned with a TM Update Revision,
SGML-formatted TMs are recommended.
8.2.7.3.2.4 Additional TM Update Revision Decisions
A TM Update Revision may retain the style and format of the original TM. With this in mind,
additional considerations concerning SGML formatting arise. DTDs and FOSIs may exist that
support the modification of the original TM while retaining the original style and format.
If these DTDs do not exist, then the project manager must consider, through economic analysis,
whether it is cost effective to modify or create a DTD and FOSI to satisfy the style and format
requirements of the original TM. If economic analysis determines that it is not practical, it is
recommended that the new TM Update Revision be delivered in a mutually agreeable format for
both text and illustrations.
8.2.7.3.2.5 Conversion of Illustrations
The project manager must now determine, through economic analysis, whether conversion of all
existing illustrations is justified.
Conversion in this case means converting nonvector
illustrations, both source and legacy data that currently exists in raster and hard copy formats,
into a vector format.

257

If it is determined that conversion of all existing nonvector illustrations to a vector format is cost
effective or if no source or legacy illustrations exist, then the recommended solution is to convert
and/or create all applicable illustrations to a vector format such as IGES and/or CGM. If
economic analysis determines that conversion of all existing illustrations is not practical, it is
recommended that only selected source or legacy illustrations (those with a high likelihood of
being revised at a later date) be converted to a vector format. Remaining illustrations should be
delivered in raster format.
To provide maximum proliferation of the preliminary TMs for review, it may be beneficial to
request that these deliverables be provided in a proprietary word processor format with
illustrations in either raster and/or CGM formats only. SGML, IGES, or commercial CAD
should not be used at this point unless it can be demonstrated that the reviewing activities
infrastructure can support display and annotation.
8.2.7.4 Decision Guidelines
Digital delivery options for technical manuals are not mutually exclusive. There will often be
cases when several options will be combined for specific deliverables during a defense system
acquisition. The decision criteria presented in this handbook are intended to aid in selecting the
best options. The following is guidance for applying the criteria to technical manuals.
8.2.7.4.1 Decision #1: Deliverable Options
Technical manual data can be delivered as composed documents, processable files, or interactive
access to the CITIS database. The composed document deliverable option offers the least
flexibility, even in digital form. It is a static, formatted presentation of the manual, which can
only be archived, viewed, and printed after receipt.
Processable files, on the other hand, offer capabilities that are more robust. These files can be
updated or transformed into many different data types.
With appropriate data processing
systems, processable files can support creation of job guides, training documents, and eventual
on-line distribution of selected portions of the data to maintenance personnel. In addition, a
separate indexing mechanism may be needed for either machine or human search or access.
8.2.7.4.1.1 Destination System Constraints on Form
Processable data files are preferable to composed documents, but the presence of both text and
graphics may cause some difficulty because not all presently installed computing equipment and
software can simultaneously process text and embedded graphics.
This issue is rapidly
disappearing. Nonetheless, during the period of intended use, installed hardware and software at
both the contractors site (i.e., the source system) and the users site (i.e., the destination system)
will be the deciding factor as to which form the deliverable may take.
8.2.7.4.1.2 Interim Dual Deliverables
Requirements for technical manual deliverables may include both composed documents in
digital form and processable data files. However, until more advanced user systems are

258

available, it may be necessary to accept a hard copy (paper) technical manual for approval,
reproduction, and distribution, and a digital form of the manual for archiving or update and
maintenance.
When NATO/NATO nations implement more advanced computer systems, processable technical
manual files (with or without composed document image files of the technical manual) should
suffice.
8.2.7.4.2 Decision #2: Forms Options
A technical manual is made up of both text (including narrative and tables) and graphics.
Integrating these elements into a complete technical manual and dealing with user requirements
that are different for interim review and approval than for final delivery may require more than
merely choosing a single optimum form. The project manager may have to choose the
appropriate forms for multiple deliverables (e.g., a document data file consisting of PDL to
support in-process reviews, and processable data files for the final deliverable).
8.2.7.4.2.1 Composed Documents
If composed documents have been selected at decision #1, the forms for technical manual
delivery can be either hard copy (paper or microfilm) or a digital composed document image file.
The digital form of this deliverable consists of composed page images of the full manual. Two
examples of digital composed document files are PDL and raster.
These options offer greater advantages than hard copy in storage, distribution, viewing, and
printing. They also provide slightly more flexibility than hard copy with respect to future data
uses, although their formats will be fixed and unyielding.
PDL and raster provide a
two-dimensional image of each manual page, offering no further updating or processing features
beyond replication. Both hard copy and the digital forms of composed documents complicate
update and maintenance.
8.2.7.4.2.2 Processable Files
If processable files are selected at decision #1, the forms for technical manual delivery can be
either one or more sets of text and graphics files, or an integrated data file that contains text and
graphics in compound data architecture. A particular type of integrated data file is the IETM.
8.2.7.4.2.3 CITIS Interactive Access
Computer screen display is the primary, preferred form for CITIS information delivery.
8.2.7.4.3 Decision #3: Specification and Standard Options
8.2.7.4.3.1 Composed Documents
Technical manuals acquired as composed documents may be acquired in the form of either
camera-ready masters or digital document image files. The intended application may also

259

require an additional indexing mechanism for efficient subsequent processing. Camera-ready

masters should be delivered in accordance with appropriate standard. Digital document image
files in raster form should be acquired in accordance with MIL-R-28002. Conversion systems
for paper copy are in place for converting legacy data to the MIL-R-28002 format.
MIL-R-28002 provides two options: Type I and Type II. Type I raster graphics binary format
consists of Group 4 encoding as defined in FIPS PUB 150(Consultative Committee on
International Telegraphy and Telephony (CCITT) Recommendation T.6).
Type II raster
graphics binary format consists of ASN.1 and CCITT Recommendation T.6 encoding as
specified by the document description presented in the NIST ODA Raster Document Application
Profile.
The term "tiled raster data" refers to drawings that are segmented into several grids of small
blocks containing raster data. These blocks of data are compressed individually. Modifications
to a tiled drawing are easier to control since only those small blocks of data requiring changes
are modified. Storage of document images in a PDL such as PostScript provides an alternative
form. PDL document image files can be acquired as interim deliverables, or as final deliverables
in addition to (but not in place of) processable data files using MIL-STD-1840 and
MIL-M-28001.
8.2.7.4.3.2 Specifications and Standards for Graphics
Graphics data may be in either raster or vector formats. Assuming an adequate scanning
resolution, raster provides nearly exact fidelity for illustrations. Vector graphics translates data
between different sending and receiving systems in native forms (this can introduce errors, even
when an intermediate, neutral format is agreed on).
For example, a line expressed as a series of pixels connecting a pair of end points, versus a line
expressed as an origin, direction, and length.
Vector representations are easily edited,
maintained, and updated. Vector representations also generally have the advantage of much
smaller file size, even when the raster bit-map image has been compressed using an algorithm
such as that specified by MIL-R-28002.
Nevertheless, raster graphic illustrations are frequently encountered because scanning remains
the only practical way of converting a legacy of hardcopy drawings into digital data. Despite the
quality limitations of raster data, the hardcopy legacy data requires supporting both raster and
vector formats for graphics.
8.2.7.4.3.3 Specifications for Vector Graphics
There are two choices of standards to consider for vector graphics:

MIL-D-28003 for CGM

MIL-D-28000 for IGES

For technical manuals, CGM is the preferred option but IGES can be used. Extensions to the
standard to allow translations of native CAD data into CGM are still being developed. If
technical manual illustrations are being derived directly from design data, then system
260

limitations may constrain the choice of delivery standard. In selecting the appropriate option, the
project manager should recognize the potential problems created by multiple translation steps
(e.g., unique CAD system to IGES to CGM). MIL-D-28003 specifies an Application Profile
(AP) with two options: Level I for publication quality data, and Level II for draft quality data.
Uncompressed raster data can be included in a CGM file, but MIL-D-28003 should only be used
where the predominant form of the graphics information is vector. When IGES is used for
technical manual illustrations, the Class I Technical Illustration subset is appropriate. Data
would be delivered in ASCII, as specified by MIL-D-28000.
8.2.7.4.3.4 Processable Text
Processable text data files should be acquired in accordance with MIL-M-28001, which
implements the SGML. An SGML Document Type Definition (DTD) and Formatting Output
Specification Instance (FOSI) created in accordance with the provisions of MIL-M-28001 or
AECMA 1000 D should be used to meet the document structure and format requirements of the
technical manual. The project manager may be required to fund development of a unique DTD
or FOSI. A more sensible approach would be to make use of previously developed DTDs
8.2.7.4.4 Decision #4: Digital delivery mode options
Physical media is currently the only economical option for the delivery of large document image
files or processable data files. While telecommunications bulk transfer of these files may be
possible, it is usually not an economical option because of the large volume of data contained in
these files, particularly the raster document image and raster graphics files.
When CITIS interactive access to a contractors technical manual database is chosen, then
telecommunications are warranted as a delivery mode for deliverables. Security aspects will also
affect the selection of delivery method.
8.2.7.4.4.1 Magnetic Tape
The standard physical media option is magnetic tape. The mature, stable, non-proprietary
standard that MIL-STD-1840 requires for magnetic tape supports most originating and
destination systems.
8.2.7.4.4.2 Floppy Disk
The preferred physical media option for small files is 3.5 inch, 1.44-megabyte floppy disk. Like
magnetic tape, floppy disk is a mature, stable technology that is usually available at all sending
and destination systems.
8.2.7.4.4.3 Optical Disk
Optical disk or CD-ROM will be alternative physical media options in the future, and are
generally well suited for data archiving because they can accommodate very large volumes of
data quite efficiently.

261

8.2.7.4.5 Digital Deliverable Summary

Selection of the options at each node of the Technical Manuals decision template should be
aligned to the needs of the organizations responsible for technical manual publication and
maintenance within each military department.
Processable data files should be the deliverable of choice when the Government assumes the
responsibility for technical manual update and maintenance.
However, requirements for interim deliverables that are provided only for review and approval
(verification) may be evaluated differently than are requirements for final deliverables. Delivery
of processable data is less important when the principal applications are view and annotate, than
when the intended applications are update/maintain and process/transform.
Consequently,
document image files may be more appropriate early in the life-cycle of the program; however,
processable data files should be the deliverable of choice when the Government assumes the
responsibility for technical manual update and maintenance.
8.2.7.4.5.1 Example - Delivery of Digital Data as Processable Files
Selection options for technical manuals may be processable technical manual files composed of:

SGML text files in accordance with MIL-M-28001 and MIL-STD-1840,

Raster graphics files in accordance with MIL-R-28002, Type I and MIL-STD-1840, and
Vector graphics files in accordance with MIL-D-28003 and MIL-STD-1840.

8.2.7.5 Validation and Verification

8.2.7.5.1 Contractor Validation
The contractor should be required to validate that the delivered TM conforms to the contractual
requirements. Specific validation agenda should be provided in the contractors validation plan
and associated documentation.
8.2.7.5.2 NATO/NATO Nations Verification
The acceptance of CALS digital data products, either delivered on physical media or by CITIS,
is different in several ways from the acceptance of comparable paper data products. The
following paragraphs provide details on the acceptance of digital data products.
8.2.7.5.2.1 Digital Data Acceptance
The unique aspect of CALS digital data deliverables is that they will be subject to inspection and
acceptance on several levels. The lowest level of acceptance is the data content and format. The
acceptance process at this level is identical to acceptance of the data product provided on paper.
This level of acceptance will be accomplished by viewing the data either through use of
computer video screen or by viewing a paper printout of the data product.

262

The next level of acceptance is adherence to the specified CALS data exchange format. This
will usually be compliant with the CALS standards or other national or international data
exchange standards. Automated tools may aid this level of acceptance. The next level of
acceptance is applied to the digital data format, such as MIL-STD-1840, if it has been specified.
Again, automated tools may be used to verify compliance. Other formatting requirements may
be subject to inspection and acceptance including EDIFACT format, when specified.
Finally, the physical media may have acceptance criteria to be applied. This level of acceptance
will not be used if data has been formally delivered by the CITIS. The means of inspection to be
used should be provided to the contractor as soon as these means have been determined. Any or
all levels of acceptance may be performed at the contractors facility or at the NATO/NATO
nations facility, as required. In addition to digital data acceptance, CITIS requires additional
acceptance requirements to be applied.

263

9.0 SECURITY
9.1 What is Information Security
9.1.1 The Environment
Organizations today, connected to extensive networks and global communications, are realizing
that achieving enterprise-wide information security is a complex but necessary task. Users have
become critically dependent on information, and on the systems and networks used to provide
access to this information. As this dependency grows, the need for increased connectivity and
inter-connectivity amongst the many diverse government and private sector systems becomes
ever more important. Furthermore, the incredible sophistication and speed of evolution of the
emerging information technologies being offered by industry create an insatiable desire by users
to employ these emerging technologies. At the same time, user organizations are concerned
about protecting classified and sensitive information, about ensuring the integrity and
authenticity of the information, and about controlling access to the information and to the
systems and networks that process and transport this information. They are also concerned about
detecting and reacting to malicious acts that could result in a temporary or sustained loss of
service. As time goes on criminals, hackers, competitors, and other threats will gain access to
more sophisticated capabilities to break into, exploit, or disrupt, information infrastructures.
Information systems security and assurance, then, cannot be viewed as a point in time. It is in
fact achieved through a process of awareness, readiness, and vigilance.
9.1.2 Types of Security
Within this environment, security consists of two broad areas; those security measures defined
within the requirements of a particular contract and defined by the acquiring organization and its
sponsoring governmental entity and those actions taken by organizations to achieve routine
information assurance.
9.1.2.1 Regulatory Requirements
Security requirements that are typically called out in contracting actions are well defined within
existing and emerging policies, regulations, and requirements. These are cited by the sponsoring
governmental entity. Emerging regulations can often be found posted to a particular sponsoring
agencys Web site or on the Web site for that governmental body responsible for security of the
affected area.
9.1.2.2 Information Assurance
Information Assurance for enterprise-wide information systems, is a vital requirement of every
commercial CIO and senior government IT professional for day to day operation. Information
Assurance enables connectivity in a safe manner, which makes companies and agencies more
productive in this information age and meets the need for secure interoperability with our Allied
and Coalition partners. This section concentrates on Information Assurance activities applicable
to all organizations.

264

9.2 What Needs to be Considered?

To help focus the analysis of security solutions, users needs have been consolidated into four
major requirement categories. This allows related requirements to be discussed together and it
helps to ensure that common solutions are considered for similar problems.
9.2.1 System Security Methodology
A Framework should be developed that presents a systematic set of inter-related processes for
addressing a users security needs.
Consideration of mission needs, relevant policies and
regulations, and a projection of threats to the systems and information all contribute to an
organizational security policy.
The Framework then recognizes that an effective security
solution to satisfy this security policy is most often realized through a balance of technical and
non-technical countermeasures. The Framework also recognizes that it is usually likely that
practical solutions will not completely satisfy the security policy, so a risk management
methodology should be applied in making decisions about the fielding and operation of available
solution alternatives. A structure for risk assessment should be developed, supporting the risk
management methodology. This then forms the basis for the certification and accreditation
process (recognized as a risk management decision).
The need for extending this risk
management methodology beyond deployment should be developed to ensure that the final
system continues to offer the intended security features and protections.
9.2.2 Technical Security Countermeasures
A Framework should be developed that considers concepts and technologies that form the
foundation for technical countermeasures available to develop an effective network security
solution. The specific areas to be considered include the following:
9.2.2.1 Fundamental Security Services
Fundamental Security Services are those services that are implemented to provide the protection
necessary to secure information and system resources. These services include access control,
confidentiality, integrity, availability, and non-repudiation. These are realized by the application
of security technologies within various system components.
9.2.2.2 Security Technologies
Security Technologies introduces technical countermeasures.
Typical technical security
countermeasures include intrusion detection/prevention, virus scanners, data link and network
layer encryptors, security protocols, and tokens. These technologies provide the underpinnings
for the framework recommendation guidance.
9.2.2.3 Robustness Strategy
Robustness Strategy
security mechanisms
value of information
direct proportion to

provides a philosophy and initial guidance for selecting the strength of

and the security assurance provisions that may be needed for a particular
and potential threat level. Robustness of a security solution needs to be in
the value of, and the threats to, what is being protected. A strategy is
265

described for measuring and assessing the need for various levels of robustness for technical (and
selected non-technical) security countermeasures.
9.2.2.4 Interoperability Framework
Interoperability Framework strongly advocates the use of compatible and interoperable security
solutions. This is needed to ensure that as security solutions are added to the communitys
Information Technology environment, that the existing interoperability lines are not broken. The
best path for achieving this is to recommend solutions based on industry standards or de facto
standards. The Framework recognizes that emerging information and security technologies are
often fielded prior to the adoption of interoperability standards. The users desire to use these
emerging technologies sometimes requires acceptance of vendor-unique or proprietary solutions.
In these cases, the Framework advocates a migration path towards standards-based solutions, as
they become available.
9.2.2.5 Security Management Infrastructure Considerations
Security Management Infrastructure Considerations address the need for SMI capabilities to
accompany the use of technical security countermeasures, placing demands on network users and
administrators. It is important that consideration be given to the needs and demands placed on
network users and operators by an SMI within the context of any potential network security
solution.
9.2.3 Security Solutions Framework
9.2.3.1 Requirement Category Guidance
Requirement Category Guidance addresses each of the requirement categories, one by one. For
each category, the Framework defines user requirements; both current and those anticipated
based on emerging technology trends. It considers applicable potential threats and identifies
potential countermeasures articulated as security requirements for that category.
Currently
available security technologies for addressing each requirement are described and compared.
Where appropriate, preferred solution(s) is (are) identified and characterized in terms of features
and assurances.
9.2.3.2 Security Management Infrastructure Considerations
Security Management Infrastructure Considerations emphasize the importance of the Security
Management Infrastructure, and provide a description of the major SMI services, followed by an
in-depth characterization of processes, requirements, potential attacks, and countermeasures that
are available for each SMI service. The SMI discussion concludes with recommendations for the
features needed to achieve three assurance levels.
9.2.3.3 Aggregated Solution
An Aggregated Solution recognizes that the needs of most users are reflected not by any one of
the four requirement categories, but by some combinations of them. The Framework recognizes

266

that a means is needed to develop a solution for logical aggregations of the recommendations for
the individual categories.
9.2.4 Technology Characterization
The recommendations for the best technologies to address each requirement category and case
are summarized in the framework. This identifies the type of features and assurance levels that
are recommended overall for a particular technology area. If existing technology needed to
mitigate the threat at a sufficient level is not available, the need is considered a gap in technology
for this customer requirement category. These gaps are identified in the appropriate technology
assessment within the relevant Framework guidance sections.

267

10.0 CONTRACTING
10.1 Introduction
This section provides sample generic CALS Statement of Work (SOW) language and CALS
source selection criteria to assist the acquisition manager in the implementation of CALS for a
Project.
10.2 How to contract for CALS - Sample Statement of Work Language and Source
Selection Criteria
10.3 Statement of Work Language
This Generic Statement of Work (SOW) provides sample language to assist in the
implementation of Continuous Acquisition and Life-cycle Support (CALS). The content within
each sample paragraph should be tailored for each application. This CALS-related language
should be used in developing the functional requirements within each applicable section of the
Request For Proposal (RFP) or Request for Quotation (RFQ) SOW. A more detailed sample
SOW for development of a CITIS is contained in section 5.
Text appearing as [ times roman italics] in the following paragraphs is provided as the language
that would be used in the actual SOW. Text appearing as [SMALL CAPS] within the actual SOW
text indicates information input by program managers relevant to their programs.
10.3.1 Scope
The contractor shall establish a digital technical information (TI) system to provide automation
and integration of the generation, delivery, and uses of [P ROGRAM NAME] technical information
over the ["DEFENSE SYSTEM" OR "EQUIPMENT"] life-cycle. Unless otherwise specified within
the contract, all, or any portion of, the technical information (TI) specified herein shall be
developed in a digital form compatible with requirements stated herein. Unless specifically
stated herein, the following requirements do not replace or amend requirements for delivery of
TI in non-digital forms specified elsewhere in the contract.
10.3.2 Specific Requirements
The contractor shall implement a CALS Program that will achieve the following objectives:

Integrate contractor technical information systems and processes;

Authorize NATO/NATO nations access to the contractor database(s);
Deliver technical information in digital forms.

10.3.3 CALS Implementation Plan

The contractor shall develop and maintain a current, comprehensive and detailed CALS
Implementation Plan (CALSIP) outlining the procedures to be used to accomplish the CALS
268

requirements defined in [Section X.X] of this Statement Of Work (SOW). The CALSIP shall
address capabilities for automating the access and retrieval of technical data, and provide for
digital exchange and integration between the engineering, manufacturing, logistics, and other
functional areas as appropriate to this acquisition phase of the Program.
The CALSIP shall address, as a minimum, the following:
CALS support hardware and software architecture, reference documents, and points of contact.

Contractors approach and experience in creation, management, use, and exchange of

digital information.
Contractors capabilities for integrating applications and databases.
Procedures to improve product quality and eliminate data redundancy.
Proposed CITIS on-line access capabilities.
Information system and relationships with NATO/NATO nations receiving systems.
Outline of proposed actions and capabilities to be pursued in subsequent life-cycle
phases.
Telecommunications data protection and integrity, including system security.

10.3.4 CALS Approach

The contractor shall define a specific CALS implementation objective and strategy, taking into
consideration technical constraints, quality and cost guidelines and the NATO/Government
CALS Concept of Operations (NCoO) established by the service acquisition manager. This
strategy shall be supported by necessary trade studies, and shall describe the framework for
CALS implementation activities to be accomplished during each phase of [P ROGRAM NAME]
system development. The strategy shall define how the principles of Concurrent Engineering
(CE) will be applied, identify the critical enablers for CE (i.e., integrated database), and provide
details on how Program risk and costs will be reduced and product quality improved through CE
and CALS initiatives. The implementation strategy shall serve as a guide in developing
contractual requirements for later Program acquisition phases. The CALSIP shall be updated
every [DAYS] throughout the life of the contract. The CALSIP updates shall define
implementation plans for the upcoming period in greater detail, resolve outstanding strategy
issues, respond to strategic and technology changes, and recommend specific alternative
approaches for continuation of CALS in the next phase.
10.3.5 Database Architecture/System Tradeoffs
The contractor plan shall provide a cost effective method of managing the utilization of the
contractor set of automated data processing systems and applications which support specific
weapon system technical database(s) such that appropriate configuration and version control of
technical information is maintained, while providing current data for design, engineering
analysis, manufacturing, and product support planning. The contractor shall conduct appropriate
tradeoffs/studies/analyzes to support determination of the CALS implementation strategy. The
status of these studies shall be reviewed at appropriate Program management, design, and ILS

269

reviews, and the results documented as part of the CALSIP.

include:[Examples only; final determination is Program specific]

Candidates for such studies

Improved alternate data generation and delivery modes.

Digital data delivery vs. on-line access.
Identification and elimination of unnecessary CDRL items.
Identification of CDRL items for interactive, on-line review.
Analysis of telecommunication alternatives.
Functional integration cost/benefit studies.
Cost effectiveness of contractor interim.

CALS support [PARTICULARLY IN AREA S WHERE INFRASTRUCTURE CAPABILITY LIMITATIONS CAN

BE OVERCOME THROUGH USE OF HARDWARE/SOFTWARE LEASED FROM THE CONTRACTOR].
10.3.6 CALS Standards Conformance Test
The contractor shall include in the CALSIP plans to demonstrate the exchange of digital
deliverables using the CALS standard formats, in accordance with the requirements of [ XXX ]
and references [ XXX ]. This shall be accomplished through testing provided by the
NATO/NATO nations or an industrial organization(s) chartered to perform such conformance
test. Deliverables should pass a first article test on all formats to ensure conformance to the
CALS specifications.
10.3.7 Security
The contractor shall establish a security system and enforce data protection and integrity
standards. System security engineering principles as outlined in [ XXX ] shall be used. Controls
to prevent unauthorized access shall be established and detailed in the CALSIP. The plan shall
be based on the results of documented data protection and integrity, threat and vulnerability
analysis, risk assessments, and tradeoff analyzes. Vulnerabilities that remain after security
system design shall be identified. The plan shall include disaster recovery provisions. Security
requirements that must be complied with by NATO/NATO nations personnel will be identified to
the NATO/NATO nations in the security section of the CALSIP. Any peculiar software that must
be resident on NATO/NATO nations access terminals will be provided and maintained by the
contractor. Information requiring special security provisions such as classified data, critical
technology and sensitive data, such as proprietary, competition or liability sensitive data, will be
partitioned to minimize the volume of information requiring specialized handling, to provide
classification at the lowest classification level, and to control access. Sensitive data, in this
context, includes but is not limited to, CDRL data items marked with one or more of the
following: an export control warning notice, restrictive distribution statement, and/or a
proprietary legend. Encryption of classified data or sensitive military data shall be stipulated by
the CDRL and on an as-required basis in accordance with procedures established by the [ XXX ].
Such information shall be identified to prevent inadvertent disclosure and retention of security
identification for printouts of accessed information. The contractor shall pay particular attention
to unclassified items of information, which, taken together, can infer classified information. The
contractor shall maintain configuration control of the security system and trusted system

270

components. The contractor shall conduct a test and evaluation of the system and periodic
inspections to ensure compliance. The NATO/NATO nations shall retain the right to conduct
announced and unannounced inspections by security specialists at any time to review, audit, and
account for classified materials.
10.3.8 Program Assessment and Control
The CALSIP shall describe the procedures and controls by which the contractor and the
NATO/NATO nations will evaluate the status and effectiveness of CALS. The implementation
of CALS will be a subject of review at program, design, and ILS reviews.
10.3.9 Post Award CALS Program Orientation Conference
The prime contractor shall host a post award CALS program orientation conference to be
scheduled no later than [NUMBER] of days after contract award. A representative from the
[PROGRAM NAME] program office shall chair this conference. Major prime contractor teaming
partners/subcontractors shall attend. The agenda for this conference shall be approved by the
[PROGRAM NAME] program office. The purpose of this CALS meeting is to clarify the NCoO and
have the contractor present to the NATO/NATO nations their plans for on-line access, if
required, exchange, and delivery of digital data.
10.3.10 Government Furnished Information
The contractor CALSIP shall describe the Government Furnished Information (GFI) the
contractor expects to receive from the NATO/NATO nations. The list of GFI the NATO/NATO
nations plans to provide is included in attachment/exhibit [NUMBER]. GFI shall be provided in
both digital and hard copy formats. The GCO will define infrastructure capabilities to receive
and use various types of digital data and technical information. The contractor shall use this GFI
with contractor generated data.
10.3.11 Contractor Integrated Technical Information Services)
The contractor shall propose ["DEVELOP" IF CITIS IS REQUIRED] a program composed of
procedures, processes, specifications, and software applications for the integration, storage,
exchange, and/or on-line sharing of data with the NATO/NATO nations. These technical data
and database(s) and functional application capabilities provided within the contractors system
shall be referred to as Contractor Integrated Technical Information Services (CITIS). This CITIS
shall be developed in accordance with [ XXX ], and the following. The contractor shall propose
["DEVELOP" IF CITIS IS REQUIRED] a Technical Information (TI) and program management
architecture, with a functional and hierarchical indexing system to:

Manage configuration of the entire TI and planning databases.

Integrate planning information into its respective TI source database.
Trace configuration changes from design to logistics products and vice versa.

The contractor shall propose how he will ["IS REQUIRED TO" IF CITIS IS REQUIRED ] establish a
link among logistics, design, engineering, and manufacturing data and functional processes to:
271

Facilitate the interchange and exchange of technical information.

Integrate technical data and database(s) to support the design, manufacturing and support
processes and allow for timely access by authorized NATO/NATO nations activities.
Provide an integrated, shared data environment, consisting of integrated databases,
analysis tools, and engineering processes designed to utilize digital TI.
Provide for the generation, storage, indexing, distribution, and delivery of integrated
acquisition and logistics information products.

In the selection of analytical tools, the contractor shall maximize the use of previously developed
or off-the-shelf software. These software tools shall be compatible with NATO/NATO nations
hardware/software systems stated in the NCoO, unless contractor developed, unique software
solutions are demonstrated to be more cost effective. The contractors telecommunications
solution for CITIS shall comply with NATO/NATO nations Interconnect Profile.
10.3.12 Data Element Dictionary [If CITIS is required.]
A general data element dictionary shall be developed so that identical data elements are
addressable by the computer as the same data element. Changes to any duplicate data element
shall be effected throughout all databases. A similar methodology shall be developed for
graphics and large textual entities to ensure that changes to the source graphic correctly flags the
necessity for change to all dependent graphic/textual entities derived from the source graphic.
The contractor shall use existing data dictionaries as guidance in constructing the [P ROGRAM]
data dictionary.
10.3.13 Engineering Data (Graphic and Text Files)
Any data, either NATO/NATO nations, contractor, or vendor, that contains engineering
definition or guidance on material items (components), equipment system practices, methods,
and/or processes relating to the design, manufacture, acquisition, test, inspection shall be
submitted in digital form in accordance with [ XXX ] and compatible with the NATO/NATO
nations data repository and receiving systems stated in the NCoO.
10.3.14 Automation and Functional Integration
The contractor should use computer-aided design, engineering, and manufacturing methods
(CAD/CAE/CAM) to support design integration with manufacturing planning and logistic
support system development. These software tools shall be compatible with the NATO/NATO
nations hardware/software systems stated in the NCoO, unless contractor developed, unique
software solutions are demonstrated to be more cost effective. An integrated set of ADP systems
and applications will be used by the contractor team to enter, update, manage, and retrieve data
from specific [P ROGRAM] technical database(s).
10.3.15 Reliability and Maintainability Automation
The contractor shall employ automated tools for performing Reliability and Maintainability
(R&M) tasks. The contractor shall integrate these R&M tools with other CAE tools. These tools
272

may stand-alone with no direct access to the CAE database; reside in the CAE system and
interface with the evolving design; or, reside on the CAE system and be automatically invoked to
support design decisions. The R&M methods and tools used by the contractor shall include, as a
minimum:

Automated R&M analysis procedures coupled to parts libraries and to material

characteristics databases.
Automated R&M synthesis based on design rules and lessons learned from prior design
experience and field use.
Fully characterized (tested and validated) component part performance and R&M
characteristic databases.
Design decision traceability.

10.3.16 R&M-Logistic Support Analysis Record Integration

The contractor shall establish an automated link to satisfy Logistic Support Analysis Record
(LSAR) documentation requirements for initial and updated reliability and maintainability
(R&M) information. Algorithms or transformations that must be applied to R&M source data
elements to conform to LSAR documentation requirements shall be documented. Traceability
between the LSAR and individual R&M data sources, and the preservation of appropriate data
flows while maintaining established LSAR data element relationships and interdependencies,
shall be clearly demonstrated.
10.3.17 LSAR Data Automation
The contractor shall establish and maintain a validated LSAR automated data processing system
capable of input, storage, and retrieval of LSAR data in accordance with [XXX]. The contractor
may use an internally developed and NATO/NATO nations validated LSAR automated data
processing system, or independently developed and NATO/NATO nations validated LSAR
automated data processing system. The contractor shall partition LSAR working data for
in-process reviews and maintain these files separate from NATO/NATO nations approved LSAR
data. The LSAR version containing the submitted data shall be the LSAR that has been
subjected to internal contractor review procedures and is pending NATO/NATO nations review
and approval. The LSAR working data shall be updated in accordance with the schedule in the
LSA plan regardless of the approval status of the working datas content since the last update.
Upon NATO/NATO nations approval, LSAR working data shall be transferred to the
NATO/NATO nations approved LSAR. All NATO/NATO nations directed changes resulting
from the LSAR data shall be cumulative of all approved LSAR data. Delivery of LSAR data
shall be in accordance with the CDRL.
10.3.18 Reliability Centered Maintenance and Age Exploration Automation
The contractor shall develop an automated system to maintain a complete Reliability Centered
Maintenance (RCM) audit trail throughout the [PROGRAM NAME] life-cycle. This audit trail will
permit traceability of preventive maintenance tasks back to specific engineering failure modes
listed in the LSAR. The automated RCM analysis process must have the capability of delivering
results digitally and through an interactive electronic interface with the LSAR database. The
273

contractor shall utilize the RCM automated worksheet process or a contractor developed RCM
automated process with the capability of automatically transferring compatible data to the
NATO/NATO nations RCM software. The automated RCM analysis data/work-sheets must be
delivered to the NATO/NATO nations in accordance with the CDRL.
The contractor will develop an Age Exploration (AE) database for the storage and analysis of
in-service/operational age-reliability data that shall be used to support the RCM analysis
process. The AE database shall be integrated digitally and have an interactive electronic
interface with the RCM automated process.
10.3.19 Level of Repair Analysis
The contractor shall employ an automated system to perform Level of Repair Analysis (LORA) in
accordance with the requirements specified in [ XXX]. The contractor shall establish a database
as a repository for LORA input data and LORA output report files generated by execution of the
LORA model software. The LORA database will be integrated with the automated LSAR
database to maintain traceability of LSA data used as input to the LORA. The output results of
the LORA shall be documented in the LSAR for development of the LSA-024 maintenance plan
report. Approved LORA input data files and output reports shall be delivered in accordance
with CDRL specified delivery mode (i.e., deliverable digital media or on-line access/retrieval).
10.3.20 Diagnostics
The source of diagnostic information will reside in logistics engineering databases offering data
exchange in neutral formats. Software shall be developed to provide for automated interface
with in-service performance and maintenance data collection processes and to provide feedback
concerning successes and failures in the fault isolation process to the [P ROGRAM] system
designer. Diagnostic systems that learn from experience and which have the capability to
update a knowledge-based diagnostic database to optimize the fault isolation process or to
improve system design are to be used to the fullest extent possible.
10.3.21 Management Information Tools
The contractor shall establish an on-line direct access capability for recording, planning,
scheduling, and reporting status of program requirements. This shall provide visibility of the
contractors performance, highlight potential problems, and provide schedule compatibility
checks to ensure integration of functional activities. This on-line capability shall identify change
impacts on related areas of logistic support, design and manufacturing, and provide the status of
program deliverables.
10.3.22 Technical Manuals
The contractor shall provide for computer assisted generation of technical manuals. This data is
to be derived, to the maximum extent possible, from integrated digital data files, e.g.,
CAD/Engineering Database/LSAR.
This data shall be provided in accordance with
(Service-unique specifications and TM development guidance or other TM SOW requirements).

274

10.3.23 Supply Support

The contractor shall maintain spare parts identification consistent with the approved
configuration baseline and allow for on-line assessment of the impact to spare parts
requirements during analysis of design alternatives. The contractor shall provide provisioning
technical documentation in accordance with [ XXX ] to facilitate automated ordering, supply
management, and distribution, and should provide on-line identification of spares, repair parts,
and source/maintenance/recoverability coding. This data shall be provided IAW (Service-unique
specifications and TM/TO development guidance or other TM/TO SOW requirement).
10.3.24 Facilities Data
The contractor shall provide facilities data in digital form in accordance with [ XXX ] consistent
with data derived from the LSAR database. Engineering drawings and specifications shall be
provided in accordance with [ XXX ].
10.3.25 Training
Training data should be developed in accordance with [xxx]. The LSAR database shall provide
source data to program software for producing output reports and instructional materials.
Authorized system software shall be in accordance with NCoO specified requirements.
10.4 Source Selection Criteria
A key process for creating a Solicitation (i.e., Request for Proposal [RFP] or Request for Quote
[RFQ]) is the data call. This process identifies and develops specific NATO/NATO nations
requirements for data (Contract Data Requirements List [CDRL]).
CALS related issues are made manifest during the data call via the NATO/NATO nations
Concept of Operation (NCoO) questionnaire responses. Only then can CALS be taken beyond a
strategy to become a value added reality. CALS must continue to be emphasized during the
contract development phase, as incentives for CALS are incorporated into both the draft contract
and the Source Selection Plan, to guide the follow-on proposal evaluation phase.
10.4.1 Source Selection for CALS
The following elements aid in CALS-presence throughout source selection:

Ensure that technical requirements facilitate CALS utilization;

Encourage industry identification of CALS alternatives;
Provide positive incentives in Evaluation Criteria section;
Make CALS an explicit element of Source Selection Plan;
Provide/ensure CALS awareness of Source Selection Evaluation Board.

275

10.5 Guidelines and Sample Clauses for Electronic Data Interchange

10.5.1 Introduction
The state of development of EDI, although maturing in terms of implementation and message
standards, still requires flexible tools and guidelines to maintain the highest growth momentum.
The objective of the sample clauses offered in this section is to provide both Ministry of Defense
and NATO Agency with a concrete and pragmatic tool which addresses the basic legal and
contractual issues raised by the use of EDI. Those sample clauses will appear in the following
paragraphs as [ Times Roman Italics].
The authoritative source for clauses to be included in contractual documents is AC/313.
The authoritative source for clauses to be included in contractual documents is AC/313. That
committee has published the guidelines from which the following samples are drawn. The
following are examples only, offered to assist in understanding the issues involved. The ones
implementing such agreements should refer to the latest AC/313 guideline document.
These examples are offered for application in situations where a signed document needs to be
established between a ministry or an agency and its trading partners with respect to data that are
going to be electronically exchanged, but they do not apply to database access. Ministries and
agencies may consider it appropriate to envelop the electronic interchange of data within a
legally binding framework, so that the obligations of the signatories towards each other are
clearly seen to be enforceable. Some nations, on the other hand, may choose not to use a legally
enforceable, signed, format to set down these obligations; they may choose instead to lay down
the principles concerned in law or regulations, depending on the characteristics of their legal
code. Nevertheless, extracts from these sample clauses may be appropriate for use in the
development of such laws and regulations.
Different legal issues have been identified with the use of Electronic Data Interchange for the
purposes of commercial transactions or similar commercially sensitive transactions, or other data
exchange with legal consequences. Although these issues do not prevent the use of Electronic
Data Interchange, they create legal uncertainty. One of the most pragmatic ways to address these
issues is to resolve them, to the extend possible, in a legal framework. The objective of these
sample clauses is to provide the Electronic Data Interchange users with a tool that addresses
these legal issues. In general, the samples are provided for bilateral relationship. However, the
samples can also be used for multilateral agreements and/or can be adopted by a community of
users.
The legal provisions should be signed by the parties to show that they intend to enter into an
agreement. The samples provided address all issues to cover an EDI relationship between
parties. Subsequent rights and obligations and the legal consequences of the use of EDI between
the parties will derive from the Agreement thus formed.
Legal consequences of the use of EDI between parties will derive from the signed Agreement

276

The sample clauses are intended to cover all the subjects to be addressed under an electronic data
interchange relationship, including electronic mail. The guidelines and sample clauses cover a
wide range of electronic exchange of data, from electronic mail to the ultimate Electronic Data
Interchange, which is the transfer of data from computer to computer without human
involvement.
The transfers involved can vary from commercial trade transactions under an Integrated Logistic
Support program (e.g., ordering spare parts from contractor stock) to exchange of proprietary
data when developing a weapon system data base.
Some of the clauses include general references to technical matters. These technical matters
require further specifications. They are often found in so-called user manual. The samples
need to be completed by a User Manual that will include the necessary technical specifications as
determined by the parties. The User Manual is left to the Electronic Data Interchange users to
develop, draft and/or agree according to their needs.
10.5.2 Agreement First Page
The first page should incorporate sufficient information to provide a capsule of the most salient
points of the Agreement at a glance. Such items of information may include:

Reference number
Identification of the parties to the agreement, their representatives and their addresses
Security classification

The data exchanged can be of different nature. It can be of a commercial nature or of an

administrative one. In some cases, the exchange of technical information of a confidential nature
can be involved. The whereases can elaborate on the nature of the transactions involved. In
case of a dispute, these considerations might be helpful.
Sample Clauses
ELECTRONIC DATA INTERCHANGE AGREEMENT
(including Electronic Mail)
[Reference Number]
Agreement concluded by and between:
the Minister of Defense of _______________ /NATO Agency
and ___________________________________________________
hereinafter referred to as the parties, now therefore have reached the following
agreement, hereinafter referred to as the Agreement.
10.5.3 Object and Scope
It should be emphasized that the Agreement constituted by the sample clauses only governs
EDI relations between the parties and that it is not intended to govern the substance
transactions that will effectively be carried out using Electronic Data Interchange. The issues
validation and formation of the underlying agreement are covered by the sample clauses
277

the
of
of
on

VALIDITY AND FORMATION OF THE CONTRACT .

Conflicts or inconsistencies between the

agreements involved should be prevented.

Sample Clauses
This Agreement specifies the terms and conditions under which the parties, conducting
transactions by the use of Electronic Data Interchange, operate.
The Agreement consists of the Provisions set out in the following and shall be completed
by a USER MANUAL that is made part of the Agreement.
Unless otherwise agreed by the parties, the provisions of the Agreement are not intended
to govern the contractual obligations arising from the underlying transactions effected by
the use of Electronic Data Interchange, except for the validity and formation of such
transactions as stipulated in clauses VALIDITY AND FORMATION OF CONTRACT
and ADMISSIBILITY IN EVIDENCE OF ELECTRONIC DATA INTERCHANGE
MESSAGES of this agreement.
10.5.4 Definitions
Inserted in this clause are the basic definitions used in the sample clauses. They aim at ensuring
an unambiguous understanding of these terms used in the Agreement.
ACKNOWLEDGMENT OF RECEIPT
As there are different kinds of acknowledgement of receipt of an EDI Message, it is essential to
indicate clearly, which level of acknowledgment is referred to, in order to avoid confusion. This
definition reflects the level chosen within the agreement in particular as it is referred to in clause
PROCESSING AND ACKNOWLEDGMENT OF RECEIPT OF ELECTRON IC DATA
INTERCHANGE MESSAGES.
EDI Message
EDI is based on the use of structured and coded messages, the main characteristic of which is
their ability to be processed by computers and transmitted automatically and without ambiguity.
This definition emphasizes these essential characteristics, which make EDI specific in
comparison with other data exchange such electronic mail.
Sample Clauses
DEFINITIONS
For the purpose of this Agreement, the following terms are defined as follows:
Acknowledgement of receipt: the procedure by which, on receipt of the EDI Message,
the syntax and semantics are checked, and a corresponding acknowledgement is sent by
the receiver.
Authentication: criteria permitting the receiver to verify that it is an authentic document
by sender.

278

Business day: any day except a Saturday, Sunday or any declared public holiday in the
intended place of receipt of an EDI Message as defined in the User Manual.
Data-log : a collection of data transferred that provides a complete historical record of
data interchanged.
Electronic Communications : the communications of digital data by electronic means
such as but not limited to telephone, telefax, computer-to-computer-link.
Electronic Data Interchange (EDI): is the electronic transfer of data, from computer to
computer, using an agreed standard to structure an EDI Message.
EDI Message : a set of segments, structured using an agreed standard, prepared in a
computer readable format and capable of being automatically and unambiguously
processed, as defined in the User Manual.
Electronic Data Interchange Protocol: the protocol specified by the parties hereto as
that governing the requirement of format, structure and transmission of documents and
other communication between the Parties via the Electronic Data Interchange network.
Electronic Mail: the electronic communication between the Parties of textual binary and
graphical data in a non structured format, of a maximum size as specified in the User
Manual.
Electronic Signature : an agreed string of characters identifying the originator of an EDI
or Electronic Mail message.
Functional Acknowledgement: an acknowledgement message of the receiving Partys
computer software application that automatically confirms the receipt of the Electronic
Data Interchange document or Electronic Mail message at the moment of receipt.
Garbled Transmission: an attempted transmission that cannot be decoded by the
receiving Partys host software application and is therefore completely or partially
unreadable.
User Manual : the technical procedures and rules applicable to the transmission of data.
10.5.5 Authenticity of Messages
The parties should provide for the identification of the sender and the receiver together with
means to verify the authenticity of the message.
Sample Clauses
All Electronic Data Interchange or Electronic Mail Messages must identify the sender
and receiver and must include an agreed means of verifying the authenticity of the
message either through a technique used in the message itself or by some other means

279

provided for in the Electronic Data Interchange Protocol, or as specified in the User
Manual.
Simultaneously with the execution of this Agreement, each Party shall furnish to the
other, a list of the individuals authorized by it to send Electronic Data Interchange or
Electronic Mail Messages and the appropriate Electronic Signature and shall update this
list as necessary.
10.5.6 Validity and Formation of Contract
10.5.6.1 Validity of the Contract
This sample clause attempts to emphasize the intention of the parties to form valid and binding
contracts by EDI and to provide proof of this intention to third parties. As such, the provision
provides that parties will not challenge the validity of transactions effected by use of EDI, on the
sole ground of that means.
The law applicable to the data transferred might be different from one country to the other and
the parties may not necessarily be aware of national law restriction on the content of an EDI
Message. It is reasonable to ensure that parties will take care to respect the national legislation
applicable to the content of the EDI Message.
Whenever the data included in an EDI Message received is inconsistent with national law of the
receiver, the obligation on him will be to inform the other party of this inconsistency and he may
then be able to take measure to avoid breach of its own law.
Sample Clauses
The parties bound by the Agreement, expressly waive any rights to contest the validity or
enforceability of a contract, affected by the use of EDI in accordance with the terms and
conditions of the Agreement, or the authenticity of an Electronic Signature on the sole
ground that it was affected by EDI.
The Parties agree not to contest the authenticity admissibility or enforceability of
messages under the provisions of any applicable law relating to whether certain
agreements are in writing and signed by the Party to be bound thereby.
Any Electronic Communications properly transmitted pursuant to this Agreement shall be
considered to be written or in writing. Any such message when containing, or to
which there is affixed, and Electronic Signature shall be deemed to have been signed
and to constitute a true copy when printed from electronic files or records established
and maintained as specified in the clause on DATA-LOG: RECORDING, STORAGE
AND RECONCILIATION OF ELECTRONIC DATA INTERCHANGE MESSAGES.
Each party shall ensure that the content of an EDI Message, sent or received, is consistent
with the law of its own respective country, the application of which could restrict the
content of an EDI Message or limit its use, and shall take all necessary measures to
inform without delay the other Party if such an inconsistency arises.
280

10.5.6.2 Formation of the Contract

The following sample clause is related to the time and place where a contract is concluded or
formed. The determination of the place and time of formation of a contract is important with
regard to the legal consequences it involves. This sample clause implements the reception
rules which ensure that acceptance takes place at the place and at the time of receipt of such
acceptance by the offeror.
Sample Clause
The contract affected by the use of EDI shall be concluded at the time and place where the
EDI Message constituting acceptance of an offer reaches the computer system of the
offeror.
10.5.7 Admissibility in Evidence of EDI Messages
Following clauses are intended to clarify the parties intention and ensure that legally binding
contracts and related EDI process can be proved in the event of a dispute by the records
maintained in conformity with the EDI agreement concluded.
The area of admissibility and evidential value is one where uncertainty is still predominant. As
in most countries legal provisions regarding evidence are not mandatory, specifically in the
commercial area, agreement between parties can be reached on the questions of evidence. By
reaching an agreement between parties, this uncertainty can be partly reduced.
Effecting transactions by EDI as an alternative to paper implies that the EDI Messages will
replace effectively the documents that were exchanged previously on paper. It implies that the
parties can rely on these exchanges of messages to provide the evidence of the facts that have
happened, in the case of a dispute.
Within the boundaries of national laws, especially mandatory law, which may apply and
provided that the parties have respected the provisions of the agreement, these EDI Messages
should be admissible before the courts as evidence and should also be recognized as a means to
provide evidence of the facts that are recorded unless evidence to the contrary is provided.
To be admissible in court the evidence offered should be trustworthy and reliable. Good recordkeeping, acknowledgment, and security provisions are factors that will affect admissibility of
evidence.
Sample Clauses
To the extend permitted by law, the parties hereby agree that in the event of dispute, the
records of EDI Messages, which they have maintained in accordance with the terms of
this Agreement, shall be admissible before Courts and shall constitute evidence of the
facts contained therein unless evidence to the contrary is adduced
Procedures to enable a secure means of archiving shall be detailed in the User Manual.

281

10.5.7.1 Processing and Acknowledgement of Receipt

10.5.7.2 Processing of Electronic Data Interchange Messages
The parties should commit themselves to deal with the EDI Messages they receive in a fixed
time that should be specified in the User Manual. In the case where no time limit has been
decided by the parties, they should process messages as soon as possible after receipt.
This provision is included, not only to ensure commercial efficiency and good business practices,
but also in order to define the contractual rights and obligations of the parties in the event where
a message is not received, is late or contains errors and the contract is thereby frustrated.
10.5.7.3 Acknowledgement of EDI Messages
The acknowledgement of receipt concept has often been misunderstood in particular with regard
to the content of the EDI Message itself.
Different levels of acknowledgement are available. Acknowledgement can be automatically
transmitted at the level of telecommunication network when the message is made available to the
receiver,
It can be automatically sent upon the receipt of the EDI Message at the information system of the
receiver without any verification, so called functional acknowledgement (see clause
DEFINITIONS);
It can be sent after some verification has been achieved;
It can also mean, at some stage, acceptance of the content of the message or confirmation that the
receiver will act on the content of the message.
The minimum level chosen (functional acknowledgment) does more than simply confirm the
receipt. It corresponds to the level where verification of semantics and syntax is achieved and
consists of a response to the EDI Message sent stating that the message has been received and
that the syntax and semantics of the message are correct.
Parties may require other levels of acknowledgement, which in that case should be determined
by them, according to their needs and the appropriate details should be included in the user
manual. In that case distinctive levels of acknowledgement, i.e., acknowledgement of receipt,
acknowledgement of receipt and verification, acknowledgement of receipt, verification and
acceptation, need to be detailed in the user manual for the respective Electronic Data Interchange
message or electronic mail.
A rejection is meant to ensure that the Electronic Data Interchange message sent should not to
have any force or effect. The sending party should be informed of such a rejection in due time as
defined in the user manual.

282

The principle stated in clause PROCESSING AND ACKNOWLEDGEMENT OF RECEIPT OF

ELECTRONIC DATA INTERCHANGE MESSAGES is that an acknowledgement of receipt of
an Electronic Data Interchange message is not required unless requested. However, data
transmissions of a confidential nature or containing classified information need to be
acknowledged in all cases.
Provision may also be made, in the User Manual, for all EDI Messages or for certain categories
of messages (i.e., all ORDER messages) to be automatically checked and acknowledged.
Alternatively, if no specific provision has been made regarding acknowledgement, the
appropriate segment for a request for acknowledgement may be included within a message sent.
Not all messages will require an acknowledgement and the User Manual should clearly
differentiate between those that do and those that do not.
10.5.7.4 Time Limit and Acknowledgement of Receipt Transmission
EDI is characterized notably by an increased reliability due to a reduction in errors, faster and
more accurate information flows and by increased automation of the processing of data.
Acknowledgements contribute to the reliability and accuracy of EDI and time limits are in this
context critical.
The importance of the time limit for sending the acknowledgement derives from the fact that the
EDI Message may not be acted upon, and hence contractual obligations may not be carried out,
until the acknowledgement, when required, has been sent.
One business day is deemed an appropriate time limit in the EDI environment. However, Justin-Time management or other priorities may require more strict adjustment of time, or it may
seem inappropriate or impractical and an extension might be required, in which case the parties
should adjust the time limit and complete the EDI Agreement, as they will agree.
Although clause DEFINITIONS (paragraph above) provides a definition of a business day, it
may prove useful for the parties to specify more precisely the public or other holidays or the time
of availability of the system.
An obligation to send an acknowledgement of an EDI Message is placed on the receiver, who
should not act on the message, which requires an acknowledgement, until such
acknowledgement has been sent.
10.5.7.5 Failure of Receipt of an Acknowledgement
In the case where an acknowledgement is not received by the sender of an EDI Message who has
requested such an acknowledgement, within the applicable time limit, it is reasonable that he is
allowed to assume that there has been a problem with the message or that the receiver does not
want to, or cannot, deal with it and consequently that he should be able to consider such message
as null and void provided he so advises the receiver. This latter condition will be particularly

283

useful in a situation where a problem has occurred with the transmission of the
acknowledgement. Time limits again will be critical.
Alternatively, the parties may determine a recovery procedure for the cases where technical
problems have occurred and the sender of an EDI Message for which an acknowledgement is
required may initiate such kind of recovery procedure if he does not receive the
acknowledgement within the prescribed time limit. The details of such procedure should be
determined in the User Manual.
10.5.7.6 Inability to Send Messages
Due to external circumstances, there may be an inability to transmit electronic communications
from time to time. The parties may agree to exchange messages at such time by other methods
of communication, including tele-copy, tele-facsimile, telephone, or paper.
The legal
implications of such alternative forms of communication should not be affected by the
agreement.
Sample Clauses
EDI Messages shall be processed as soon as possible after receipt, but in any event,
within the time limits specified in the User Manual.
If a message received appears not to be in good order, correct and complete in form, the
recipient Party shall inform the other Party within the time limit as specified in the User
Manual. If the message is rejected, a rejection message shall be sent within the time limit
as specified in the User Manual
Immediately upon receipt of any EDI Message or Electronic Mail message at its receipt
computer, the receiving Partys receipt computer shall automatically transmit a
Functional Acknowledgement in return and additionally the sender may request the
recipient to confirm the receipt of that message.
An acknowledgement of receipt is not required unless requested.
However,
acknowledgement is required for all trade data messages and messages containing
classified data. An acknowledgement of receipt can also be requested by specific
provision included in the User Manual or by express request of the sender in an EDI
Message.
Where an acknowledgement of receipt is required, the receiver of the EDI Message to be
acknowledged shall ensure that the acknowledgement is sent within one business day of
the time of receipt of the EDI Message to be acknowledged, unless an alternative time
limit has been specified in the User Manual. The receiver of an EDI Message requiring
an acknowledgement shall not act upon the content of the EDI Message or further
disclose or use its contents until such acknowledgment is sent.
If the sender does not receive the acknowledgement of receipt within the time limit
applicable, he may, upon giving notification to the receiver to that effect, treat the EDI
Message as null and void as from the expiration of that time limit or initiate an alternative
284

recovery procedure as specified in User Manual, to ensure effective receipt of the

acknowledgement. In case of failure of the recovery procedure, within the time limit, the
EDI Message will definitely be treated as null and void, as from the expiration of that
time limit, upon notification to the receiver.
A Garbled Transmission shall have no force or effect.
10.5.8 Security and Protection of EDI Messages
10.5.8.1 Obligations of Parties
A satisfactory level of security for messages must be ensured to avoid any risks that may be
associated with the exchange of messages by EDI, and such level will depend upon the
importance of the transactions or messages exchanged.
10.5.8.2 NATO Classified Information
For NATO classified information the NATO document C-M(55)15(Final) Security within
North Atlantic Organization provides the necessary security requirements. In addition, national
security regulations might be introduced here.
10.5.8.3 Security Procedure s and Measures
Verification of origin and integrity are stated to be mandatory for any EDI Message as they
constitute a basic level of security. Parties are, however, strongly recommended to agree, where
required, on additional security measures, the degree of which will no doubt depend on the value
and importance of the subject-matter of the messages and the possible security risks in the event
of an unsuccessful exchange of messages.
Control measures should be provided in the user manual, possibly by reference to an agreed
standard, such as specific checks, acknowledgement of receipt, control count, reference number,
identification etc. More elaborate controls may be necessary, in particular when transactions are
important and could mean the use of some specific messages to increase the security such as
those recommended by security experts, or any other available security means or method,
including, as an example, digital signatures.
The means, methods and specifications of security and the messages to be used between the
parties, to ensure the level of security required, should be set out in detail in the user manual.
10.5.8.4 Failure and Security Procedures
The failure of an EDI Message exchange, or an error in a message resulting from the use of
security procedures or measures should be notified to the sender within the specified time limits
in order to allow the sender to initiate any appropriate corrective action. In the case of rejection
of an EDI Message or the detection of an error, instructions from the sender should be sought
before any other action is undertaken by the receiver on the content of message itself.

285

10.5.8.5 Encryption
The parties may agree to use a specific form of protection for certain message such as a method
of encryption to the extent permitted by law in either of their respective countries. For
consequential transmission or retransmissions, parties shall maintain the same level of
protection.
Sample Clauses
The parties undertake to implement and maintain security procedures and measures in
order to ensure the protection of EDI Messages against the risks of unauthorized access,
alteration, delay, destruction, loss, or security breach.
The security classifications detailed in the User Manual shall apply. For NATO
classified information the NATO document CM(55) 15(Final) Security within North
Atlantic Organization is applicable. This document is made part of this Agreement by
reference, automatically if the User Manual indicates that classified information will be
transmitted.
Security procedures and measures include the verification of origin, the verification of
integrity (including date and time of transmission), the non-repudiation of origin and
receipt and the confidentiality of EDI Messages. Security procedures and measures for
the verification of origin and the verification of integrity, in order to identify the sender of
any EDI Message and to ascertain that any EDI Message received is complete and has
not been corrupted, are mandatory for any EDI Message. Where required, additional
security procedures and measures may be expressly specified in the User Manual.
If the use of security procedures and measures results in the rejection of, or in the
detection of an error in an EDI Message, the receiver shall inform the sender thereof,
within the specified time limit. The receiver of any EDI Message which has been
rejected, or which contains an error shall not act upon the EDI Message before receiving
instructions from the sender.
Where a rejected or erroneous EDI Message is
retransmitted by the sender, the EDI Message should clearly state that it is a corrected
EDI Message.
10.5.9 Confidentiality
In-confidence information is distinguished from classified information by different laws and
regulations relating to its disclosure and use and it should therefore be addressed separately in
the agreement.
The level of protection to be maintained for Electronic Data Interchange messages of an in
confidence nature is intended to reflect the level adhered to in the paper environment. At least
the same level of protection of such messages should be maintained wherever such message is
subject to consequential transmission or re-transmission. The contract covering the underlying
transaction may provide for marking requirements (e.g., in respect of technical data). Any
protective measures applied to such messages must be compatible with these requirements. The

286

user manual may elaborate on the further technical procedures required to implement the
necessary protection.
The information to be protected by this clause is sensitive information of a commercial nature.
Accurate protection of this kind of information is mandatory. However, the restrictions required
under this clause on the receiving party should not be applicable if the information is rightfully
available for unrestricted use.
Sample Clauses
In addition to the provisions governing security the Parties shall ensure that Electronic
Data Interchange Messages containing information specified by the sender or agreed
mutually between the Parties to be of an in confidence nature are maintained in
confidence and are not disclosed or transmitted to any unauthorized person nor used for
any purposes other than those intended by the Parties.
When authorized, further
transmission of in confidence information shall be protected to at least the same degree as
the originally transmitted Electronic Data Interchange Message.
Data requiring
protection shall be marked by the sender in accordance with the contract covering the
underlying transaction and as defined in the User Manual.
Electronic Data Interchange Messages shall not be regarded as containing in-confidence
information to the extent that it can be demonstrated such information:

Is in the public domain other than by breach of this Agreement by the receiver
and is available for unrestricted use; or
Is in or comes rightfully into the possession of the receiver without restrictions; or
Is received by the receiver from a third Party who himself has the right to disclose
the information without restrictions; or
Is or was independently developed by the receiver; or
Is approved by the owner of the information for unrestricted release by the
receiver.

10.5.10 Data-Log: Recording, Storage, and Reconciliation of EDI Messages

10.5.10.1 Storage Procedures and Time Limits
The requirements for storage of Electronic Data Interchange messages have in some countries
been set up by legislation, in most cases fiscal legislation. In those countries where no
provisions have been made for Electronic Data Interchange storage, analogy should be applied
by reference to the paper. The time of storage requirements is different from country to country
[or of state to state] and may vary according to the area and circumstances.
For this reason, the parties should ensure that the specified time of storage complies with any
national legislation. The Uniform Rules of Conduct for Interchange of Trade Data by Teletransmission (edited by the International Chamber of Commerce) suggest a period of storage of
three years. The same duration of storage has been adopted by the fiscal legislation of some
countries. Such a period should be considered as a minimum requirement to store information in

287

an accurate and secure way. This time period of three years is suggested as the time limit to
consider by parties, should there be no other legal or customary requirement.
If the requirements of national law vary compliance with the laws in question should be ensured.
It must be stressed that laws of many countries require a period of storage, of 7 years or more. It
must also be emphasized that such storage may need to be ensured for various purposes,
including but not limited to, audit, accountancy, tax, evidence, and other administrative or legal
requirements. It is recommended that careful storage of the information be ensured. The
Electronic Data Interchange messages sent or received should, for the security of the transaction,
be stored completely and in a chronological order, in a secure way and without alteration.
Certification of the data-log may be necessary or desirable for the purposes of introducing the
data-log as evidence. More legal requirements in connection with the storage of the data may
exist at national level and should be carefully followed.
10.5.10.2 Format of Storage
The data transferred using Electronic Data Interchange should be stored in the agreed format (see
user manual) in which it has been sent or in the format in which it has been received.
This is the format of the data that can be considered as originally received and will constitute, if
necessary, evidence of the Electronic Data Interchange message as it has been sent or received,
before any translation of the message has happened.
If an Electronic Data Interchange message has been electronically signed, it will only be possible
to verify it against the format in which the message has been sent.
The data should also be stored in the format in which it is translated in the information system of
the receiver or from the information system of the sender. This will be however, a matter for
decision of the parties. The readability of, and the possibility to print out the messages are
criteria most required by national legislation and should be complied with. To ensure that
readability is maintained, any material, software or any other operational equipment which may
be required to access the data and read it, should be retained by the parties, even in the case
where updating of systems have occurred. The parties may wish or need, in such cases, to keep
the availability of such equipment without retaining it themselves. Such possibility should only
be relied on after verification of national legislation requirements.
Each party should prepare a permanent copy of its data-log at a frequency that would depend on
the quantity of transactions. Some regularity is desirable if the permanent record is to be
admissible as evidence in legal proceedings as routinely prepared business record.
To ensure that all documents sent have been received the permanent copy of the data-log should
be delivered to the other party for reconciliation purposes and a procedure for objection should
be specified.
Sample Clauses

288

A Data-log, including any Electronic Data Interchange Message as sent and received,
shall be maintained by each of the Parties without any modification for a minimum
period of [insert number of] years/as specified in the User Manual, following the
completion of the transmission.
Parties shall ensure that electronic or computer records of the Electronic Data Interchange
Messages shall be readily accessible, are capable of being reproduced in a human
readable form and of being printed, if required. Any operational equipment required in
this connection shall be retained.
Each Party shall designate one or more individuals with appropriate authority as the
persons responsible for the systems and procedures relating to the recording and storage
of the Data-log. Any such authorized person shall be competent to certify the accuracy
and completeness of the Data-log.
At the end of each period as specified in the User Manual or more frequently as a Party
may wish, each Party shall prepare a permanent copy of its Data-log for the immediately
preceding period. The permanent copy for that period shall be certified by one of the
persons authorized pursuant to paragraph above and prepared in duplicate in an
unalterable form of electronic or optical media as specified in the User Manual. If not
more than [insert number] Electronic Data Interchange Messages have passed between
the Parties during that period, a Party may, at its option, prepare the permanent record of
the Data-log for that period in written form.
Each Party shall deliver one duplicate of its permanent Data-log to the other who shall
have a period of [insert number] days following receipt to compare it with its own, and
shall give notice to the other stating the details of any objections with respect to the
accuracy or completeness of the record received. In the absence of any such notice of
objection upon the expiry of that period the permanent record of the Data-log shall be
conclusively deemed to have been accepted as accurate and complete by both Parties.
Each Party may retain the other Partys Data-log for such period as it considers
appropriate.
10.5.11 Operational Requirements for EDI
10.5.11.1 Operational Environment
The objective of this clause is to include in an agreement the basic requirements for operating
Electronic Data Interchange. The list of operational and technical elements that are mentioned in
the clause on OPERATIONAL REQUIREMENTS FOR ELECTRONIC DATA
INTERCHANGE is not exhaustive. The details regarding these operational requirements will be
developed in the user manual, in accordance with the clause on TECHNICAL
SPECIFICATIONS AND REQUIREMENTS.

289

10.5.11.2 Operational Equipment

Although Electronic Data Interchange is independent from the hardware, the software and the
telecommunication means, the ability to exchange Electronic Data Interchange messages
requires information systems to be able to effectively receive, send and process Electronic Data
Interchange messages. Basic requirements in that respect include the efficient working of the
equipment used for the transfer of messages, including hardware, appropriate software, and
software translation.
10.5.11.3 Means of Communications
Parties need to determine the method of transmission that they will use including, in particular,
the telecommunications protocols and, where necessary, the choice of third party service
providers (i.e., suppliers of Value Added Network Services), which might be used to provide a
range of services. need to determine the method of transmission that they will use including, in
particular, the telecommunications protocols and, where necessary, the choice of third party
service providers (i.e., suppliers of Value Added Network Services), which might be used to
provide a range of services.
10.5.11.4 EDI Message Standards
The appropriate specifications required to exchange Electronic Data Interchange messages need
to be determined by the parties. Many standards are available. Parties should reach an
agreement on these and determine also all appropriate details and specifications. The use of
standards developed or accepted by the International Standardization Organization (ISO) should
be encouraged.
10.5.11.5 Codes
Code lists that are used for Electronic Data Interchange are essential. Where possible the use of
international standards or officially published code lists is recommended. These may not cover
all the needs of the parties. In that case it is recommended, in order to promote efficiency, that
preference should be given to the use of code lists which are published and maintained by known
organizations and which ensure the correspondence with other coding systems (for example:
statistical code lists).
Sample Clause
In order to undertake Electronic Data Interchange the Parties shall implement and
maintain the operational environment that includes but is not limited to the following:
Operational Equipment. The Parties shall provide and maintain, the equipment,
software, and services necessary to transmit, receive, translate, record and store
Electronic Data Interchange Messages.
Means of Communication.
The Parties shall determine the means of
communication to be used, including the telecommunication protocols and if
required, the choice of third Party service providers.

290

Message Definitions. The Parties shall use ISO definitions for Electronic Data
Interchange Messages as defined in the User Manual.
Standards. All Electronic Data Interchange Messages defined in the User
Manual shall be transmitted in accordance with standards, recommendations, and
procedures as defined in the User Manual.
Codes. Data element code lists referred to in Electronic Data Interchange
Messages shall include the agreed standard maintained code lists as defined in the
User Manual. Where such code lists are not available, preference shall be given
to the use of published and maintained code lists.
10.5.12 Technical Specifications and Requirements
10.5.12.1 User Manual
The user manual should determine all the technical requirements and specifications that are
required in order to properly exchange Electronic Data Interchange messages.
Although it is not easy to provide a list of all the elements which need to be taken into account,
as these will vary according to the needs of the parties, it can be emphasized that relevant
specifications with regard to the following points need to be provided:
The specifications relating to the operational requirements in the clause on OPERATIONAL
REQUIREMENTS FOR ELECTRONIC DATA INTERCHANGE, including:

Specifications required in relation to software and translation software for the purpose of
Electronic Data Interchange exchanges;
Communication protocols and third party services (Value Added Network Services);
Message standards and recommendations, including the list of messages and their
references;
The conditional elements where needed;
The messages design guidelines;
The implementation guidelines;
The directories;
The code lists;
The reference to the documentation;
The versions and updates;
The methods used for storage of transmissions.

The parties should specify in the user manual:

The method that they will use to implement updated versions of messages, rules,
guidelines and directories;

291

The specifications required for the processing and acknowledgment of Electronic Data
Interchange messages;
The specifications relating to security means for Electronic Data Interchange messages;
and
The specifications relating to recording and storage, the time limits.

Time limits may be of critical importance in Electronic Data Interchange, in particular when
Electronic Data Interchange is combined with other techniques such as "Just-in-Time.
10.5.12.2 Test and Trial Procedures
Technical experts have made it clear that it may prove not only useful, but also sometimes
necessary, to run tests to ensure the proper working of the systems and telecommunications.
Practice shows that such tests are, in fact, usually conducted by parties commencing use of
Electronic Data Interchange and this generally happens in two steps. Firstly, Electronic Data
Interchange messages are exchanged in parallel with the paper documents and secondly, when
this test is satisfactory, Electronic Data Interchange messages are exchanged without paper
support. It may also be necessary to conduct further tests from time to time, for example after
changes to the system have been implemented.
The parties should ensure that any data sent is free of viruses etc.
Sample Clauses
The User Manual shall include the technical, organizational, and procedural specifications and
requirements to operate Electronic Data Interchange according to the terms of this Agreement,
which includes but is not limited to the following:

Operational requirements for Electronic Data Interchange, as referred to in the Clause

OPERATIONAL REQUIREMENTS FOR ELECTRONIC DATA INTERCHANGE,
including, operational equipment, means of communication and codes;
Processing and acknowledgment of Electronic Data Interchange Messages;
Security and protection of Electronic Data Interchange Messages;
Time limits;
Procedures for tests and trials to establish and monitor the adequacy of the technical
specifications and requirements;
Recording and storage of Electronic Data Interchange Messages.
The Parties shall ensure that any data sent is free of viruses, etc.

Sample Annex
User Manual annexed to
Agreement
no.
dated
1. Time limits:
For processing messages after receipt:
For Acknowledgement of Receipt of the message

292

For rejection messages.

2. Messages which always require Acknowledgement of Receipt:
[e.g., termination of this Agreement]
3. Specific conditions regarding Acknowledgment of Receipt:
Messages concerning [...] will be acknowledged by the recipient Party within
[insert number] hours but in any event before close of business for the day
concerned.
4. For Electronic Mail, each Party shall include in each message it transmits: its
name, the date and time of the transmissions, the reference (if any) to which it
pertains, and the name and telephone number and Electronic Mail address of the
individual authorized to transmit the message.
5. Alternative recovery procedure:
6. Procedures and measures to fulfill the requirements set forth in the Clauses on
SECURITY AND PROTECTION OF IN CONFIDENCE INFORMATION:
unauthorized access, alteration, delay, destruction, loss verification of origin,
verification of integrity,
non-repudiation of origin/receipt, confidentiality, time
limits for report by receiver on rejection or error, Electronic Signature.
7. Confidential (NATO classification) information set forth in Clause SECURITY:
Reference can be made to C-M(55)15(Final)
On classification issues see C-M(55)15(Final) page 133 through 135)
Marking and tagging
8. Authorization for disclosure:
9. Method of encryption:
10. Archiving requirements:
Detail the technical provisions to ensure that a complete and unalterable Data-log is
established and maintained
Provisions for regular exchange of Data-logs.
11. Operational requirements and technical specifications e.g.:
Equipment
Software
Third Party Services
Communication services
Communication Protocols
Message standards, directories, versions, syntax, type of messages, segments, and
data elements
Codes
Procedure for tests and trials
Availability
12. Modification:
Any modification to this User Manual shall be -agreed in writing between the
Parties in accordance with the Clause on EFFECT, MODIFICATIONS,
TERMINATION AND SEVERABILITY.
10.5.13 Liability
Where liability stems from an underlying contract, the terms of that contract should prevail over
the provisions of the Electronic Data Interchange agreement.
293

10.5.13.1 Exclusion of Liability

The principle is that parties to an agreement should be held responsible for their acts and
omissions. In addition, the risks should be born by the party responsible according to the law
applicable. However, parties might want to limit (by introducing a maximum amount) or
exclude liabilities. In this clause special, incidental, indirect, or consequential damages liability
in connection with the agreement have been excluded.
10.5.13.2 Force Majeure
An exception to liability is made in the case of what is commonly known as "Force Majeure.
The concept of force majeure included in this clause is in line with the concept developed by the
United Nations Convention on Contracts for the International Sale of Goods or Vienna
Convention of 11 April 1980, and, in the absence of uniform national law on this point, provides
a definition which the parties may expand, if they wish, by citing various situations in which
liability may be exempted.
10.5.13.3 Intermediaries Liability
The parties might use a third party (also called Value Added Network Services) to provide
services such as logging, or encryption. Liability for the actions of a third party is included in
many agreements and generally accepted since often the third party will effectively be acting as
an agent of the user. Moreover, it is the party who will use the service of a third party provider
and who has the contractual relationship with the service provider who will be in the best
position to sue the service provider in the case where its liability could be engaged. A clause to
that extend could be introduced here.
Where one party imposes the use of a particular intermediary on the other, it seems fair that the
party who imposes such use should be responsible for damages which result from using that
intermediary instead of the one who has to make use of it.
10.5.13.4 Supplier Contracts
The Electronic Data Interchange agreement fits within a complex of relations enabling the
Electronic Data Interchange involving many parties, such as a Telephone Company or a supplier
of Value Added Network Services. Contracts with these suppliers, not chosen or imposed by
either party to the Electronic Data Interchange agreement might exclude liabilities.
Sample Clauses
This clause shall not apply in cases where Parties have agreed on an underlying contract
and the liability results from such contract.
Except for willful misconduct or gross negligence, no Party to this Agreement shall be
liable for any special, incidental, indirect or consequential damages caused by a failure to
perform its obligations under this Agreement. Except for willful misconduct or gross

294

negligence, liability for any direct damages incurred is limited to the maximum amount
of [insert amount and currency].
No Party to this Agreement shall be liable for any loss or damage suffered by the other
Party caused by any delay or failure to perform in accordance with the provisions of this
Agreement, where such delay or failure is caused by an impediment beyond that Partys
control and which could not reasonably be expected to be taken into account at the time
of conclusion of the Agreement or the consequences of which could not be avoided or
overcome. This provision shall not relieve liability for any matter that constitutes a
breach of the Clauses on SECURITY OR PROTECTION OF IN CONFIDENCE
INFORMATION.
If a Party requires another Party to use the services of an intermediary to perform the
transmission, logging or processing of an Electronic Data Interchange Message, the Party
who required such use shall be liable to the other Party for damage arising directly from
that intermediarys acts, failures, or omissions in the provision of said services.
10.5.14 Dispute Resolution
10.5.14.1 Options
In case of disputes resulting from the performance of underlying contracts, the dispute provisions
of such contracts should prevail.
Three dispute resolution options are offered:
1. The first option provides a clause on arbitration.
2. The second option provides a jurisdiction clause, where the choice of a jurisdiction is to
be agreed in the case where the parties decide that dispute will be referred to court.
3. A third option leaves open the choice between arbitration and court of law.
It should perhaps be emphasized that because of the relationships that Electronic Data
Interchange creates between users there is a great potential for dispute to be resolved by
negotiation. It is only when such negotiations fail that the clauses on dispute resolution will
become effective and useful.
10.5.14.2 Arbitration Clause
Parties may wish to decide to resolve their dispute by way of arbitration. Arbitration may prove
a practical procedure to resolve a dispute involving parties of different countries. It offers the
advantage of the choice of arbitrator(s) or of the appointing authority and of a more speedy
procedure although this is not always the rule. It can be attractive for the confidentiality of the
procedure, which is sometimes favored by parties. The arbitration award is in principle final
although appeal is possible.
Many countries still require a written and clear statement on arbitration when this is the choice of
dispute resolution and the parties are therefore advised to include such clause.

295

The clause offered for inclusion in the agreement under option A refers to the rules of
conciliation and arbitration of the International Chamber of Commerce. The parties need to
define how the arbitrator will be nominated. A choice can be made between one or three
person(s) nominated by agreement or in case of failure of an agreement on the arbitrator(s), an
appointing authority can proceed to the nomination. The parties should therefore indicate which
will be the appointing authority. In addition, it can be determined by parties in which language
the arbitration procedure should be conducted.
10.5.14.3 Court of Law
In the case the parties intend to have their litigation solved by a court, the second alternative
provision provides for the parties to choose the competent court and stipulate it in their
agreement. In the case where the parties do no make such a choice, the competent court shall be
determined by reference to e.g., the Convention on jurisdiction and the enforcement of
judgments in civil and commercial matters.
10.5.14.4 0ption C
If parties do not want to exclude up front one of the methods of dispute resolution this option can
be selected.
Sample Clauses
In case of disputes resulting from performance of underlying contracts, the dispute
provision of such contract shall apply.
Option A: Arbitration.
Any disputes between the Parties arising from or relating to this agreement shall be
finally settled in accordance with the conciliation and arbitration of regulations of the
International Chamber of Commerce, by one or more arbitrators appointed in pursuance
of these regulations and there shall be no right of appeal nor recourse of any kind.
Option B: Court of Law.
Any dispute arising out of or in connection with this Agreement shall be referred to the
competent Court of [insert name of country], which shall have sole jurisdiction.
Option C: Arbitration or Court of law.
Unless the Parties agree in writing to submit the matter to arbitration or other procedure
for the resolution of dispute, or to select a different jurisdiction any matter or dispute
arising from, out of or in connection with this Agreement as to its validity, interpretation,
construction or performance shall be subject to sole and exclusive jurisdiction of the
[insert name of country] Court.
10.5.15 Applicable Law
The parties to the agreement should indicate their choice of applicable law

296

Sample Clause
This Agreement is governed by the Law of [insert name of country].
10.5.16 Effect, Modification, Term, and Severability
10.5.16.1 Effect
This article states that the agreement does not come into effect until the parties sign it.
10.5.16.2 Modification
Any modification, addition, or alternative provisions to the agreement should only be made in
writing and agreed by all parties.
10.5.16.3 Termination
The period of one month proposed in this clause regarding termination notice may be extended
by the parties. It is not advised to reduce it as it is considered as a minimum.
The Termination Clause provides that some rights and obligations relating to the agreement are
of fundamental importance and should remain in effect following termination of the agreement.
10.5.16.4 Severability
A paragraph should be inserted to prevent a party from terminating the agreement simply
because one clause has become invalid. It is also intended to prevent parties from terminating an
agreement to avoid certain obligations
Sample Clauses
Effect. The Agreement shall be effective from the date on which it is signed by the
Parties.
Modification. Where required, additional or alternative provisions to the Agreement
including modification to the User Manual, agreed in writing by the Parties, will be
considered as part of the Agreement upon the signature on behalf of the Parties by the
original signatories or their authorized representatives.
Termination. Any Party may terminate the Agreement by giving not less than ...[one]
months notice either by registered post or by any other means (e.g., by an Electronic
Data Interchange Message) agreed between the Parties. Termination of the Agreement
shall only affect Electronic Data Interchange (including Electronic Mail) transactions
after that date. Notwithstanding termination for any reason, the rights and obligations of
the Parties referred to in Clauses ADMISSIBILITY IN EVIDENCE OF ELECTRONIC
DATA INTERCHANGE MESSAGES, SECURITY, PROTECTION OF INCONFIDENCE INFORMATION, DATA-LOG RECORDING AND STORAGE AND
RECONCILIATION OF ELECTRONIC DATA INTERCHANGE MESSAGES,
DISPUTE RESOLUTION and APPLICABLE LAW shall remain in effect.

297

Severability. Should any clause or part of a clause of the Agreement be deemed invalid,
all other clauses shall remain in full force and effect [and the Parties shall agree on a
substitute provision]. All annexes to this Agreement shall be an integral part of the
Agreement.
10.5.17 Signature Page
Sample Clause
For the Minister of Defense
of [insert name of country]

For [insert company name]

or for NATO agency

[insert name]
[insert title]
date date
place place

[insert name]
[insert title]

298

11.0 CALS STANDARDS OVERVIEW

11.1 NATO CALS Standards Policy
It is NATO CALS Policy to promote the use of International, technology, and vendor
independent CALS standards and to harmonize, wherever possible, standards and their
application. Many CALS and CALS-like processes also rely on standards that have multiple
applications outside the primary CALS domain; the NATO CALS Organization will only
involve itself with such related standards in instances where such involvement is essential to
support the NATO CALS Mission.
11.1.1 ISO Standards
This policy implies the use, where they exist, of International Organization for Standardization
(ISO) standards or those of other international bodies of similar status (e.g., United Nations
Economic Commission for Europe(UN/ECE), International Electrotechnical Commission (IEC),
or International Telecommunications Union - Telecommunications Standardization Bureau
(ITU-TSB)(formerly CCITT)). The NATO CALS Organization will seek to ensure that the
NATO interest as users of such standards are safeguarded or represented as appropriate.
11.1.2 Multi-national or National Standards
Where such ISO standards do not exist, it is NATO CALS Policy to promote the harmonization
of any appropriate de facto international, multi-national, or national standards with the aim of
establishing such products on a migration path to ISO status.
11.1.3 Standardization Agreements/Military Profiles
Where the establishment of an ISO Migration Path is not practicable, the NATO CALS
Management Board will promote the development of NATO Standard practices that lead to
improved interoperability, using, where appropriate, NATO Standardization Agreements
(STANAG).
11.1.4 Limitations of Standards
Not all CALS standards contain comprehensive detailed specifications that permit the optimum
implementation of every possible process to which the standards have relevance. In particular,
international and national standards often seek to provide a framework suited to a variety of
applications; this approach often results in standards with deficiencies so far as any specific
application (e.g., Military) is concerned, and hence particular user groups tend to develop either
separate standards (e.g., US DoD MIL SPECs) or application profiles which interpret the base
standards or amplify them for specific applications (e.g., UK MoD DEF STANs or NATO
STANAGs). The NATO CALS Policy recognizes such limitations, but such products will only
be promoted as an interim measure whilst more general standards are under development or to
support essential NATO operational requirements specific to NATO and the NATO Nations for
which external standards are inappropriate.

299

11.1.5 NATO User Groups

In instances where a number of NATO applications of a specific standard exist the NATO CALS
Organization will seek to promote the exchange of experience, skills, and information between
users with the primary aims of improving the standard where necessary and of providing a
source of information and advice to staff of new agencies and projects.
11.2 NATO CALS Standards
Pending any formal adoption of a standard for NATO CALS application, a system of
recommendation will be adopted. Where determined, this recommendation is shown in Column
1 under each heading:
11.2.1 Temporary Standard [ T ]
Temporary Standards are either de-facto standards from industry or academic development
bodies or standards organisations that have been widely adopted and are available in COTS
implementations from commercial vendors. If such a standard becomes an ISO standard, it will
be adopted as a Recommended Standard. If it is superseded by an approved ISO standard that is
adequately supported by implementation tools, then it will be dropped.
11.2.2 Emerging Standard [ E ]
An Emerging Standard is a de-facto or de-jure standard appropriate for CALS application but
which has not (yet) been adopted or taken under consideration by an international standards
organisation.
These can be Draft International Standards (DIS) or National Standards or
approved International Standards without product support. Emerging Standards generally do not
have approved product support (COTS tools).
11.2.3 Recommended Standard [ R ]
A Recommended Standard is one which has been approved by international standards
organizations such as ISO, IEC, or ITU-TSB/CCITT and which is supported by an adequate
number of COTS implementations or tools.
These standards have priority over Emerging
Standards and Temporary Standards.
11.2.4 Not Recommended Standard [ N ]
A Not-Recommended Standard is one which has been approved by international standards
organisations, but which does not comply with modern CALS Philosophy and which has been
superseded. These standards may be in current use, but it is not recommended that they be used
in future applications.
11.2.5 Undetermined Status [ ]
Unless one of the above indicators has been used, the status of the standard should be regarded as
undetermined at the date of publication as far as NATO CALS Policy is concerned. Normally
this designation will only be used in initial drafts of new sections of the Handbook.
300

12.0 EXAMPLES AND LESSONS LEARNED

12.1 The Viking Submarine
The Viking submarine program represents a cooperative venture between not only government
and industry, but also between multiple governments, non-governmental organizations, and
industry and defense activities. The goal is to determine whether to jointly develop new
generation military submarine platforms or not: To establish a foundation for the national
authorities, making them able to decide whether to continue the co-operation in a Definition
phase for new Submarines.20
Denmark, Norway, Sweden, and Finlands Defense Ministers agreed to co-operation in the area
of defense material (agreement dated 2 December 1994) and a working group was formed. From
March of 1995 to June of 1997, the working group performed preliminary studies on a common
Submarine project. Agreement to carry out a common Study and concept phase was signed by
the heads of the three nations Materiel Commands on 3 July 1997 and the Viking program
resulted.
The main activities were focused on harmonizing requirements, producing a common
preliminary Staff Requirement Document, assessing and describing consequences of a common
procurement and examining the possibilities for participation by the Scandinavian defense and
shipbuilding industry. Milestones were established starting with the signed agreement in July of
1997 and continuing through a system specification due in December of 1999. Key players in
the effort included the Naval Materiel Commands, Defense Research Institutions, Kockums AB
as the main Study Contractor, various Sub-contractors, Universities, and the NATO CALS
Office.21
And what of CALS in the Viking Program? CALS was integral from the start. A CALS Study
was scheduled in the initial program plan, the Viking program called an initial meeting in
December of 1997, inviting national CALS experts and the NATO CALS office. Introduction of
CALS into the program was expected to produce reduction in acquisition and life-cycle costs,
acceptable information flow between the participating parties and an acceptable Information
Management concept for the Viking22 As a result, a Viking CALS Working Group was
established.
A major activity within this working group was the development of the Through Life
Information Management (TLIM) Strategy and its operational level document, the Through Life
Information Management Plan. The TLIM Strategys goals of improved through-life quality and
accuracy of system information, accurate and consistent configuration management and
reduction of 10% in design, development and production costs are to be achieved by establishing
a shared data environment amongst all parties. This shared data environment would have a
logical data structure able to hold and integrate all the information necessary to design, build,
20

NCMB Briefing, October 98, chart 4

NCMB Briefing, October 98, chart 10
22
NCMB Briefing, October 98, chart 14
21

301

operate and support the Viking Submarines and be based on open, international, or de facto
standards.
Operational level documents of the Through Life Information Management Strategy, which
forms the framework for this program and the Through Life Information Management Plan, are
located at Appendix J and Appendix K respectively.
12.2 The Crusader (US Howits)
The crusader program will produce the US Armys next generation cannon artillery system. Its
objective is to develop and field a revolutionary Cannon Artillery system of systems, consisting
of 155mm Self-Propelled Howitzer and an armored Resupply Vehicle for Force XXI. The prime
contractor is United Defense Limited Partnership, UDLP.
Figures 12-1 and 12-2 show examples of the Internet access to the Project management site.
This site provides a Web based CITIS access for both on post and Off-post users as well as
program management information, milestones and schedules and general information.
Following the figures is a document describing the Programs Integrated Data Environment.

Figure 12-1 Crusader Home Page

302

Figure 12-2 Crusader Integrated Data Environment Web Page

Selection of the Integrated Data Environment Document Link provides the following
document outlining the IDE for the Crusader Program.
Crusader Integrated Data Environment
Point of Contact:
Mr. Angelo J. Castellano
US Army PM Crusader
ATTN: SFAE-GCSS-CR-B
Building 171
Picatinny Arsenal, NJ 07806
Phone: (201) 724-7143, DSN 880-7143
Fax: (201) 724-4836
E-Mail: angeloc@pica.army.mil
12.2.1 Statement of the Situation
The Crusader will be the Armys next generation self-propelled Howitzer. It was deemed critical
to the success of the Crusader program that the design of the Crusader and the efforts of all the
factions involved in the effort be integrated by the prime contractor into an automated

303

computerized service that provides the needed environment for Integrated Product Development
(IPD) and virtual co-location of data.
It is expected that the engineering data environment generated in the program will be highly
complex and the shortened timeline will require a level of coordination of effort that is missioncritical. This coordination of effort is compounded by the fact that there will be many companies
involved in the design and fabrication of the Crusader.
View and markup tools supporting the ability to gather and manage multiple reviewers was
deemed necessary, as was workflow, sign-off, and routing mechanisms to improve end-users
productivity and efficiency, prevent the production of paper based data, eliminate duplication of
effort, and provide a fully integrated data environment supporting multiple data types,
throughout the products life-cycle.
A goal of the Crusader IDE is to contain all contractor generated data and GFI, including
engineering, support, and management data. The Contractor is required to deliver all data
electronically.
In addition to providing engineering data delivery, data management, and
configuration management services to the Office of the PM, the Crusader IDE will serve as the
mechanism by which the large, geographically dispersed industry team will share engineering
data. This method of developing the product requires that the team have near-real time access to
information as it is created.
The goal of the Crusader IDE system is to provide this access, ensuring that the most recent data
is identifiable, revision histories are included and is accessible by any member of the team. The
extended scope of the Crusader IDE includes access by the Government to all contractor workin-progress information, rather than merely to contractually deliverable documents - this feature
is an enabler for IPD and, coupled with the integration of cost and schedule data, makes the IDE
a primary tool for overall program management and control.
12.2.2 CALS Technologies, Philosophies, and Standards Implemented
The Crusader IDE was developed under contract as a CITIS (Contractor Integrated Technical
Information Service), initially defined IAW MIL-STD 974, but expanded greatly under PM
Crusader. The Crusader IDE is a robust technical information service that goes beyond
traditional "CITIS" mechanisms, towards a true integrated product environment that includes
procedures, processes, specifications and software applications for the generation, protection,
integration, storage, exchange, and on-line access of digital data.
The Crusader IDE implements the philosophy and intent behind the CALS initiative, by
integrating all program data and allowing concurrent use of real-time, in-process (work-inprogress) data in a virtual co-location scenario. The Crusader IDE Intranet supports a growing
user community involving multiple tiers of Contractors with an initial combination of T1, and
Internet connections. It supports an environment that involves clients with widely diverse data
demands.
The Crusader IDE is an integration of commercial off the shelf (COTS) software that is modular,
scaleable, and capable of adapting to evolving program needs, and includes Product Data
304

Manager (PDM) and document viewer software. The IDE systems integration work done by the
prime contractor and its subcontractors is fully owned by the Government.
The PDM client/server software is integrated with other software to handle core functions such
as Windows 95 desktop access, workflow management, configuration management, and
view/markup. The technical files are represented in an object-oriented data architecture that
graphically mirrors the program WBS and other views into the information such as product
structure, with a relationship-based data model that allows data to be tied to one another via softlinks that support their interrelationships.
Technical files are managed by the metadata, controlled by the PDM engine, supported by
Metaphase Technologies, a division of SDRC. Metaphase is an industry-accepted client/server
PDM. The Crusader IDE is designed for single point access into one logical data system to
ensure the integrity and uniqueness of stored data relationships.
The Crusader IDE architecture employs the PDM to facilitate the combined management of
data, processes, and users and allow information systems architects to define groups, workflows,
and metadata. Additionally, this software allows for tailoring of data workflows and automated
life-cycles, allowing for future growth and expansion as the program matures from PDRR to
EMD and beyond.
The Crusader IDE architecture (a) makes data easier to find so that users will be less likely to recreate data that already exists, (b) enforces CALS and application standards that help data flow
from one application to another, and (c) provides multiple views into the data repository. An
integrated common toolset includes standard commercial off the shelf (COTS) software for the
generation and management of design models, documentation, and other product information.
MS-Office was chosen as the standard for integration of textual, spreadsheet, and presentation
data. Cost and schedule data are fully integrated and available to the IPD Teams via a desktop
toolset that includes the use of WInsight and OpenPlan.
Pro-Engineer is integrated at a "level 3" which provides for management of the IDE drawing data
from inside the Pro-E tool itself. Other tools integrated include: Rational/Rose/Apex, Adobe
Exchange, RTM/RDD-100, and workflows from CMSTAT. Encryption of sensitive data is
enabled over local and wide area networks, and over the Internet.
12.2.3 Team Members
The Crusader IDE Team consists of members from the Office of PM Crusader, United Defense
Limited Partnership (UDLP), and EDS. Additional participation came from General Dynamics.
Consulting support was obtained from Metaphase/SDRC, CIMdata, Adobe, Parametrics
Technologies, CMSTAT, and other software vendors. NSA, DIS, and ARDEC contributed
guidance on specific areas within the IDE, via the PMs encryption Process Action Team (PAT).
EDS performed the actual IDE systems integration effort under direction from UDLP (the
Crusader prime contractor) and the Government IDE Team members in accordance with the
philosophies and goals of true IPD and teaming. Special support was provided by the EDS onsite technical people, who provided direct support to the end-users, and essential IDE training.
305

12.2.4 Results Achieved

Within the IPD environment, the focus is not only on delivery of data, but also on the enabling of
data sharing.
The IDE provides the Crusader IPD Teams with a level of coordination
unsurpassed in industry today. The features of the IDE allow controlling costs, reducing risks,
minimizing re-design, increasing productivity, and increasing data quality. Version and parts
control are facilitated, and Configuration Management of the design data is fully supported. All
types of Crusader objects and images are managed.
Integration of tools facilitates use of the IDE, and integrates the IDE fully into the day-to-day
working environment. Internet Web access provides remote users access using a familiar, userfriendly interface (Netscape). Simultaneous view/markup of multi-reviewer comments directly
on a single document provides the program with coordinated reviews.
Full history of comments and changes to documents, as well as library and archive data are
supported. A return on investment (ROI) is fully expected; this stems not only from cost
avoidance, such as travel costs, lost hours, data handling improvements, paper reduction, but
time and productivity improvements, such as instant data feeds from remote users at proving
grounds.
The major contributors to an ROI are improvement of the business processes such that users can
manage not just the data but also the program, and the nature of the IDE facilitates greater
review/design participation and increases time available to do so, such that the final product
quality increases several fold. It is expected that the IDE will reduce engineering design manhours by approximately 25%, reduce the number of changes by over 25%, reduce the cost of
changes by 25-50%, and reduce time to access data by over 25%.
The Crusader IDE enables effective generation, exchange, use and management of Crusader
technical and programmatic information, it enhances integration of Product Development Teams,
both government and contractor, enabling them to function more efficiently by sharing
information in an electronically integrated, "virtual co-location" scenario.
The IDE is an
integrated information environment that enables continuous product and process improvement,
with a reduction of administrative burden, delivering full data management support to the users
desktop.

306

12.3 U.S. ARMY PMCMS

The U.S. Armys Program Manager for Combat Mobility Systems (PMCMS) is responsible for
the acquisition and fielding of Armys Ground mobility equipment. PMCMS implemented an
Integrated Data Environment using Government Off the Shelf (GOTS) and Commercial Off the
Shelf (COTS) products for three of its systems: the M88A2 Hercules recovery vehicle, the
Wolverine Assault Bridge and the Grizzly Obstacle Breacher.
PMCMS wished to achieve an environment for collaboration through enterprise connectivity that
would provide process improvements, commonality to improve responsiveness and increase
efficiency. PMCMS described its state of defense system data as:

"Data availability not timely with the decision/action process

Corporate knowledge tied to individuals
Data structure inhibited sharing
Life span of the data inadequate

PMCMS felt that the IDE would lead to electronic vs. actual team meetings, would make team
and corporate knowledge more widely available and accessible, information mobility would
enhance both team and individual responsiveness and that the IDE would facilitate rapid changes
in team size and composition.
The IDE solution at PMCMS links the PMCMS at Warren, MI, the prime contractor, UDLP at
York, PA, the US Army Engineer School at Ft Leonard Wood, MO, TEXCOM at Fort Hood,
TX, Anniston Army Depot, Anniston, AL and other key activities (eleven sites, 165 users).
Using a series of defined workflows PMCMS achieves reduced times to let production contracts,
resolve corrective actions and provide cost avoidance.
Appendix L is an abstract of the PM CMS IDE solution. This paper provides a description of
the effort and lessons learned from the government perspective.

307