DATA MANAGEMENT FOR THE ALL-DOD CORE ARCHITECTURE DATA MODEL (All_CADM)

1
DATA MANAGEMENT FOR THE ALL-DOD CORE ARCHITECTURE
DATA MODEL (All_CADM)

• Briefing to DAMA-NCR
• (Data Management Association, National Capitol
  Region)
• 11 March 2003
• INSTITUTE FOR DEFENSE ANALYSESSystem Evaluation
  Division
• Robert P. McDonald-Walker (rwalker_at_ida.org,
  703-845-2462)

2
OUTLINE

• DATA MODELING FOR DoD ARCHITECTURE FRAMEWORK
• CADM AS A DATA MODEL
• Role of Data Models
• Relation of Data Models to Interoperability
• CADM Support for Architecture
• Status of CADM
• Relation of CADM to Other Data Models
• DATA MANAGEMENT IN DoD
• OSD Policy on CADM
• Use of Standards in CADM
• Status of CADM Standardization
• DATA MANAGEMENT ISSUES
• Management of Identifiers
• Primary Role Design or Exchange Standard
• CADM Conformance

3
WHAT IS AN ARCHITECTURE

• DoD DEFINITION
• Structure of components, their relationships, and
  the principles and components governing their
  design and evolution over time (C4ISR
  Architecture Framework Version 2.0, December
  1997)
• DESCRIPTION
• Representation of a defined domain- In terms
  of component parts- What those parts do- How
  those parts relate- What are the rules and
  constraints
• Relation of components to requirements,
  standards, organizations, capabilities, and costs
• USES
• System development
• System of systems management
• Interface specification and control
• Interoperability analyses
• Resource planning and programming (budget
  decisions)

4
FRAMEWORK 2.0 PRODUCTS
5
FRAMEWORK 2.0 PRODUCTS (Contd)
6
DATA MODEL--A STRUCTURE FOR CAPTURING REQUIREMENTS
STRUCTURED REQUIREMENTS
7
RELATION OF DATA MODELS TO INTEROPERABILITY

• BASIC INTEROPERABILITY
• Exchange of information that preserves meaning
  and relationships
• OPTIONS FOR INFORMATION EXCHANGE
• Voice, electronic mail, facsimile
• Formatted messages, XML
• Files
• Database-to-database (with/without dynamic user
  constraints)
• DATA MODEL ROLES
• Specifying meaning and relationships of
  information elements
• Providing basis for database design and
  implementation
• Providing basis for (partial) database
  replication between systems
• Identifying and structuring data elements for
  standardization

8
CADM SUPPORT FOR DoD ARCHITECTURE

• Captures mission area characteristics
• Holds entirety of Universal Joint Task List
  (UJTL) and Service-defined extensions (e.g., AF
  Task List, AFDD 1-1, Aug 98)
• Captures key requirements
• Tables of organization and equipment (actual
  planned)
• Information exchange requirements (IERs)
• Operational requirements underlying activity
  models
• Captures information technology standards
• Data link standards
• Other information exchange standards
• DoD and other data standards (e.g., holds
  entirety of DoD Data Dictionary System, DDDS)
• Captures technology and standards forecasts
• Holds entirety of the Joint Technical
  Architecture (JTA)
• Specifies minimum detail required to reuse and
  exchange architecture data
• Includes core data for configuration management
  (Army SOSA, ASID)

9
OSD AND JOINT STAFF INTEREST IN CADM

• INTEGRATING MISSION-AREA ARCHITECTURES
• Achieving interoperability
• Consistently expressing common elements of
  concepts and requirements
• Ensuring operational concepts and architectures
  are mutually supporting
• Finding consistent and reusable ways to structure
  data underlying architectures
• JOINT STAFF (JWCA) APPROACH
• Identify attributes that describe how concepts
  attain goals
• Decompose attributes to level needed for
  expression in architectures
• Modify the CADM as needed to represent those
  attributes
• Identify metrics
• Validate approach through testing, modeling
  simulation, experimentation, and executable models

10
STATUS OF CADM

• Goal Interoperability of architecture tools and
  DoD-wide exchange of architecture data
• Fully attributed IDEF1X data model
• Extends DoD-approved data standards
• Captures and structures data requirements from
  Architecture Framework
• Designed to serve as a starting point for C/S/A
  architectures
• Usability limited by complexity 612 entities
  and 2,056 attributes
• Documented in 64 subject area views (26 for
  architecture products)
• DoD-wide data standardization nearly complete
  (95)

