SECTION 2

APPROACH

The modeling effort began with extensive research of IEW doctrinal publications. Then SMEs within the Intelligence Community were chosen and interviewed extensively. This effort provided a real world application of IEW operations. The input from the SMEs was compared to doctrinal practices and nuisances were captured in the IEW Process Model. Each section of the IEW Process Model was extensively reviewed by several SME panels. Finally, the Process Model went through a month long In-Process Review (IPR) and the model was given the distinction as being an accurate depiction of IEW operations.

IDEF modeling continued with the IEW Data Model. This effort began by selecting a baseline model to represent IEW information requirements. The C2 Core Data Model was chosen as base model for the IEW Data Model. The next key step was to highlight information flows in the IEW Process Model as they supported command and control activities. This led to the overall mapping of the data exchanges within the IEW Process Model to the C2 Core Data Model. Mapping continued with the comparison of the Moderniz ed Intelligence Database (MIDB), the C2 Core Data Model, and the United States Message Text Formatting Program.

From the above activities an entity pool was created which was reviewed by SMEs from IEW functional areas, as well as IEW materiel developers, combat developers, and outside functional area experts. Next, the Key-Based IEW Data Model was created and brought for review. This process continued through the development of non-key attributes, domain values, and metadata. Every step in the development of the IEW Data Model was extensively analyzed so that the information requirements of the SMEs, combat d evelopers, materiel developers, and functional area experts were addressed by the IEW Data Model. Finally, the IEW Data Model came to represent an accurate depiction of the information requirements needed to perform IEW operations.

2.1 THE MODELING PROCESS

Modeling is a structured, analytical method of studying and documenting business activities and the data needed to support their information needs. Modeling employs a language, or syntax, to record the things modeled, in a structured format, so that trained users can communicate with each other and the Information Systems Community.

The Department of Defense has mandated the use of IDEF modeling techniques as their modeling language because it is most easily understood by management, information users, and information system specialists. The IDEF modeling techniques are precise and inclusive, supporting Process Models, Data Models, consistent definitions, and analytic matrices.

Process Models (IDEF0) analyze and document business processes. For each process or sub-process, the necessary information flows and roles are defined (e.g., inputs, controls, and outputs). Additionally, the systems, people, or equipment that perform the activities are recorded (mechanisms).

Data Models (IDEF1X) analyze and document the fundamental data needed to support the business as defined by the Process Models. These data requirements and the associated business rules are discovered by examining the information requirements defined in the Process Models.

One of the most significant characteristics of the modeling process is this iterative and evolutionary nature. By definition, a model is a description of the real world expressed in a language or structure at a particular point in time. The modeling techniques recognize that each model is an approximation, a snapshot, or an abstraction of the real thing. As we learn more about the process modeled, either from further study or by merely applying the model to everyday business, we discover enhancements or corrections that need to be made.

A modeling procedure must be able to accept the inevitable iterations of its models, and be prepared to make changes as they occur. The approach anticipated the fallibility of the models and plans for the continual change that has always happened to organizations, their policies, and their information systems. The modeler anticipates this change rather than being caught off-guard by it.

2.2 USER-DRIVEN ANALYSIS

Models are "user-driven" to depict a realistic picture of enterprise business processes and the data used to support the processes. Thus, the input of functional area SMEs is critical to the success of the effort.

SME input was key to the success of both the Process and Data Models. Also, combat developers, materiel developers, and outside functional area SMEs helped with coordination efforts throughout the Intelligence Community, as well as DoD. The emphasis placed on SME input helped to create an accurate representation of IEW operations and its information requirements.

2.3 THREE-SCHEMA APPROACH

The notion of a three-schema model consisting of a conceptual model, an external model, and an internal (or physical) model was first introduced by the ANSI/X3/SPARC Study Group on Database Management Systems (DBMS) in 1977 (See Figure 2-1). The ANSI/X3/SPARC Report characterized DBMSs as having a two schema organization. That is, DBMSs utilize an internal schema, which represents the structure of the data as viewed by the DBMS, and an external schema, which represents various structures of the data as vi ewed by the end user. The concept of a third schema (conceptual) was introduced in the report. The conceptual schema represents the basic underlying structure of data as viewed by the enterprise as a whole.

As the practice of Data Administration has evolved and more graphical techniques have evolved, the term "schema" has given way to the term "model". The conceptual model represents the view of data that is negotiated between end users and database administrators covering those entities about which it is important to keep data, the meaning of the data, and the relationships of the data to each other.

The ANSI group identified the requirement to formalize the conceptual model with a standard language and use it to actively manage data. Thus, a conceptual data model is a particular organized way of viewing or defining data, or simply a data structure with a specific scope and viewpoint.

Figure 2-1 Three-Schema Model

The three-schema approach to information management promotes the conceptual model as the key to achieving data integration. By distinguishing between the forces that cause change to the external models (usersí views) and to the internal models (physical structures), the conceptual model emerges as the neutral zone providing growth and flexibility to the data resource environment. The conceptual data model enables users to see the data without concern as to where the data is located, or who is maintaining it.

