1 / 65

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.

Thomas
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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@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 (Cont’d)

  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. DoD (Enterprise) Data Model DoD Data Architecture 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, TO&Es, 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 (Cont’d)

  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(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)

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

  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 (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)

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

  27. 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)

  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 DISA’s 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 (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)

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

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

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

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

  46. 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

  47. 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

  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)

More Related