11
RELATIONS AMONG TYPES OF DoD DATA MODELS
DoD Data Dictionary System (DDDS)
Architecture Tools
Operational Systems
All-DoD Core Architecture Data Model
(All_CADM) Army CADM DON Architecture Database
(DIAD)-Navy CADM
C2 Core Data Model (C2CDM) ATCCIS Generic Hub
Data Model (GH) Land C2 Info. Exch Data Model
(LC2IEDM) Army Integrated Core Data Model (AICDM)
Combatant Cmd/Service-Unique Architecture
Tools Defense Arch Repository Management
System Army Systems Architecture Database Army
Architecture Repository Management System
(IERs, TOEs, Activity Models/Operational
Arch.) Installation Information Infrastructure
Architecture Global Information Grid (GIG)
Architecture Combat Identification (CID)
Architecture
Joint Common Database (JCDB) Army Battle Command
Systems (ABCS)
C4ISR Architecture Framework 2.0 (Dec 97) DoD
Architecture Framework 1.0 (Jan 03)
12
STANDARDIZATION POLICY
13
USE OF DOD DATA STANDARDS IN CADM

• When first defined, 109 Entities, 479 attributes
  of CADM were already approved--needed no change
  (21)
• Data standardization for CADM as of Jan 03
• 31 proposal packages approved
• 1 not approved (12 data elements not approved,
  9 archived)
• 5 proposal packages in DoD 8320.1 approval
  procedures
• 1 proposal package in preliminary FDAd
  coordination (Arch V)
• 3 more proposal packages planned
• 90 of CADM entities and attributes are now DoD
  data standards
• 582 of 658 entities
• 1,987 of 2,188 attributes
• Completion of CADM standardization planned for
  Apr 03

14
PROPOSAL PACKAGES PLANNED FOR CADM (41)
15
DATA STANDARD VIEW OF CADM
16
MANAGING CADM IDENTIFIERS (Contd)
17
CADM CONFORMANCE

• CADM conformance means the following
• Conforming model to be based on a subset of the
  CADM (not all attributes of selected entities are
  required)
• Extensions of that subset are expected (but
  should not be redundant with elements of the CADM
  itself) extensions that could apply to the CADM
  for general use should be proposed
• Agreed datatypes and coded domains should be used
• POCs should be identified and consulted when
  generating instances of keys (to avoid redundancy
  and non-uniqueness)
• Primary key attributes for entities taken from
  the CADM should be identical with or directly
  derivable from the primary key attributes
  specified in CADM (alternate keys may be used but
  CADM keys need to be preserved)
• The goal is to ensure fully faithful information
  transfer among databases, which cannot happen if
  the primary keys of one database have no
  correlation to the primary keys of another
  database for the same entity
• Keys for authoritative data source instances
  should be retained to enable effective updates
  from those sources

18
ROLES OF CADM

• CORE ARCHITECTURE DATA MODEL
• Structures meaning and relationships of reusable
  data
• Specifies data requirements at implementation
  level
• Integrates data requirements for operational,
  systems, and technical views of architectures
• Promotes interoperability among architecture
  effects and between architecture tools
• OPTIONS FOR USE
• Building architecture databases for data-driven
  architecture products
• Configuration management of how procured items
  will be integrated into operational units
• Standardizing data for architectures
• Providing exchange standards for moving data
  among tools
• Enabling users other than developers to extract
  data and build specialized architecture products

19
OSD POLICY ON CADM

• C4ISR Framework 2.0 mandated (February 1998) for
  applicable DoD architectures (CADM was cited but
  not mandated)
• Joint Staff J-6, ASD(C3I), USD(ATL)
• DoD Architecture Development Policy planned to be
  issued as DoD Instruction 8370.aa
• DoD Architecture Framework 1.0 planned for FY2003
• Planned to be issued in 2 volumes as DoD Manual
  8370.1-M with Deskbook CD-ROM
• All-DoD CADM planned to be issued as a DoD
  Standard 8370.1-STD
• Mandates currently exist for CADM by
• Army CIO (implemented in Army Systems
  Architecture and AARMS)
• Navy CIO (implemented in DIAD)
• OSD CIO for GIG 2.0 and JCAPS II (GIG Data
  Repository)
• Joint Staff J8 for Combat Identification (CID)
  Architecture
• Various levels of support for wide use of CADM
• SOUTHCOM (J85), SOCOM, STRATCOM
• US Army Command Command Interoperability Program
  Office (CADM Visualization Tool)