The objectives of the conceptual model are to:

  1. Provide for the enterprise-wide logical integration of data, independent of the logical and physical storage structures, and independent of current and future applications or uses of the data.
  2. Provide guidance and control for sharing of common data with flexible assess.
  3. Provide guidance and control to ensure data integrity and quality, including consistency with business policies and procedures.
  4. Provide for on-going extensions to formally defined and automated data.
  5. Provide for identifying shared data, fixing acceptable meanings to these data, and assuring consistent interpretation throughout the enterprise.

In order to meet these objectives, the conceptual model must have the following characteristics:

  1. It must be a single integrated view of the data which is consistent with the underlying rules of the business and must be true regardless of how the data is stored.
  2. Once defined, the conceptual model only changes when the nature or rules of the business change.
  3. It must be extendible without revising existing data definitions to allow for evolutionary development.
  4. It must be mappable to multiple internal data models (physical database structures) to allow for the upgrading of computing technology and tuning of physical databases for efficiency.
  5. It must be mappable to multiple external model views to allow for user flexibility and allow changes to the internal model without affecting user views of the data.

An external view or model has the following characteristics:

  1. An external view is a subset of the conceptual data structured to provide specific information to a user.
  2. Many different external views may exist for the same data.
  3. External views change according to user information requirements.

An internal model has the following characteristics:

  1. An internal model is a subset of the conceptual model structured for efficient and effective storage and retrieval of certain data.
  2. The logical data structure (hierarchical, network, inverted, relational, etc.) for each physical database is defined as an internal model ( or schema).
  3. An internal model is implemented with a specific data access and storage technology.
  4. Internal models change according to data access and storage technology and according to how the data is physically distributed.

2.4 STRAP METHODOLOGY

The Structured Requirements Analysis Planning (STRAP) methodology was used to develop the Process Models and Data Models for this effort (See Figure 2-2). During the STRAP process the information requirements of a business (both process and data) are analyzed and documented. The STRAP methodology is used to facilitate the modeling process.

Information Engineering Pyramid

Information Requirements Study Strategic Planning
Information Requirements Study Implementation Tactical Planning
Prototype Systems Implementation Activity and Data Models
Prototype Systems Implementation Physical Database Application Software
Figure 2-2 Information Engineering Pyramid

STEPS TO THE STRAP PROCESS

  1. Overview.
  2. Determine deliverable and schedule.
  3. Identify participant roles.
  4. Develop the Scope statement.
  5. Develop the Process Node Tree outlining the process structure of the business area.
  6. Identify SMEs who will participate in the development and validation of the Context and Decomposition Diagrams and the Data Model.
  7. Develop Decomposition Diagrams and Context Diagrams by selecting the lower level activities from the Node Tree.
  8. Develop higher level Decomposition Diagrams by integrating the lower level Context Diagrams.
  9. Develop an entity pool from the ICOMs contained in the Context or Decomposition Diagrams.
  10. Develop a Key-Based Data Model using the Entity-Relationship Data Model as a basis.
  11. Validate the Key-Based Data Model by reviewing reports and validating the ICOMs supported in the Data Model.
  12. Define activities, ICOMs, entities, and keys.
  13. Prepare STRAP.

2.5 MODELING TECHNIQUES

IDEF modeling techniques are being employed for this project. IDEF modeling techniques are government owned and were originally developed by the U.S. Air Force. IDEF use and successful implementation are widespread throughout government and private industry. IDEF has proven to be an effective tool to aid in information management and information requirement definitions.

The IDEF modeling techniques provide an effective means for:

  1. Documenting the current ("AS-IS") and the planned ("TO-BE") environments.
  2. Accomplishing interaction and consensus between user groups as part of system requirements definitions and subsequent development.
  3. Achieving consistency, which facilitates data integration and sharing.
  4. Providing documentation and audit trails during system conceptual design.

The IDEF modeling techniques are used to develop Process Models (known as IDEF0) and Data Models (known as IDEF1X). These models graphically and descriptively depict business processes and their basic data. The Process Models define and explain the business process, while the Data Models build the foundation of data needed to run the business.

Key Points of the IDEF modeling techniques:

  1. IDEF is a structured development methodology that is standardized through a formal userís group.
  2. IDEF modeling techniques provide a picture of the business process and provide graphic documentation.
  3. IDEF facilitates discussion and change.
  4. IDEF permits evolution.
  5. IDEF models business functions (activities) first.
  6. IDEF identifies the information needed and its flow.
  7. IDEF models the data needed to support the desired information.

2.6 TOOLS

The following tools were utilized in support of the STRAP process:
  1. Bpwin, Logic Works, Inc. - Used for the development of the Process Model.
  2. ERwin/Erx, Logic Works, Inc. - Used for the development of the Data Model.

Return to Previous Page Previous Section | Next SectionReturn to Previous Page