Core architecture data model

The major elements of a core architecture data model are described as follows:[3]

• Core : The essential elements of architecture information that need to be developed, validated, and maintained and that should be sharable across architecture concerns to achieve architecture goals (e.g., interoperability, investment optimization).
• Architecture data : The possible piece-parts of architecture products and related analytical tools in a rigorous definition of the pieces (object classes), their properties, features, or attributes, and inter-relationships.
• Data model: A data model defines the objects of a domain, their inter-relationships, and their properties, normally for the purpose of a database design. There are three data model levels, from highest to lowest: conceptual, logical, and physical. Conceptual data models are the highest level. They model the user concepts in terms familiar to users. Details may be left out to improve clarity and focus with users. Logical models are more formal, often with considerations of unique data representation (non-redundancy or database normalization), emphasis on semantic well-definedness and exclusivity (nonoverlapping entities), and domain-level completeness. Logical data models need not commit to a specific Data Base Management System (DBMS). Physical data models are usually the most detailed and the level sufficient for database generation. The Physical model must contain all the information necessary for implementation. The Physical model often addresses performance considerations.[3]

The DoDAF incorporates data modeling (CADM) and visualization aspects (products and views) to support architecture analysis. The DoDAF's data model, CADM, defines architecture data entities, the relationships between them, and the data entity attributes, essentially specifying the “grammar” for the architecture community. It contains a set of “nouns,” “verbs,” and “adjectives” that, together with the “grammar,” allow one to create “sentences” about architecture artifacts that are consistent with the DoDAF. The CADM is a necessary aspect of the architecture and provides the meaning behind the architectural visual representations (products). It enables the effective comparing and sharing of architecture data across the enterprise, contributing to the overall usefulness of architectures. The CADM describes the following data model levels in further detail:[5]

• Conceptual : Models the user concepts in terms familiar to users
• Logical : More formal model that considers unique data representation, emphasis on semantic well-defineness and exclusivity, and domain-level completeness
• Physical : Models all the information necessary for database implementation

Data visualization is a way of graphically or textually representing architecture data to support decision-making analysis. The DoDAF provides products as a way of representing the underlying data in a user-friendly manner. In some cases, the existing DoDAF products are sufficient for representing the required information. Regardless of how one chooses to represent the architecture description, the underlying data (CADM) remains consistent, providing a common foundation to which analysis requirements are mapped.[5]

CADM Data Model Diagram Notation.[1]

As illustrated in the figure, boxes represent entities for which architecture data are collected (representing tables when used for a relational database); they are depicted by open boxes with square corners (independent entities) or rounded corners (dependent entities). The entity name is outside and on top of the open box. The lines of text inside the box denote the attributes of that entity (representing columns in the entity table when used for a relational database). The horizontal line in each box separates the primary key attributes (used to find unique instances of the entity) from the non-key descriptive attributes.[1]

The symbol with a circle and line underneath indicates subtyping, for which all the entities connected below are non-overlapping subsets of the entity connected at the top of the symbol. Relationships are represented by dotted (non-identifying) and solid (identifying) relationships in which the child entity (the one nearest the solid dot) has zero, one, or many instances associated to each instance of the parent entity (the other entity connected by the relationship line).[1]

An architecture data repository responsive to the architecture products of the DoDAF contains information on basic architectural elements such as the following:[3]

CADM Architecture Concepts Model.[3]

• Operational nodes may be organizations, organization types, and operational (human) roles. (A role may be a skill, occupation, occupational specialty, or position.).
• Operational activities including tasks defined in the Universal Joint Task List (UJTL).
• Information and data refers to information provided by domain databases and other information asset sources (which may be network centric) and systems data that implement that information. These information sources and systems data may define information exchanges or details for system interfaces.
• Systems nodes refers to nodes associated with physical entities as well as systems and may be facilities, platforms, units,3 or locations.
• Systems include families of systems (FOSs) and systems of systems (SOSs) and contain software and hardware equipment items.
• System functions are required by operational activities and are performed by one or more systems.
• Performance refers to performance characteristics of systems, system functions, links (i.e., physical links), computer networks, and system data exchanges.
• Standards are associated with technologies, systems, systems nodes, and data, and refer to technical standards for information processing, information transfer, data, security, and human computer interface.
• Technologies include future technologies and relates to systems and emerging standards concerning the use of such technologies.

The depicted (conceptual) relationships shown in this diagram include the following (among many others):[3]

• Operational nodes perform many operational activities.
• Operational nodes require information.
• Information are related to systems and implemented as data, which is associated with standards.
• Systems perform system functions.
• Systems have performance characteristics; both systems and performance may relate to a system function being performed.

With these relationships, many types of architectural and related information can be represented such as networks, information flows, information requirements, interfaces, and so forth.[3]

The counterpart to CADM within NASA is the NASA Exploration Information Ontology Model (NeXIOM), which is designed to capture and expressively describe the engineering and programmatic data that drives exploration program decisions. NeXIOM is intended to be a repository that can be accessed by various simulation tools and models that need to exchange information and data.[4]