• DoD Financial Management Enterprise Architecture
  (support CADM)
• Defense Modeling and Simulation Office (e.g.,
  NETWARS)

20
ADDITIONAL INFORMATION
21
MAJOR ALL-DOD CADM IMPLEMENTERS

• US Army TRADOC (at US Army Signal Center, Fort
  Gordon, GA) for Army Architecture Repository
  Management System (AARMS)
• US Army PEO-C3T (at Fort Monmouth, NJ) for Army
  Systems Architecture (ASA electronic data
  exchanges with AARMS)
• Department of the Navy CIO DON Integrated
  Architecture Database (DIAD)
• OASD(C3I)AI GIG 2.0 Architecture
• Joint Staff J8, USD(ATL), and ASD(C3I)C3
  Combat Identification (CID) Architecture
• Combatant Command Interoperability Program Office
  (CIPO) at Fort Monmouth for SOUTHCOM
• Army G-1 Architecture Database Systems of
  Systems Architecture (SOSA)
• Army Systems Integration Database (ASID)

22
CADM DEVELOPMENT STRATEGY

• USE DOD STANDARD ATTRIBUTES AND ENTITIES WHERE
  POSSIBLE
• WHERE C2 CORE (NOW ARMY INTEGRATED CORE DATA
  MODEL OR AICDM) AND CADM OVERLAP, ENSURE THE
  OVERLAP CONSISTS OF IDENTICAL ENTITIES AND
  ATTRIBUTES
• Ensures CADM conforms to ATCCIS Generic Hub
  (NATOs LC2IEDM) where they overlap
• MAINTAIN CADM AS A CORE BY GETTING AGREEMENT FROM
  TWO OR MORE IMPLEMENTING ORGANIZATIONS (C/S/As)
• INCLUDE ALL OF ARCADM (formerly, ASA Data Model)
• Parts of ARCADM not agreed for CADM 2.0 were
  included in an annex of CADM 2.0 final report and
  in the Erwin diagram as a separate view all now
  in the All-DoD CADM (All_CADM)
• EXTEND AS REQUIRED TO MEET EMERGING ARCHITECTURE
  DATA REQUIREMENTS (e.g., for GIG 2.0)
• SUPPORT INTEGRATED ARCHITECTURE DATABASES
  REPOSITORIES (MAY BE CENTRALIZED OR DISTRIBUTED)

23
IER VIEW
24
CADM SUPPORT FOR DATA REPOSITORIES

• CADM specifications define at both the logical
  and physical level the structure of an
  architecture data repository
• Reference data (missions, tasks, organizations,
  organization types, facilities, materiel
  instances, material classes) common to all
  architectures
• Architecture-specific data and their
  relationships to reference data (planned as well
  as actual capabilities architecture
  alternatives)
• Details include data types, domains, short
  physical names, null options, and XML tags, as
  well as definitions
• CADM conformance comprises the minimum rules to
  enable conformant databases to exchange data
  electronically
• Implementors choose those parts of the CADM that
  apply
• Implementors extend the core from the CADM as
  needed
• Implementors cooperate on key assignments
• Implementations can be relational, object
  oriented, or other
• Example data repositories based on or conformant
  to CADM
• DoD Data Dictionary System (data standards)
• Army Architecture Repository Management System
  (OPFAC requirements development, systems
  architecture, C4 acquisition)
• GIG Architecture Database CID Architecture
  Database

25
CADM SUPPORT FOR ARCHITECTURE FRAMEWORK DOCUMENT

• CADM is a core data model, meant to be extended
  as required
• CADM supports all 1,299 data requirements from
  C4ISR Architecture Framework 2.0 (FW 2.0, Dec
  97), including Product Attribute Table (Appendix
  A)
• CADM will be extended in FY03 to capture
  additional requirements from the DoD Architecture
  Framework 1.0 (e.g., SV-TV bridge)
• CADM documentation includes matrix relating each
  CADM entity with all applicable FW 2.0
  architecture products
• Implementors are cooperating in managing
  identifiers
• CADM supports Service-specific products, such as
  the following for Army Systems Architecture
• Horseblanket
• Core Systems and Quantities Report
• All Systems and Quantities Report
• OPFAC Rule Report

26
CADM SUPPORT FOR ENTERPRISE TAXONOMIES

• Taxonomies relate two instances, often
  hierarchically (tree diagram) may be viewed as a
  set of folders and subfolders
• DIAD has taxonomies for 10 groups of reference
  data, noted below
