Misplaced Pages

#803196

58-471: This Architecture Framework is especially suited to large systems with complex integration and interoperability challenges, and it is apparently unique in its employment of "operational views". These views offer overview and details aimed to specific stakeholders within their domain and in interaction with other domains in which the system will operate. The DoDAF provides a foundational framework for developing and representing architecture descriptions that ensure

116-450: A Mission Needs Statement (MNS) was a U.S. Department of Defense type of document which identified capability needs for a program to satisfy by a combination of solutions ( DOTMLPF ) to resolve a mission deficiency or to enhance operational capability. This type of document has been superseded by the description of capability needs called an Initial Capabilities Document, as of CJCSI 3170.01E. The CJCSI 3170.01 and 6212.01 were superseded by

174-483: 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

232-656: 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. Core architecture data model (CADM) 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,

290-482: A common denominator for understanding, comparing, and integrating architectures across organizational, joint, and multinational boundaries. It establishes data element definitions, rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. These architecture descriptions may include families of systems (FoS), systems of systems (SoS), and net-centric capabilities for interoperating and interacting in

348-612: 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

406-592: A meta-model underpinning the framework, defining the types of modelling elements that can be used in each view and the relationships between them. DoDAF versions 1.0 thru 1.5 used the CADM meta-model, which was defined in IDEF1X (then later in UML) with an XML Schema derived from the resulting relational database. From version 2.0, DoDAF has adopted the IDEAS Group foundation ontology as

464-423: A new way of thinking for solving grand challenges where the interactions of technology, policy, and economics are the primary drivers. System of systems study is related to the general study of designing , complexity and systems engineering , but also brings to the fore the additional challenge of design . Systems of systems typically exhibit the behaviors of complex systems, but not all complex problems fall in

522-482: A new, more complex system which offers more functionality and performance than simply the sum of the constituent systems. Currently, systems of systems is a critical research discipline for which frames of reference, thought processes, quantitative analysis, tools, and design methods are incomplete. referred to system of systems engineering . Commonly proposed descriptions—not necessarily definitions—of systems of systems, are outlined below in order of their appearance in

580-447: 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

638-409: A specific focus on the "design, development and engineering of System-of-Systems". These projects included: Ongoing European projects which are using a System of Systems approach include: Core Architecture Data Model Core architecture data model ( CADM ) in enterprise architecture is a logical data model of information used to describe and build architectures. The CADM is essentially

SECTION 10

#1732894518804

696-461: A systems-of-systems approach. An application in business can be found for supply chain resilience . Collaboration among a wide array of organizations is helping to drive the development of defining system of systems problem class and methodology for modeling and analysis of system of systems problems. There are ongoing projects throughout many commercial entities, research institutions, academic programs, and government agencies. Major stakeholders in

