Core architecture data model
Core architecture data model in enterprise architecture is a logical data model of information used to describe and build architectures.
The CADM is essentially a common database schema, defined within the US Department of Defense Architecture Framework DoDAF. It was initially published in 1997 as a logical data model for architecture data.
Overview
Core architecture data model is designed to capture DoDAF architecture information in a standardized structure. CADM was developed to support the data requirements of the DoDAF. The CADM defines the entities and relationships for DoDAF architecture data elements that enable integration within and across architecture descriptions. In this manner, the CADM supports the exchange of architecture information among mission areas, components, and federal and coalition partners, thus facilitating the data interoperability of architectures.CADM is a critical aspect of being able to integrate architectures in conformance with DoDAF. This includes the use of common data element definitions, semantics, and data structure for all architecture description entities or objects. The use of the underlying CADM faithfully relates common objects across multiple views. Adherence with the framework, which includes conformance with the currently approved version of CADM, provides both a common approach for developing architectures and a basic foundation for relating architectures. Conformance with the CADM ensures the use of common architecture data elements.
History
The CADM was initially published in 1997 as a logical data model for architecture data. It was revised in 1998 to meet all the requirements of the C4ISR Architecture Framework Version 2.0.1 As a logical data model, the initial CADM provided a conceptual view of how architecture information is organized. It identified and defined entities, attributes, and relations. The CADM has evolved since 1998, so that it now has a physical view providing the data types, abbreviated physical names, and domain values that are needed for a database implementation. Because the CADM is also a physical data model, it constitutes a database design and can be used to automatically generate databases.The CADM v1.01 was released with the DoD Architecture Framework v1.0 in August 2003. This DoDAF version restructured the C4ISR Framework v2.0 to offer guidance, product descriptions, and supplementary information in two volumes and a desk book. It broadened the applicability of architecture tenets and practices to all mission areas rather than just the C4ISR community. This document addressed usage, integrated architectures, DoD and Federal policies, value of architecture, architecture measures, DoD decision support processes, development techniques, analytical techniques, and the CADM v1.01, and moved towards a repository-based approach by placing emphasis on architecture data elements that comprise architecture products.
The CADM v1.5 was pre-released with the DoD Architecture Framework, v1.5 in April 2007. The DoDAF v1.5 was an evolution of the DoDAF v1.0 and reflects and leverages the experience that the DoD components have gained in developing and using architecture descriptions. This transitional version provided additional guidance on how to reflect net-centric concepts within architecture descriptions, includes information on architecture data management and federating architectures through the department, and incorporates the pre-release CADM v1.5, a simplified model of previous CADM versions that includes net-centric elements. Pre-release CADM v1.5 is also backward compatible with previous CADM versions. Data sets built in accordance with the vocabulary of CADM v1.02/1.03 can be expressed faithfully and completely using the constructs of CADM v1.5.
Note: For DoDAF V2.0, The DoDAF Meta-model is working to replace the core architecture data model which supported previous versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document. CADM can continue to be used in support of architectures created in previous versions of DoDAF.
Topics
Building blocks
The major elements of a core architecture data model are described as follows:- 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.
- Architecture data : The possible piece-parts of architecture products and related analytical tools in a rigorous definition of the pieces, 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, emphasis on semantic well-definedness and exclusivity, and domain-level completeness. Logical data models need not commit to a specific Data Base Management System. 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.
Data modeling and visualization
- 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 model diagram notation.
As illustrated in the figure, boxes represent entities for which architecture data are collected ; they are depicted by open boxes with square corners or rounded corners. 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. The horizontal line in each box separates the primary key attributes from the non-key descriptive attributes.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 and solid relationships in which the child entity has zero, one, or many instances associated to each instance of the parent entity.
Basic architectural elements
An architecture data repository responsive to the architecture products of the DoDAF contains information on basic architectural elements such as the following:- Operational nodes may be organizations, organization types, and operational roles..
- Operational activities including tasks defined in the Universal Joint Task List.
- Information and data refers to information provided by domain databases and other information asset sources 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 and systems of systems 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, 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.
- 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.