• Operational Nodes
• ORGANIZATION-ASSOCIATION and ORGANIZATION-TYPE-ASS
  OCIATION (for operational elements)
• NODE-ASSOCIATION (for specific nodes, each of
  which represents an operational element,
  operational facility, command element, etc.)
• Process Activities PROCESS-ACTIVITY-ASSOCIATION
• For TASKs (e.g., in UJTL) TASK-ASSOCIATION (in
  GIG and DIAD, each TASK corresponds to a unique
  PROCESS-ACTIVITY using PROCESS-ACTIVITY-TASK)
• For ACTIONs (e.g., EVENTs) ACTION-ASSOCIATION
• For ACTIVITY-MODELs ACTIVITY-MODEL-PROCESS-ACTIV
  ITY-ASSOCIATION (e.g., for node trees in IDEF0)
• System Functions PROCESS-ACTIVITY-ASSOCIATION
  (in conjunction with SYSTEM-PROCESS-ACTIVITY if a
  specific system is cited), since each
  SYSTEM-FUNCTION is a subtype of PROCESS-ACTIVITY
• Triggers/Events ACTION-ASSOCIATION

27
CADM FOR ENTERPRISE TAXONOMIES (Contd)

• Information Elements INFORMATION-ELEMENT-ASSOCIA
  TION
• Platforms, Facilities, Units, Locations
• MILITARY-PLATFORM-ASSOCIATION
• FACILITY-ASSOCIATION
• ORGANIZATION-ASSOCIATION (each UNIT is assigned a
  unique ORGANIZATION Identifier)
• NODE-ASSOCIATION (when NODE denotes specific
  location)