754-497: 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. As illustrated in the figure, boxes represent entities for which architecture data are collected (representing tables when used for

812-484: Is an OMG initiative to standardize UML and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national IDEAS Group , which is supported by Australia, Canada, Sweden, UK, USA, with NATO observers, has launched an initiative to develop a formal ontology for enterprise architectures. Systems of systems System of systems is a collection of task-oriented or dedicated systems that pool their resources and capabilities together to create

870-509: Is necessary to clearly identify the stakeholders and their concerns that map to each selected DoDAF product. Otherwise there is the risk of producing products with no customers. The figure "DoDAF V1.5 Products Matrix" shows how the DoD Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E specifies which DoDAF V1.5 products are required for each type of analysis, in the context of

928-507: Is organized around a shared repository to hold work products. The repository is defined by the common database schema Core Architecture Data Model 2.0 and the DoD Architecture Registry System (DARS). A key feature of DoDAF is interoperability, which is organized as a series of levels, called Levels of Information System Interoperability (LISI). The developing system must not only meet its internal data needs but also those of

986-602: Is urgent not only because of the growing complexity of today's challenges, but also because such problems require large monetary and resource investments with multi-generational consequences. While the individual systems constituting a system of systems can be very different and operate independently, their interactions typically expose and deliver important emergent properties. These emergent patterns have an evolving nature that stakeholders must recognize, analyze and understand. The system of systems approach does not advocate particular tools, methods or practices; instead, it promotes

1044-596: Is working to replace the core architecture data model (CADM) 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. The major elements of a core architecture data model are described as follows: 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,

1102-449: The "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of

1160-401: The C4ISR community. This document addressed usage, integrated architectures, DoD and Federal policies, value of architectures, 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. In February 2004

1218-439: 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

SECTION 20

#1732894518804

1276-822: The CJCSI 5123.01 Series. This term was introduced as a fundamental step in CJCSI 3170.01B (Apr 2001), 6212.01D (Apr 2005), and the Interim Defense Acquisition Guidebook (Oct 2004). On May 28, 2009, DoDAF v2.0 was approved by the Department of Defense. The current version is DoDAF 2.02 DoDAF V2.0 is published on a public website. Other derivative frameworks based on DoDAF include the NATO Architecture Framework (NAF) and Ministry of Defence Architecture Framework . Like other EA approaches, for example The Open Group Architecture Framework (TOGAF), DoDAF

1334-484: The Conceptual, Logical & Physical Data Models. The DODAF 2.0 Architects Guide repeated DOD Instruction 4630.8 definition of an integrated architecture as "An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures. For the purposes of architecture development, the term integrated means that data required in more than one of

1392-461: The DM2 supports the exchange and reuse of architectural information among JCAs, Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will evolve to a resource that more completely supports

1450-554: The Net-Ready Key Performance Parameter (NR-KPP): Representations for the DoDAF products may be drawn from many diagramming techniques including: There is a UPDM (Unified Profile for DoDAF and MODAF) effort within the OMG to standardize the representation of DoDAF products when UML is used. DoDAF generically describes in the representation of the artifacts to be generated, but allows considerable flexibility regarding

1508-602: The SV to the OV can be exemplified as systems are procured and fielded to support organizations and their operations. The DoDAF V1.5 SV products are: Technical standards view (TV) products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The DoDAF V1.5 TV products are as follows: In DoDAF V2.0, architectural viewpoints are composed of data that has been organized to facilitate understanding. To align with ISO Standards, where appropriate,

1566-400: The application domain and the specific needs of the effort. One concern about the DoDAF is how well these products meet actual stakeholder concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as ANSI/IEEE 1471-2000 or ISO/IEC 42010 viewpoints . But to build an architecture description that corresponds to ANSI/IEEE 1471-2000 or ISO/IEC 42010, it

1624-611: The architectural models is commonly defined and understood across those models. Integrated architectures are a property or design principle for architectures at all levels: Capability,Component, Solution, and Enterprise (in the context of the DoD Enterprise Architecture (EA) being a federation [of] architectures). In simpler terms, integration is seen in the connection from items common among architecture products, where items shown in one architecture product (such as sites used or systems interfaced or services provided) should have

1682-430: 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: Data visualization is a way of graphically or textually representing architecture data to support decision-making analysis. The DoDAF provides products as

1740-420: The basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness. All view (AV) products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The DoDAF V1.5 AV products are defined as: Operational View (OV) products provide descriptions of

1798-489: The basis for its new meta-model. This new meta-model is called "DM2"; an acronym for "DoDAF Meta-Model". Each of these three levels of the DM2 is important to a particular viewer of Departmental processes: The purposes of the DM2 are: The DM2 defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions. In this manner,

Department of Defense Architecture Framework - Misplaced Pages Continue

1856-551: The broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views: Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The three views and their interrelationships – driven by common architecture data elements – provide

1914-656: 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

1972-570: The defense sector, is also seeing application in such fields as national air and auto transportation and space exploration . Other fields where it can be applied include health care , design of the Internet , software integration, and energy management and power systems. Social-ecological interpretations of resilience, where different levels of our world (e.g., the Earth system, the political system) are interpreted as interconnected or nested systems, take

2030-418: 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 (DM2)

2088-689: The development of a new exploration "system-of-systems" to accomplish the goals outlined by President G.W. Bush in the 2004 Vision for Space Exploration. A number of research projects and support actions, sponsored by the European Commission , were performed in the Seventh Framework Programme . These target Strategic Objective IST-2011.3.3 in the FP7 ICT Work Programme (New paradigms for embedded systems, monitoring and control towards complex systems engineering). This objective had

2146-635: The development of this concept are: For example, DoD recently established the National Centers for System of Systems Engineering to develop a formal methodology for system-of-systems engineering for applications in defense-related projects. In another example, according to the Exploration Systems Architecture Study , NASA established the Exploration Systems Mission Directorate (ESMD) organization to lead

2204-467: The documentation of Version 1.0 was released with volume "I: Definitions and Guidelines", "II: Product Descriptions" and a "Deskbook". In April 2007 the Version 1.5 was released with a documentation of "Definitions and Guidelines", "Product Descriptions" and "Architecture Data Description". This period further developed the concepts and terms that have since been replaced with different approaches. For example,

2262-460: The entity) 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 (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

2320-413: The identical number, name, and meaning appear in related architecture product views." There are many different approaches for creating an integrated architecture using DoDAF and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for. As one example, the DoDAF v1.0 listed the following products as

2378-484: The literature: Taken together, all these descriptions suggest that a complete system of systems engineering framework is needed to improve decision support for system of systems problems. Specifically, an effective system of systems engineering framework is needed to help decision makers to determine whether related infrastructure, policy and/or technology considerations as an interrelated whole are good, bad or neutral over time. The need to solve system of systems problems

Department of Defense Architecture Framework - Misplaced Pages Continue

2436-403: The nature of the exchanges. The DoDAF V1.5 OV products are defined as: Systems and services view (SV) is a set of graphical and textual products that describe systems and services and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between architecture data elements across

2494-540: The newer architecture. In regard to DoDAF V1.5 products, they have been transformed into parts of the DoDAF V2.0 models. In most cases, the DoDAF V2.0 Meta-model supports the DoDAF V1.5 data concepts, with one notable exception: Node. Node is a complex, logical concept that is represented with more concrete concepts. Note, see Logical data model for discussion of the relationship of these three DIV data models, with comparison of

2552-447: The non-combat environment. DoD Components are expected to conform to DoDAF to the maximum extent possible in development of architectures within the department. Conformance ensures that reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding. All major U.S. DoD weapons and information technology system acquisitions are required to develop and document an enterprise architecture (EA) using

2610-494: The operational framework into which it is set. See the diagram for a depiction of the Capabilities Emphasis, as tied in with mission/course of action, threads, activities, and architectures. The DoD has moved toward a focus on the delivery of capabilities, which are the reason for creating the system/service. The Capability Models describe capability taxonomy and capability evolution. A capability thread would equate to

2668-619: The parent entity (the other entity connected by the relationship line). An architecture data repository responsive to the architecture products of the DoDAF contains information on basic architectural elements such as the following: The depicted (conceptual) relationships shown in this diagram include the following (among many others): With these relationships, many types of architectural and related information can be represented such as networks, information flows, information requirements, interfaces, and so forth. The counterpart to CADM within NASA

2726-639: The realm of systems of systems. Inherent to system of systems problems are several combinations of traits, not all of which are exhibited by every such problem: The first five traits are known as Maier's criteria for identifying system of systems challenges. The remaining three traits have been proposed from the study of mathematical implications of modeling and analyzing system of systems challenges by Dr. Daniel DeLaurentis and his co-researchers at Purdue University . Current research into effective approaches to system of systems problems includes: Systems of systems, while still being investigated predominantly in

2784-403: 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

2842-511: The requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries. To facilitate the use of information at the data layer, the DoDAF describes a set of models for visualizing data through graphic, tabular, or textual means. These views relate to stakeholder requirements for producing an Architectural Description. The UPDM (Unified Profile for DoDAF and MODAF )

2900-452: The specific activities, rules, and systems that are linked to that particular capability. The concept of capability, as defined by its Meta-model Data Group allows one to answer questions such as: The Mission or Course of Action is described by a Concept of Operations (CONOPS), and is organized by Capabilities. The DoDAF V1.5 defines a set of products, a view model , that act as mechanisms for visualizing, understanding, and assimilating

2958-602: The specific formats and modeling techniques. The DoDAF deskbook provides examples in using traditional systems engineering and data engineering techniques, and secondly, UML format. DoDAF proclaims latitude in work product format, without professing one diagramming technique over another. In addition to graphical representation, there is typically a requirement to provide metadata to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories. DoDAF has

SECTION 50

#1732894518804

3016-399: The tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. The OV provides textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. It defines the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and

3074-602: The terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint). The architectures for DoDAF V1.0 and DoDAF V1.5 may continue to be used. When appropriate (usually indicated by policy or by the decision-maker), DoDAF V1.0 and V1.5 architectures will need to update their architecture. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture, concept differences (such as Node) must be defined or explained for

3132-428: 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 (or types). The CADM was initially published in 1997 as

3190-426: The views prescribed in the DoDAF. While it is clearly aimed at military systems, DoDAF has broad applicability across the private, public and voluntary sectors around the world, and represents one of a large number of systems architecture frameworks . The first version of the development DoDAF was developed in the 1990s under the name C4ISR Architecture Framework. In the same period the reference model TAFIM , which

3248-478: The warfighter. Continued development effort resulted in December 1997 in the second version, C4ISR Architecture Framework v2.0. In August 2003 the DoDAF v1.0 was released, which 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

3306-461: Was initiated in 1986, was further developed. The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of the Clinger-Cohen Act . It addressed the 1995 Deputy Secretary of Defense directive that a DoD-wide effort be undertaken to define and develop a better means and process for ensuring that C4ISR capabilities were interoperable and met the needs of

3364-633: 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

#803196