DATA MANAGEMENT FOR THE ALL-DOD CORE ARCHITECTURE DATA MODEL (All_CADM): 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 ANALYSES System Evaluation Division Robert P. McDonald-Walker (rwalker@ida.org, 703-845-2462)


OUTLINE: 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


Slide3: 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)


Slide4: FRAMEWORK 2.0 PRODUCTS


Slide5: FRAMEWORK 2.0 PRODUCTS (Cont’d)


DATA MODEL--A STRUCTURE FOR CAPTURING REQUIREMENTS: DATA MODEL--A STRUCTURE FOR CAPTURING REQUIREMENTS STRUCTURED REQUIREMENTS


RELATION OF DATA MODELS TO INTEROPERABILITY: 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


CADM SUPPORT FOR DoD ARCHITECTURE: 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)


OSD AND JOINT STAFF INTEREST IN CADM: 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


STATUS OF CADM: 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%)


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


Slide12: STANDARDIZATION POLICY


USE OF DOD DATA STANDARDS IN CADM: 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


Slide14: PROPOSAL PACKAGES PLANNED FOR CADM (41)


Slide15: DATA STANDARD VIEW OF CADM


MANAGING CADM IDENTIFIERS (Cont’d): MANAGING CADM IDENTIFIERS (Cont’d)


CADM CONFORMANCE: 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


ROLES OF CADM: 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


OSD POLICY ON CADM: 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(AT&L) 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)


Slide20: ADDITIONAL INFORMATION


MAJOR ALL-DOD CADM IMPLEMENTERS: 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)A&I: GIG 2.0 Architecture Joint Staff J8, USD(AT&L), 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)


CADM DEVELOPMENT STRATEGY: 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 (NATO’s 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)


Slide23: IER VIEW


CADM SUPPORT FOR DATA REPOSITORIES: 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


CADM SUPPORT FOR ARCHITECTURE FRAMEWORK DOCUMENT: 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


CADM SUPPORT FOR ENTERPRISE TAXONOMIES: 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-ASSOCIATION (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-ACTIVITY-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


CADM FOR ENTERPRISE TAXONOMIES (Cont’d): CADM FOR ENTERPRISE TAXONOMIES (Cont’d) Information Elements: INFORMATION-ELEMENT-ASSOCIATION 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)


DEVELOPING AN ARCHITECTURE TOOL KITCategories and Example COTS/GOTS: DEVELOPING AN ARCHITECTURE TOOL KIT Categories and Example COTS/GOTS


Slide29: OV-1 VIEW


Slide30: AV-1 (OVERVIEW & SUMMARY) VIEW


OTHER CADM SUPPORT: 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 DISA’s XML Repository)


FY02 ADDTIONS TO CADM: 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)


FY02 ADDTIONS TO CADM (Cont’d): FY02 ADDTIONS TO CADM (Cont’d) 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, TO&Es (ASA, AARMS) Circuit Switch Materiel, Software License, Materiel Custody, Node Port, POC Association (CIPO) System Detail, System Proponent, System Usage, Interoperability Document Type (LISI)


MARINE CORPS ARCHITECTURE: 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)


AIR FORCE POLICY ON ENTERPRISE ARCHITECTURES: 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 CIO’s 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


AIR FORCE ENTERPRISE ARCHITECTURE REPOSITORY: 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) OBJECTIVE AIR FORCE ENTERPRISE ARCHITECTURE RESPOSITORY CONTROLLED SUITE OF ARCH TOOLS CADM COMPLIANT COMPARABLE ARCHITECTURE PRODUCTS & INFORMATION AF ARCHITECUTE WEB SERVICES ENABLED BY ARCHITECTURE REPOSITORY HELP TO PRODUCE DISTRIBUTED VIA


DIAD: NAVY CADM: DIAD: NAVY CADM


RELATION OF CADM TO GIG 1.0 AND 2.0: 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 2001—almost 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


Slide39: 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


INTEGRATION OF ARMY AND NAVY CADMs INTO All_CADM: 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)


ARMY CADM (ARCADM): 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


ARCADM DEVELOPMENT: ARCADM DEVELOPMENT ARCADM began as ASA Data Model First published as part of CADM 2.0 Most was fully documented in OSD’s 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


Slide43: 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)


OUTSTANDING ISSUES FOR CADM IMPLEMENTERS: 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.


FY03 ANTICIPATED ADDITIONS—SOURCES : FY03 ANTICIPATED ADDITIONS—SOURCES 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


FY03 ANTICIPATED ADDITIONS—SOURCES (Cont’d) : FY03 ANTICIPATED ADDITIONS—SOURCES (Cont’d) 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


FY03 ANTICIPATED ADDITIONS—SOURCES (Cont’d) : FY03 ANTICIPATED ADDITIONS—SOURCES (Cont’d) Example capabilities-based architecture products uses (may imply new data requirements): CV-1, Prioritized Capability List—References 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 Profile—Mission objectives, threat situation, physical environment, US & Allied systems, design reference mission, similar to CONOPS or scenario based, OPLAN CV-4, Capability Metrics Description—Used to describe metrics for evaluating capabilities CV-5, Capability to Systems / Programs Traceability Matrix—Key product that leverages applicable operational and system views CV-6, Capability Evolution Description—Identifies when capabilities will be achieved; supports funding decisions CV-7, Integrated Capability Analysis Summary—Key end product that presents decision makers with results of analysis


MANAGING CADM IDENTIFIERS: 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


ARCHITECTURE AT CISA WORLDWIDE: 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


AUTOMATED SYSTEMS INTEGRATION MANAGEMENT (SIM) INTELLIGENCE DATABASE (ASID): 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)


CADM EVOLUTION AND DOCUMENTATION: 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.


TOP-LEVEL VIEW OF CADM: TOP-LEVEL VIEW OF CADM


Slide53: OVERVIEW—KEY ENTITIES AND RELATIONSHIPS


Slide54: ORGANIZATION-TYPE VIEW (PARTIAL)


EXAMPLE INTEGRATION (ARMY G-1): EXAMPLE INTEGRATION (ARMY G-1)


LISI View: LISI View


Slide57: NODE VIEW (PARTIAL)


Slide58: NETWORK VIEW (PARTIAL)


Slide59: NODE-ASSOCIATION VIEW (PARTIAL)


Slide60: IER VIEW


FY2000 INTEGRATION OF JCAPS I INTO CADM: 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


JCAPS I VIEW OF CADM: 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


DEVELOPING AN ARCHITECTURE TOOL KIT—OPTIONS: DEVELOPING AN ARCHITECTURE TOOL KIT—OPTIONS 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


STRUCTURE OF DoD ENTERPRISE MODEL: STRUCTURE OF DoD ENTERPRISE MODEL


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