• System
• SYSTEM-TYPE-ASSOCIATION (among general classes)
• SYSTEM-ASSOCIATION (among versions of a SYSTEM)
• NODE-SYSTEM-ASSOCIATION (among instances of
  NODE-SYSTEM, each specifying a SYSTEM at a
  specific NODE
• Technical Standards AGREEMENT-ASSOCIATION
  (since IT-STANDARD is a subtype of AGREEMENT)
• Performance attributes CAPABILITY-ASSOCIATION
• Technologies TECHNOLOGY-ASSOCIATION
• Data AGREEMENT-ASSOCIATION (since
  MESSAGE-STANDARD and STANDARD-TRANSACTION are in
  subtype hierarchy of AGREEMENT)

28
DEVELOPING AN ARCHITECTURE TOOL KITCategories
and Example COTS/GOTS
29
OV-1 VIEW
30
AV-1 (OVERVIEW SUMMARY) VIEW
31
OTHER CADM SUPPORT

• Implementations SQL Server 2000, MS Access,
  Oracle
• Separate physical schema has been developed for
  Oracle with Oracle datatypes and globally-unique
  relationship names, used by GIG (and MS
  Access-based schemas)
• Identifiers 32-bit integers (migration to
  64-bit integers recommended for end FY03)
• Common set of XML tags for architecture community
  of interest (registered in DISAs XML Repository)

32
FY02 ADDTIONS TO CADM

• Operational Capability (for GIG defined by
  tasks, process activities)
• IERs
• Information Elements between Organization Types
  (CADM 2.0)
• Information Elements between Organizations as
  well as Organization Types for CRDs ORDs
  (6212.01B)
• Information Elements between Process Activities
  (DIAD/DON CIO)
• Improve data elements (DIAD/DON CIO AARMS)
• Transactions across interfaces (Army G-1)
• Mission Threads
• Among operational elements through IERs (CADM
  2.0)
• Among process activities in an Activity Model
  (for GIG 2.0)
• Among systems through interfaces (Army G-1)
• Amendments for storing entirety of JTA and UTJL
  with Service extensions and Joint Mission Areas
  (Technical Guideline Element, for CID
  Architecture)
• Architecture resourcing (instances of systems,
  materiel, costs, shortfalls, IP addresses)

33
FY02 ADDTIONS TO CADM (Contd)

• Icon Catalog (consistent icons for System.
  Materiel-Item, etc., for AARMS and ASA)
• Communication Circuit Thread Element,
  Communication System Use Detail, Document
  Message, IER Failure Impact Detail, IT
  Registration, Military Platform, Network Detail,
  Antenna Type, Satellite (GIG)
• Data Standards (especially complete metadata from
  DDDS)
• Domain specifications (Air Force AETC)
• Extensions for Nodes, Networks, Communications,
  Interfaces, TOEs (ASA, AARMS)
• Circuit Switch Materiel, Software License,
  Materiel Custody, Node Port, POC Association
  (CIPO)
• System Detail, System Proponent, System Usage,
  Interoperability Document Type (LISI)

34
MARINE CORPS ARCHITECTURE

• MEF/MAGTF Fires Operational Architecture
• Tasks included in UJTL and UNTLs, as well as
  specific training tasks
• AV-1, AV-2
• OV-1, Multiple OV-2s (e.g., NSFS), OV-3 (embedded
  as drill-down multiple need lines between nodes
  for OV-2)
• OV-5 (e.g., for FSCC), linked to nodes in OV-2
• Links to definitions, missions, references,
  tasks, operational facilities
• Documents current concepts and processes,
  especially for training
• Highlights communication requirements
• Planned links to systems data in FY03
• CADM-compliant database (uses netViz)

35
AIR FORCE POLICY ON ENTERPRISE ARCHITECTURES

• USAF Enterprise Architectures
• Visualizing mission information relationships
• Promoting interoperability
• Synchronizing planning with requirements and
  acquisition management
• Integrate combat operations with combat and
  business support elements
• Mission Area Operational Architectures
• Developed by major commands and HQ functional
  proponents
• Integration oversight by AF/XO and AF/XI
• System and Technical Architectures
• Developed by acquisition agents
• Oversight by AF/XI
• Facilitating architecture product development
  USAF CIOs Chief Architect Office (CAO) POC
  Jim Thilenius

Ref Air Force Policy on Enterprise
Architecting, Gen J.P. Jumper, USAF Chief of
Staff, and Hon. J.G. Roche, Secretary of Air
Force, 6 August 2002
36
AIR FORCE ENTERPRISE ARCHITECTURE REPOSITORY

• Data-based architecture products, with potential
  to
• Exploit existing tools, including visualization
  tools for CADM-based architecture products
• Exploit exchange of data using CADM-based XML
  tagged data
• Enable creation of architecture product
  containing all the CADM data on which the product
  is built (XML tagged data)

DISTRIBUTED VIA
OBJECTIVE
HELP TO PRODUCE
CONTROLLED SUITE OF ARCH TOOLS
AIR FORCE ENTERPRISE ARCHITECTURE RESPOSITORY
ENABLED BY ARCHITECTURE REPOSITORY
COMPARABLE ARCHITECTURE PRODUCTS INFORMATION
AF ARCHITECUTE WEB SERVICES
CADM COMPLIANT
37
DIAD NAVY CADM
38
RELATION OF CADM TO GIG 1.0 AND 2.0

• All of the architecture products depicted in GIG
  1.0 are fully supported by CADM 2.0
• Initial GIG 2.0 data requirements analysis by IDA
  in 2001almost all of the GIG 2.0 data
  requirements are fully supported by the CADM 2.0
• 13 entities from CADM extensions needed
• -- 5 from Army CADM and DoD data standards
• -- 5 others from Army CADM
• -- 1 from Navy CADM (DIAD Data Model)
• -- 2 from JCAPS extension to CADM (Dec 2000)
• Two data requirements in GIG 2.0 (relating to
  Personnel Skills) need 2-4 new entities not
  already defined in the CADM or known extensions
• DIAD assessment Any deficiencies for supporting
  GIG 2.0 in DIAD could be easily resolved by
  implementing 14-16 additional entities

39
WHY INVEST IN A DATA MODEL?

• TO CAPTURE DoD-WIDE DATA REQUIREMENTS IN A
  CONSISTENT WAY
• TO PROVIDE AN INTEGRATED VIEW OF HOW C2 DATA
  REQUIREMENTS ARE MET BY ENTERPRISE-LEVEL DATA
  STANDARDIZATION
• TO IDENTIFY AND FIX DEFICIENCIES OF STANDARD DATA
  (E.G., FOR C2 SYSTEMS)
• TO IMPROVE QUALITY AND ACCESSIBILITY OF
  DATABASES
• TO IMPROVE INTEROPERABILITY STANDARDS

40
INTEGRATION OF ARMY AND NAVY CADMs INTO All_CADM

• DON Integrated Architecture Database (DIAD) is
  Navy CADM
• 1,287 of 1,746 DIAD owned and foreign key
  attributes (74) identical (in name) to those in
  comparable entities in CADM as extended by Army
• Further work in aligning column names, datatypes,
  and domains has begun (alignment of table names
  is complete)
• Integration with Army CADM (ARCADM) complete a
  major subset of All_CADM
• ARCADM has 481 of 612 All_CADM entities (79
  percent)

41
ARMY CADM (ARCADM)

• SUPPORTS CONCURRENT DEVELOPMENT OF ARMY
  ARCHITECTURE TOOLS
• AARMS
• -- Replaces C4RDP and AOA Repository
• -- Incorporates C4 Requirements Information
  Management System-Warrior Reachback (CRIMS-WARR)
• Army Systems Architecture (ASA)
• -- ASA Conceptual (2.0 architectures formerly
  ASA-C) focused on requirements (SIGCEN)
• -- ASA Detailed (3.0 architectures formerly
  ASA-D) focused on C4 system/equipment acquisition
• I3A focused on current and planned C4
  infrastructure at bases and installations in US
  and elsewhere
• Includes separate configuration-managed physical
  schema for implementations using various DBMSs
• Widespread use of 32-bit-integer primary key
  identifiers (migration to 64-bit integers is
  planned for end FY03)
• Integration with Army G-1 Architecture Database
  underway

42
ARCADM DEVELOPMENT

• ARCADM began as ASA Data Model
• First published as part of CADM 2.0
• Most was fully documented in OSDs CADM 2.0
  report (Dec 98)
• Extensions were identified in annex to CADM 2.0
  report
• Separate physical schema (PS_ARCADM) begun April
  1999 logical model continues to be embedded
  within CADM (now called the All_CADM)
• Major integration with C4RDP completed August
  1999
• Baseline 2.0 PS_ARCADM issued 26 October 2000
• Baseline 3.0 PS_ARCADM issued 5 October 2001

43
ARCADM ARCHITECTURE PRODUCTS

• Current ARCADM (PS 3.0) supports five Army-unique
  products
• Horseblanket Chart
• Core Systems and Quantities
• All Systems and Quantities
• Nodal Diagrams (netViz)
• OPFAC Rule Report
• Current ARCADM supports 13 products defined in
  Framework 2.0
• AV-1, 2
• OV-1, 2, 3, 5
• SV-1, 2, 3, 4, 5, 6
• TV-1, 2
• Annex C of AEADP identifies three classes of
  entities needed to support these products, as
  well as identifying mandatory attributes
• 1 Essential (mandatory for AEADP
  implementations)
• 2 Desirable (must be included early data search
  but not deemed essential)
• 3 Applicable)

44
OUTSTANDING ISSUES FOR CADM IMPLEMENTERS

• Sources CADM does not directly address
  identification management of authoritative data
  sources (ADSs), but use of CADM (DoD standard)
  identifiers could help
• Identifiers Not all CADM implementors are
  making use of centralized assignment of blocks of
  identifiers
• Implementation Guidance Many implementation
  decisions are implicit in any CADM-compliant
  database these need to be documented and made
  available to all implementors
• Rules for rollup/drill down (implicit
  associations), such as for doing consistent
  equipment counts
• Import/Export Mechanisms Use of CADM-based XML
  tags is recommended but not yet widely used
• Update Imports CADM compliance recommends
  maintaining the native keys of data so that
  updates and deletes can be recognized
• Taxonomies Not all implementers see a
  requirement for relying on a taxonomy multiple
  taxonomies exist
• CADM is inherently complex Its effective use
  requires an investment and collaboration with
  other implementors
• Multiple Options Exist in CADM for many
  architecture products.

45
FY03 ANTICIPATED ADDITIONSSOURCES

• Levels of Information System Interoperability
  (LISI)
• Additions to JTA 4.0 (as they emerge)
• DoD CIO Information Technology Architecture (ITA)
• Net-Centric Operations/Warfare (NCOW) Reference
  Model
• -- Architecture products (e.g., common glossary)
• -- Programmatic Evaluation Criteria (e.g., for
  NetOps)
• DoD TRM
• GIG 2.0 (enterprise IT infrastructure)
  requirements repository
• DoD Architecture Framework 1.0
• Key Interface Point (KIP) profiles
• CISA architecture products
• Joint Staff operational architectures

46
FY03 ANTICIPATED ADDITIONSSOURCES (Contd)

• Air Force, Navy, Marine Corps, Army, SOF
  enterprise architectures
• Examples AEA Development Plan implementation
  guidance
• Joint Staff-OSD sponsored/managed architectures
  JTAMD operational, SIAP system, CID architectures
• Financial Management Enterprise Architecture
  (FMEA)
• Federal Enterprise Architecture
• Modeling simulation data requirements (e.g.,
  NETWARS)
• Architecture development and display tools (e.g.,
  using CADM-based XML tags)
• Concepts for better associating architecture data
  between OV SV
• Data requirements underlying communication
  architecture views

47
FY03 ANTICIPATED ADDITIONSSOURCES (Contd)

• Example capabilities-based architecture products
  uses (may imply new data requirements)
• CV-1, Prioritized Capability ListReferences to
  Strategic Plan, CONOPS, CRD, ORD, Task List,
  Capability Decision Packages
• CV-2, Capability to Requirements and/or Tasks
  Matrix Maps capabilities to applicable
  requirements and/or tasks and activities
• CV-3, Operational ProfileMission objectives,
  threat situation, physical environment, US
  Allied systems, design reference mission, similar
  to CONOPS or scenario based, OPLAN
• CV-4, Capability Metrics DescriptionUsed to
  describe metrics for evaluating capabilities
• CV-5, Capability to Systems / Programs
  Traceability MatrixKey product that leverages
  applicable operational and system views
• CV-6, Capability Evolution DescriptionIdentifies
  when capabilities will be achieved supports
  funding decisions
• CV-7, Integrated Capability Analysis SummaryKey
  end product that presents decision makers with
  results of analysis

48
MANAGING CADM IDENTIFIERS

• 231 identifiers are managed for CADM
  implementations
• Central control through CADM Entity Owner (DoD
  organization)
• CADM Entity Owner allocates blocks on request to
  implementers
• Implementer assigns instances from each block
• Entity instances with assigned identifiers are
  shared with CADM Entity Owner
• CADM Entity Owner makes available the combined
  list of instances
• Implementors make a good faith effort to search
  already assigned identifiers before assigning a
  new one
• Blocks of 32-bit identifiers are currently being
  assigned (4 billon available)
• Blocks of 64-bit identifiers will use Enterprise
  Identifiers based on the 32-bit seed server (Army
  ODISC4 POC Bruce Haberkamp, CDAd)
• Each seed is assigned on request to a DoD
  organization
• Organization manages assignment of the remaining
  32 bits
• Organizations requiring more than 4 billion
  instances request additional seeds

49
ARCHITECTURE AT CISA WORLDWIDE

• CONTEXT FOR ARCHITECTURE
• Listening, seeing, taking initiative
• Best done in community, diverse community
• Names labels are important
• ESSENTIAL ELEMENTS OF ARCHITECTURE
• Managing change
• Searching for identifying meaning structure
• -- Recognizing commonality
• -- Language contains meaning bias
• -- No idea is too old to be reused
• Need for authoritative sources
• Requirements driven but capabilities focused
• Time is an ally not just a constraint
• Each architecture is an interpretation of meaning
  structure within a specific context

50
AUTOMATED SYSTEMS INTEGRATION MANAGEMENT (SIM)
INTELLIGENCE DATABASE (ASID)

• Centralized information management, IT
  management, decision making (includes asset
  management, life-cycle replacement)
• SQL Server 2000
• Web interface using ASP.NET (on SIPRNet)
• Graphic displays using netViz
• Configuration management data (asset visibility)
• Cost data for hardware software (feeds PPBS)
• System data (training, h/w, s/w, manpower,
  maintenance)
• Automated collection tool interface (SMS)
• CADM-compliant using CADM identifiers as
  alternate keys
• Provided CADM requirements for POC, SYSTEM,
  SYSTEM-MIGRATION, MATERIEL, HAND-RECEIPT,
  SOFTWARE-LICENSE
• Sponsor Army G-2 (POC CJ Cooper)
• Developer INSCOM (POC John Nixon)

51
CADM EVOLUTION AND DOCUMENTATION

• CADM 1.0 (Sep 97, Based on C4ISR Architecture
  Framework 1.0)
• CADM 2.0 (Nov 98, Based on C4ISR Architecture
  Framework 2.0)
• All-DoD CADM (All_CADM), Draft, 11 October 2002
• 612 entities
• 2,056 owned attributes (3,496 with foreign keys
  counted)
• All_CADM Specifications (distributed bimonthly)
• ERwin 3.5.2 IDEF1X data model diagram (contains
  metadata for both logical and physical views)
• Entity, attribute, and relationship
  specifications extracted from ERwin file
  detailed change control (since Jan 02)
• Specifications include domain values and
  meanings, datatypes, and physical (access) names
• Mapping CADM entities to DoD Architecture
  Framework
• All metadata are in the DDDS ERwin files carries
  the DDDS counter, version, and approval status
  for entities and attributes
• Configuration management at IDA

Meets all 1,299 data requirements from main body
and Annex A of FW 2.0.
52
TOP-LEVEL VIEW OF CADM
53
OVERVIEWKEY ENTITIES AND RELATIONSHIPS
54
ORGANIZATION-TYPE VIEW (PARTIAL)
55
EXAMPLE INTEGRATION (ARMY G-1)
56
LISI View
57
NODE VIEW (PARTIAL)
58
NETWORK VIEW (PARTIAL)
59
NODE-ASSOCIATION VIEW (PARTIAL)
60
IER VIEW
61
FY2000 INTEGRATION OF JCAPS I INTO CADM

• Defined new JCAPS data model as a view of the
  CADM
• Build on Army extensions to CADM developed in
  1998-2000
• -- Army Integrated Architecture Data Model
  (formerly ASA View of CADM)
• -- Army CADM Physical Schema (Baseline 2.0, 26
  Oct 2000)
• Build on Navy extensions to CADM developed in
  1997-2000
• -- Navy Architecture Database (1997-1998)
• -- DON Integrated Architecture Data Model
  (1999-2000)
• Added implementation details for use in a
  physical schema
• Supported data requirements from NETWARS, C/S/A
  architectures, and 1999 DSWG recommendations
• Included 143 entities
• 122 from CADM and recent CADM extensions
• 21 are JCAPS-unique
• 90 attributes derived from JCAPS added to CADM
  extensions

62
JCAPS I VIEW OF CADM

• Selected 122 entities from CADM and CADM
  extensions
• 97 from CADM
• 10 from CADM extensions defined in Dec 98 CADM
  2.0 report (e.g., COMM-LINK, ORGANIZATION-POINT,
  MATERIEL)
• 14 from Army CADM
• 1 from DIAD/Navy CADM (others are already in
  CADM)
• Selected 21 JCAPS entities with 145 attributes to
  be added to CADM
• COMM-LINK-TYPE
• COMM-CIRCUIT, COMM-CIRCUIT-TYPE, COMM-CHANNEL
• INTERFACE, INTERFACE-TYPE, SYSTEM-INTERFACE-TYPE
• USER-DEFINED-PROPERTY entities
• Selected 90 additional JCAPS attributes to be
  added to CADM entities

63
DEVELOPING AN ARCHITECTURE TOOL KITOPTIONS

• Repository management JCAPS II, DIAD, AARMS,
  LISI, DDDS (follow-on)
• Building databases schemata ERwin, Oracle,
  SQL Server 2000, MS Access
• Building architectures System Architect, Slate,
  Rational Rose, BPwin
• Visualization Visio, netViz, CIPO Visualization
  Tool (XML)
• Export/import mechanisms CADM-based XML tags
  MS Access, spreadsheets
• Transformations CACHE
• Modeling simulation NETWARS
• J6 planning/capital investment JEIAPS, MEDIS,
  ASID
• Assessment criteria TBD (cost, CADM-compliance,
  auto discovery, direct interface to authoritative
  data sources, Web enabled, security
  certification, information assurance)
• Foundation CADM

64
STRUCTURE OF DoD ENTERPRISE MODEL
65
C2 DATA MODEL EVOLUTION
ATCCIS
NATO
DISA/JIEO
JOINT STAFF
ARMY
OSD
DM
ARCH
92
25/3
GH1 (8/93) P-2897
93
C2CDM V1.0
EDM 1.0
JOPES LDM
DDM 2.0
GH2 (8/94) P-3012
FSDM (8/94) P-2895
25/4
DDM 3.0 DDM (4/94)
JOPES SM
94
C2CDM V2.0
14/1
GCCS P-3047 (12/95)
95
14/2
DDM (3/95)
14/3 E1
GH3 V1.0 (12/96)
V2.1 (3/96) V2.2 (7/96)
96
DDM (1/96)
FW 1.0
P-3125 (2/96)
NC3DM
SAASE
GH3 V2.0 (9/97) P-3398
14/3 D2
V2.3 (1/97) V2.4 (12/97)
97
CADM 1.0 9/97
JCAPS
FW 2.0
GH3 V3.0 (7/98)
V2.5 7/98 V2.6 12/98
P-3433 (11/98)
98
ASADM 12/98
CADM 2.0 12/98
GH4 E1 (9/99)
99
DSWG
AICDM
V2.7 (12/99)
ASA PS
14/3 D3
DDA
GH4 E2 (3/00)
00
All_CADM
01
AARMS
LC2IEDMADatP-32
02