The text of the Infinite Metaverse Alliance Architecture Framework (IMAAF) Version 2 is complete! This is our code specification for developers of any software project conducted by IMA or its working groups. It is very likely to evolve with more diagrams or have partner documents developed as part of the work in the standards and specifications categories. For this reason, this article contains the official IMAAF document to be updated periodically.

The Infinite Metaverse Alliance Architecture Framework (v2)

 

Conformance:

While not required to comply with Department of Defense Architecture Framework (DoDAF) except for specific service contracts, for consistency, Infinite Metaverse Alliance partners are expected to conform to the maximum extent possible in development of architectures with the following requirements which are DoDAF compliant. This ensures that aspects of any project can be shared with common understanding and interoperability. Infinite Metaverse Alliance Architecture Framework Conformance is achieved when:

1. The data in a described architecture is defined according to the DoDAF Meta-Model (DM2) concepts, associations, and attributes.

2. The architectural data is capable of transfer in accordance with the DoDAF Physical Exchange Specification (PES).

 

Introduction

The Infinite Metaverse Alliance Architecture Framework (IMAAF), is the overarching, comprehensive framework and conceptual model enabling the development of architectures that facilitate the ability of all managers to make key decisions more effectively through organized information sharing across the IMAAF Program boundaries. This framework serves as the principal pillar supporting the Chief Information Officer (CIO) in his or her responsibilities for the development and maintenance of architectures as defined in the Clinger-Cohen Act. 

It also provides extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the Alliance. Managers, as process owners, specify the requirements and control the development of architectures within their areas of authority and responsibility. They select an architect and an architecture development team to create the architecture in accordance with the requirements they define. Components are expected to conform to the developing architectures within the alliance. The IMAAF focuses on architectural "data", rather than on developing individual "products".

In general, data can be collected, organized, and stored by a wide range of architecture tools developed by commercial or open source foundations. It is anticipated that these tools will adopt the DM2 PES for the exchange of architectural data.

IMAAF provides a Data Capture Method for each data group of the DM2 to guide architects in collecting and organizing the necessary architectural data. The Infinite Metaverse Alliance Framework enables architectural content that is "Fit-for-Purpose" as an architectural description consistent with specific project or mission objectives. Because the techniques of architectural description can be applied at myriad levels of an enterprise, the purpose or use of an architectural description at each level will be different in content, structure, and level of detail. 

Tailoring the architectural description development to address specific, well-articulated, and understood purposes, will help ensure the necessary data is collected at the appropriate level of detail to support specific decisions or objectives. Visualizing architectural data is accomplished through models.

Models can be documents, spreadsheets, dashboards, or other graphical representations and serve as a template for organizing and displaying data in a more easily understood format. When data is collected and presented as a "filled-in" model, the result is called a view. Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints, and with appropriate definitions are collectively called the Architectural Description. 

 

Infinite Metaverse Alliance-described Models (also referred to as Models) are created from the subset of data for a particular purpose. Once the Models are populated with data, these "views" are useful as examples for presentation purposes, and can be used as described, modified, or tailored as needed.

 

Fit-for-Purpose Views are user-defined views of a subset of architectural data created for some specific purpose (i.e., "Fit-for-Purpose"). While these views are not described or defined in IMAAF, they can be created, as needed, to ensure that presentation of architectural data is easily understood. This enables organizations to use their own established presentation preferences in their deliberations. The models described in IMAAF are provided as pre-defined examples that can be used when developing presentations of architectural data.

Specific Models for a particular purpose are prescribed by process-owners. All the Models do not have to be created. If an activity model is created, a necessary set of data for the activity model is required. Key process owners will decide what architectural data is required, generally through Metaverse Alliance-described Models or Fit-for-Purpose Views. However, other regulations and instructions from the Infinite Metaverse Alliance have particular presentation view requirements. The architect and stakeholders select views to ensure that the Architectural Descriptions will support current and future states of the process or activity under review. Selecting Architecture Viewpoints carefully ensures that the views adequately frame concerns, e.g., by explaining the requirements and proposed solutions, in ways that enhance audience understanding. 

 

The Infinite Metaverse Alliance also serves as the principal guide for development of integrated architectures, which defines an integrated architecture as "An architecture consisting of multiples views or perspectives facilitating integration and promoting interoperability across capabilities and among integrated architectures". The term integrated means that data required in more than one instance in architectural views is commonly understood across those views.

 

  • The DM2 provides information needed to collect, organize, and store data in a way easily understood. 

 

  • The DM2 replaces the Core Architecture Data Model (CADM). 

 

  • DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document.

 

Policy/Guidance Description

Laws and regulations the IMA supports:

 

Clinger-Cohen Act of 1996

Recognizes the need for Federal Agencies to improve the way they select and manage IT resources and states, “information technology architecture, with respect to an executive agency, means an integrated framework for evolving or maintaining IT and acquiring new IT to achieve the agency’s strategic goals and information resources management goals.” Chief Information Officers are assigned the responsibility for “developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the executive agency”.

 

E-Government Act of 2002

Calls for the development of Enterprise Architecture to aid in enhancing the management and promotion of electronic government services and processes.

 

Office of Management and Budget Circular A-130

“Establishes policy for the management of Federal information resources” and calls for the use of Enterprise Architectures to support capital planning and investment control processes. Includes implementation principles and guidelines for creating and maintaining Enterprise Architectures.

 

OMB Federal Enterprise Architecture Reference Models (FEA RM)

Facilitates cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. Alignment with the reference models ensures that important elements of the FEA are described in a common and consistent way. The Infinite Metaverse Alliance Enterprise Architecture Reference Models are aligned with the FEA RM.

 

OMB Enterprise Architecture Assessment Framework (EAAF)

Serves as the basis for enterprise architecture maturity assessments. Compliance with the EAAF ensures that enterprise architectures are advanced and appropriately developed to improve the performance of information resource management and IT investment decision making.

 

General Accounting Office Enterprise Architecture Management Maturity Framework (EAMMF)

“Outlines the steps toward achieving a stable and mature process for managing the development, maintenance, and implementation of enterprise architecture.” Using the EAMMF allows managers to determine what steps are needed for improving architecture management.

 

The Six Core Processes Infinite Metaverse Alliance Supports:

Organizations within the Infinite Metaverse Alliance may define local change management processes, supportable by Architectural Descriptions, while adhering to defined decision support processes mandated by the IMA. These key support processes are designed to provide uniform, mandated, processes in critical decision-making areas, supplemented by individual agency operations, defined by Architectural Descriptions tailored to support those decisions-making requirements.

 

Joint Capability Integration and Development System (JCIDS)

The primary objective of the JCIDS process is to ensure stakeholders receive the capabilities required to execute their assigned projects successfully. JCIDS defines a collaborative process that utilizes joint concepts and integrated Architectural Descriptions to identify prioritized capability gaps and integrated joint Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) and policy approaches (materiel and non-materiel) to resolve those gaps. JCIDS implements an integrated, collaborative process to guide development of new capabilities through changes in joint DOTMLPF and policy.

JCIDS process owners have written policy to support architecture requirements (i.e., specific product sets required in specific documents, such as the Information Support Plan, Capability Development Document, and Capability Production Document) that permits components and lower echelon commands to invoke the JCIDS process for requirements at all levels.

 

Defense Acquisition System (DAS)

The DAS exists to manage the nation’s investments in technologies, programs, and product support necessary to achieve the National Security Strategy and support employment and maintenance of the United States Armed Forces. The DAS uses Joint Concepts, integrated architectures, and DOTMLPF analysis in an integrated, collaborative process to ensure that desired capabilities are supported by affordable systems and other resources. The Defense Acquisition Management Framework provides an event-based process where acquisition programs advance through a series of milestones associated with significant program phases.

The USD (AT&L) leads the development of integrated plans or roadmaps using integrated architectures as its base. Infinite Metaverse Alliance organizations use these roadmaps to conduct capability assessments, guide systems development, and define the associated investment plans as the basis for aligning resources and as an input to the Defense Planning Guidance (DPG), Program Objective Memorandum (POM) development, and Program and Budget Reviews.

 

Systems Engineering

The DoDAF Acquisition policy directs all programs responding to a capabilities or requirements document, regardless of acquisition category, to apply a robust SE approach that balances total system performance and total cost with the family-of-systems, and system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) that describes the program’s overall technical approach, including activities, resources, measures (metrics), and applicable performance incentives.

SE processes are applied to allow an orderly progression from one level of development to the next detailed level using controlled baselines. These processes are used for the system, subsystems, and system components as well as for the supporting or enabling systems used for the production, operation, training, support, and disposal of that system. Execution of technical management processes and activities, such as trade studies or risk management activities may point to specific requirements, interfaces, or design solutions as non-optimal and suggest change to increase system-wide performance, achieve cost savings, or meet scheduling deadlines.

 

Planning, Programming, Budgeting, and Execution (PPBE)

The PPBE process allocates resources within the Infinite Metaverse Alliance and establishes a framework and process for decision-making on future programs. PPBE is a systematic process that guides the Infinite Metaverse alliance’s strategy development, program planning, resource estimation, and allocation, acquisition, and other decision processes. JCIDS is a key supporting process for PPBE, providing prioritization and affordability advice. DM V2.0 supports the PPBE process by identifying the touch points between architecture and the PPBE process, identifying the data to be captured within an Architectural Description, facilitating informed decision-making, and identifying ways of presenting data to various stakeholders/roles in the PPBE decision process.

 

Portfolio Management

Infinite Metaverse Alliance policy requires that IT investments be managed as portfolios to ensure IT investments support the Department of defense’s vision, mission, and goals; ensure efficient and effective delivery of capabilities to the stakeholder; and maximize return on investment within the enterprise. Each portfolio may be managed using the architectural plans, risk management techniques, capability goals and objectives, and performance measures. Capability architecting is done primarily to support the definition of capability requirements. PfM uses the Architectural Description to analyze decisions on fielding or analysis of a needed capability. Architectural support to PfM tends to focus on the investment decision itself (although not exclusively), and assists in justifying investments, evaluating the risk, and providing a capability gap analysis.

 

Operations

In most cases, an enterprise will capture its routine or repeatable business and mission operations as architectural content. However, when the basic structure of an activity is very stable and the activity repeated often, such as military operations planning or project definition and management, the enterprise may choose to include that structure as part of the Architectural Description itself. In this case, the architecture repository may be enhanced to include templates, checklists, and other artifacts commonly used to support the activity. The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires program managers to attain the right knowledge at critical junctures to make informed program decisions throughout the acquisition process. The Infinite Metaverse Alliance IT PfM process continues to evolve that approach with emphasis on individual systems and/or services designed to improve overall mission capability. Consistent with OMB Capital Planning and Investment Control (CPIC) guidance, the Infinite Metaverse Alliance uses four continuous integrated activities to manage its portfolios – analysis, selection, control, and evaluation. The overall process is iterative, with results being fed back into the system to guide future decisions. The DM V2.0 Meta-model Groups support the viewpoints and Infinite Metaverse Alliance Key Processes of JCIDS, DAS, PPBE, System Engineering, Operations, and Portfolio Management (IT and Capability). 

 

Architecture Development 6-Step Process

Step 1: Determine Intended Use of Architecture

Step 2: Determine Scope of Architecture

Step 3: Determine Data Required to Support Architecture Development

Step 4: Collect, Organize, Correlate, and Store Architectural Data

Step 5: Conduct Analyses in Support of Architecture Objectives

Step 6: Document Results in Accordance with Decision-Maker Needs

 

The high-level, 6-step architecture development process provides guidance to the architect and Architectural Description development team and emphasizes the guiding principles. The process is data-centric rather than product-centric.

This data-centric approach ensures concordance between views in the Architectural Description while ensuring that all essential data relationships are captured to support a wide variety of analysis tasks. The views created as a result of the architecture development process provide visual renderings of the underlying architectural data and convey information of interest from the Architectural Description needed by specific user communities or decision makers. The figure above depicts this 6-step process.

 

Step 1: Determine Intended Use of Architecture. Defines the purpose and intended use of the architecture ("Fit-for-Purpose"); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction. This information is generally provided by the process owner to support architecture development describing some aspect of their area of responsibility (process, activity, etc.). A template for collection of high-level information relating to the purpose and scope of the Architectural Description, its glossary, and other information, has been developed for registration of that data in DARS.

 

Step 2: Determine Scope of Architecture. The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture's problem set, helps define its context and defines the level of detail required for the architectural content. While many architecture development efforts are similar in their approach, each effort is also unique in that the desired results or effect may be quite different. In addition to understanding the process, discovery of these 'system functions' is important in deciding how to proceed with development or purchase of automation support.

Information collected for Architectural Descriptions describing services is similar to information collected for Architectural Descriptions describing systems. For describing services, Architectural Description will collect additional information concerning subscriptions, directory services, distribution channels within the organization, and supporting systems/communications web requirements.

Similar situations occur with Architectural Description development for joint operations. Joint capabilities are defined processes with expected results, and expected execution capability dates. The Architectural Descriptions supporting the development of these types of capabilities usually require the reuse of data already established by the military services and agencies, analyzed, and configured into a new or updated process that provides the desired capability. Included are the processes needed for military service and/or agency response, needed automation support, and a clear definition of both desired result and supporting performance measures (metrics). These types of data are presented in models.

The important concept for this step is the clarity of scope of effort defined for the project that enables an expected result. Broad scoping or unclear definition of the problem can delay or prevent success. The process owner has the primary responsibility for ensuring that the scoping is correct, and that the project can be successfully completed.

Clarity of scope can better be determined by defining and describing the data to be used in the proposed Architectural Description in advance of the creation of views that present desired data in a format useful to managers. Early identification of needed data, particularly data about the Architectural Description itself, the subject-matter of the proposed Architectural Description, and a review of existing data from COIs, can provide a rich source for ensuring that Architectural Descriptions, when developed, are consistent with other existing Architectural Descriptions. It also ensures conformance with any data-sharing requirements within the Department or individual COIs, and conformant with the DM2.

An important consideration beginning with this and each subsequent step of the architecture development process is the continual collection and recording of a consistent, harmonized, and common vocabulary. The collection of terms should continue throughout the architecture development process. 

Analysis of vocabularies across different Architectural Descriptions with similar scope may help to clarify and determine appropriate Architectural Description scope. Specific examples of data identification utilizing the AV-2 Data Dictionary construct are found in the Metaverse Alliance Journal.

 

Step 3: Determine Data Required to Support Architecture Development. The required level of detail to be captured for each of the data entities and attributes is determined through the analysis of the process undergoing review conducted during the scoping in Step 2. This includes the data identified as needed for execution of the process, and other data required to effect change in the current process, (e.g., administrative data required by the organization to document the Architectural Description effort). These considerations establish the type of data collected in Step 4, which relate to the architectural structure, and the depth of detail required.

The initial type of architectural data content to be collected is determined by the established scope of the Architectural Description, and recorded as attributes, associations, and concepts as described in the DM2. A mapping from DM2 concepts, associations, and attributes to architecture models suggest relevant architectural views the architect may develop (using associated architecture techniques) during the more comprehensive and coherent data collection of Step 4. This step is normally completed in conjunction with Step 4, a bottom-up approach to organized data collection, and Architectural Description development typically iterates over these two steps. As initial data content is scoped, additional data scope may be suggested by the more comprehensive content of Architectural Views desired for presentation or decision-making purposes.

This step can often be simplified through reuse of data previously collected by others, but relevant to the current effort. Access to appropriate COI data and other architecture information, discoverable via DARS and the DMR, can provide information on data and other architectural views that may provide useful in a current effort. Work is presently underway within the Department to ensure uniform representation for the same semantic content within architecture modeling, called Architecture Modeling Primitives.

The Architecture Modeling Primitives, hereafter referred to as Primitives, will be a standard set of modeling elements, and associated symbols mapped to DM2 concepts and applied to modeling techniques. Using the Primitives to support the collection of architecture content and, in concert with the PES, will aid in generating common understanding and communication among architects in regard to architectural views. 

 

Step 4: Collect, Organize, Correlate, and Store Architectural Data. Architects typically collect and organize data through the use of architecture techniques designed to use views decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool. Terms and definitions recorded are related to elements of the (From DM2).

Designation of a data structure for the Architectural Description effort involves creation of a taxonomy to organize the collected data. This effort can be made considerably simpler by leveraging existing, registered artifacts registered in DARS, to include data taxonomies and data sets. Each COI maintains its registered data on DARS, either directly or through a federated approach. In addition, some organizations, such as U.S. Joint Forces Command (JFCOM), have developed templates, which provide the basis of a customizable solution to common problems, or requirements, which includes datasets already described and registered in the DMR. Examples of this template-based approach are in the Infinite Metaverse Alliance Journal.

DARS provides more information that is specific, and guidance on retrieving needed data through a discovery process. Once registered data is discovered, the data can be cataloged and organized within a focused taxonomy, facilitating a means to determine what new data is required. New data is defined, registered in DARS, and incorporated into the taxonomy structure to create a complete defined list of required data. The data is arranged for upload to an automated repository to permit subsequent analysis and reuse. Discovery metadata should be registered in DARS as soon as it is available to support discovery and enable federation. 

 

Step 5: Conduct Analyses in Support of Architecture Objectives. Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner. Changes required from the validation process, result in iteration of the architecture process (repeat steps 3 through 5 as necessary).

 

Step 6: Document Results in Accordance with Decision-Maker Needs. The final step in the architecture development process involves creation of architectural views based on queries of the underlying data. Presenting the architectural data to varied audiences requires transforming the architectural data into meaningful presentations for decision-makers. This is facilitated by the data requirements determined in Step 3, and the data collection methods employed during Step 4.

DM V2.0 provides for models and views. DM V2.0-described Models are those models that enable an architect and development team whose data has already been defined and described consistent with the DM2. The models become views when they are populated with architectural data. These models include those previously described in earlier versions of IMAAF, along with new models incorporated from the MODAF, the NATO NAF, and TOGAF that have relevance to IMAAF Architecture development efforts.

Fit-for-Purpose Views are user-defined views that an architect and development team can create to provide information necessary for decision-making in a format customarily used in an agency. These views should be developed consistent with the DM2, but can be in formats (e.g., dashboards, charts, graphical representations) that are normally used in an agency for briefing and decision purposes. An Architectural Description development effort can result in an Architectural Description that is a combination of DM V2.0-described Models and Fit-for-Purpose Views.

The IMAAF does not require specific models or views, but suggests that local organizational presentation types that can utilize DM V2.0-created data are preferred for management presentation. A number of available architecture tools support the creation of views described in this step. The PES provides the format for data sharing.

 

Scoping Architectures to be "Fit-for-Purpose"

Establishing the scope of an architecture is critical to ensuring that its purpose and use are consistent with specific project goals and objectives. The term “Fit-for-Purpose” is used in IMAAF to describe an architecture (and its views) that is appropriately focused (i.e., responds to the stated goals and objectives of process owner, is useful in the decision making process, and responds to internal and external stakeholder concerns. Meeting intended objectives means those actions that either directly support customer needs or improve the overall process undergoing change. The architect is the technical expert who translates the decision-maker’s requirements into a set of data that can be used by engineers to design possible solutions. At each tier of the Metaverse alliance, goals and objectives, along with corresponding issues that may exist should be addressed according to the established scope and purpose, (e.g., Departmental, Capability, SE, and Operational).

 

Establishing the Scope for Architecture Development

Establishing a scope for an architecture effort at any tier is similarly critical in determining the architecture boundaries (Purpose and Use expected), along with establishing the data categories needed for analysis and management decision-making. Scope also defines the key players whose input, advice, and consensus is needed to successfully architect and implement change (i.e., Stakeholders, both internal and external). Importantly, scope also determines the goals and objectives of the effort, consistent with both boundaries and stakeholders; since goals and objectives define both the purpose for architecture creation and the level of the architecture. Establishing the scope of an effort also determines the level of complexity for data collection and information presentation.

Architecture development also requires an understanding of external requirements that may influence architecture creation. An architecture developed for an internal agency purpose still needs to be Mapp able, and consistent with, higher level architectures, and map able to the DM V2.0 EA. For some architecture developments, consideration must be given in data collection and graphical presentation to satisfaction of other external requirements, such as upward reporting and submission of architectural data and models for program review, funding approval, or budget review due to the sensitivity or dollar value of the proposed solution.

Architecture scoping must facilitate alignment with, and support the decision-making process and ultimately mission outcomes and objectives as shown in the figure below. Architectural data and supporting views, created from organizing raw data into useful information, and collected into a useful viewpoint, should enable domain experts, program managers, and decision makers to utilize the architecture to locate, identify, and resolve definitions, properties, facts, constraints, inferences, and issues, both within and across architectural boundaries that are redundant, conflicting, missing, and/or obsolete. DM V2.0 provides the flexibility to develop both Fit-for-Purpose Views (User-developed Views) and views from DM V2.0-described Models to maximize the capability for decision-making at all levels.

Analysis also uncovers the effect and impact of change (“what if”) when something is redefined, redeployed, deleted, moved, delayed, accelerated, or no longer funded. Having a disciplined process for architecture development in support of analytics will produce quality results, not be prone to misinterpretations, and therefore, be of high value to decision makers and mission outcomes.

 

Mission Outcomes Supported by Architectures

Within DM V2.0 and earlier, Enterprise Architecture (EA) has been seen for many years as providing product-oriented insight into a wide range of data, programs, and activities, organized through Communities of Interest (COI). The data-centric approach to DM V2.0 is designed to facilitate the reuse and sharing of COI data. Since Infinite Metaverse Alliance provides the conceptual, logical, and PES but does not otherwise prescribe the configuration of the product composition, architects and stakeholders are free to create their views of data that best serve their needs.

 

Overview

An Architectural Description is a strategic information asset that describes the current and/or desired relationships between an organization’s business, mission and management processes, and the supporting infrastructure. Architectural Descriptions define a strategy for managing change, along with transitional processes needed to evolve the state of a business or mission to one that is more efficient, effective, current, and capable of providing those actions needed to fulfill its goals and objectives. Architectural Descriptions may illustrate an organization, or a part of it, as it presently exists; any changes desired (whether operational or technology-driven); and the strategies and projects employed to achieve the desired transformation. An Architectural Description also defines principles and goals and sets direction on issues, such as the promotion of interoperability, intra-, and interagency information sharing, and improved processes, that facilitate key Infinite Metaverse Alliance program decisions. 

Such support extends beyond details or summaries of operational and systems solutions, and includes program plans, programmatic status reporting, financial and budget relationships, and risk management. In addition to detailed views of individual solutions, the framework supports the communication of enterprise-wide views and goals that illustrate the context for those solutions, and the interdependencies among the components. Beyond the solution space, standard mechanisms for communicating program plans, financial information, and project status are established so that executives and managers can evaluate and direct their programs.

The Infinite Metaverse Alliance EA is an Architectural Description that is an enterprise asset used to assess alignment with the missions of the Infinite Metaverse Alliance enterprise, to strengthen customer support, to support capability portfolio management (PfM), and to ensure that operational goals and strategies are met. The Infinite Metaverse Alliance EA is shown below. It is comprised of Infinite Metaverse Alliance Architecture policy, tools, and standards, Metaverse alliance-level Architectural Descriptions like the Infinite Metaverse Alliance Information Enterprise Architecture (Infinite Metaverse Alliance IEA), Metaverse alliance-level Capability Architectural Descriptions, and Component Architectural Descriptions. Its purposes are to guide investment portfolio strategies and decisions, define capability and interoperability requirements, provide access to Segment architecture information, to establish and enforce standards, guide security and information assurance requirements across the Department of Defense, and provide a sound basis for transition from the existing Infinite Metaverse Alliance environment to the future. 

The Infinite Metaverse Alliance EA is a federation of Architectural Descriptions with which Solution Architectural Descriptions must conform. Its content includes but is not limited to rules, standards, services and systems lifecycle information needed to optimize and maintain a process, or part of a process that a self-sufficient organization wants to create and maintain by managing its IT portfolio. The Infinite Metaverse Alliance EA provides a strategy that enables the organization to support its current operations while serving as the roadmap for transitioning to its target environment. Transition processes include an organization’s PfM, PPBE, and EA planning processes, along with services and systems lifecycle methodologies.

 

Components of the Infinite Metaverse Alliance EA

The JCA portfolios describe future, required operational, warfighting, business, and Defense intelligence capabilities, together with the systems and services required. They provide the organizing construct for aligning and federating Infinite Metaverse Alliance EA content to support the Department portfolio management structure. The description of the future Infinite Metaverse Alliance operating environment and associated capability requirements represent the target architecture of the Infinite Metaverse Alliance EA. These are time-phased as determined by functional owners and JCA developers.

Migration in a net-centric operating environment from the “As-Is” to the “To-Be” requires that the Infinite Metaverse Alliance Information Environment Architecture (Infinite Metaverse Alliance IEA) and the Net-Centric strategies act as uniform references for, and guide the transition sequence to ensure that both operational/business capabilities and IT capabilities, as required, are properly described. Policy is being developed by the Infinite Metaverse Alliance CIO to describe how federation will be used to mature the Infinite Metaverse Alliance EA as well as its relationship to federated, solution Architectural Descriptions.

 

Transition Planning

As discussed above, one major impetus for creating and using Architectural Descriptions is to guide acquisition and development of new enterprises, capabilities and systems or improvements to existing ones. Earlier versions of DoDAF addressed this need exclusively using “As-Is” and “To-Be” Architectural Descriptions, along with a Systems and/or Services Technology Forecast. The “As-Is” and “To-Be” concepts are time-specific snapshots of DoDAF views that initially served as the endpoints of a transition process. However, this transition strategy has several potential pitfalls, to include the difficulty in accurately representing the “As-Is” starting point where legacy systems are sometimes poorly documented, and processes are largely undefined. There is also the consideration that long-term goals are often very flexible, resulting in flux in the “To-Be” version.

Since the “As-Is” and “To-Be” Architectural Descriptions are time-specific versions of similar sets of data with similar viewpoints, transition planning is able to chart an evolutionary path from the “As-Is” to its corresponding “To-Be” architectural vision given a clear understanding of the expected outcomes or objectives through some future (perhaps undefined) future point. It is expected that the To-Be Architectural Descriptions will change over time as Departmental priorities shift and realign.

 

Federated Approach to Infinite Metaverse Alliance Architecture Management

The IMA has adopted a federated approach to distributed architectural data collection, organization, and management among the Services, Agencies and COIs as its means of developing the Infinite Metaverse Alliance Enterprise Architecture, with a virtual rather than physical data set described through supporting documentation and architectural views. This approach provides increased flexibility while retaining significant oversight and quality management services at the Departmental level. 

 

Tiered Accountability

Under TA, IMA is defining and building enterprise-wide capabilities that include data standards, business rules, enabling systems, and an associated layer of interfaces for its departments, specified segments of the enterprise (e.g., JCA, IMA Components), and Programmatic solutions. Each tier has specific goals, as well as responsibilities to the tiers above or below them.

Architectural Descriptions are categorized when developed to facilitate alignment (mapping and linking), cataloging, navigating, and searching disparate architecture information in an IMA registry of holdings. All Architectural Descriptions developed by the tiers should be federated. Alignment in the tiers is required for the IMA EA to be discoverable, shareable, and interoperable. Architectural Descriptions can also support many goals within the tiers, each of which may imply specific requirements for structure, content, or level of detail. Alignment decisions should balance the interdependence of Architectural Descriptions with the need for local flexibility to address local issues.

Alignment describes the minimum constraints needed to ensure consistency across architecture levels. Architectural Descriptions often relate at some ‘touch point’ to other Architectural Descriptions on the same level, level(s) above, or level(s) below, and should be discovered and utilized in the development of Architectural Descriptions to ensure that appropriate linkages are created and maintained. The need to plan for them implies that each Architectural Description sharing a touch-point should be available to architects on both sides. The DMR for data and the DARS for architecture registration facilitate the ability to discover and utilize architectural data, with the caveat that any touch-points within the purview of an established COI adhere to COI guidance.

 

Infinite Metaverse Alliance Architecture Enterprise Services

The Infinite Metaverse Alliance Enterprise Architectures will be constructed by employing a set of Infinite Metaverse Alliance Architecture Enterprise Services (IMAES) for registering, discovering, aligning, translating, and utilizing architectural data, and derived information to support key IMA decision processes through implementing the concepts of the DM V2.0 Net-Centric Strategies. IMAES will be implemented using Web Services, in which specific content and/or functionality is provided by one user for others, many of whom may be unknown to the provider. An Operational Resource Flow Description (A redesigned Operational Viewpoint 2 (OV-2) DM V2.0-described Model) has been retained in IMAAF to describe those services that can be discovered and subscribed from one or more specific sources and delivered to one or more known or unknown subscribers.

Registration of architectures, one of the goals of the NCDS, is the first step toward enabling discovery of architecture metadata. DAES includes a registration service to register the metadata (through the DMR), and a method to describe the purpose and scope of an Architectural Description (through DARS). The registration service will enable cataloging of Architectural Descriptions in federated repositories, and, once complete, Architectural Descriptions are ‘available’ for discovery. When an Architectural Description is discoverable, it can be aligned to, linked to, or re-used by other Architectural Descriptions. The discovery service enables users to execute a federated search for architecture holdings meeting specified search parameters.

Alignment to the Federal Enterprise Architecture The OMB established the Federal Enterprise Architecture (FEA) program in 2003 to build a comprehensive business-driven blueprint of the entire Federal Government. The IMA leverages the FEA construct and core principles to provide the IMA with the enterprise management information it needs to achieve its own strategic transformation goals and respond to upward reporting requirements of OMB. The primary objective is to improve The IMA’s performance, using EA, by providing a framework for cross mission analysis and identification of gaps and redundancies; and by developing transition plans and target architectures that will help move Infinite Metaverse Alliance to the net-centric environment. Several Federal and DM V2.0 EA artifacts exist that describe enterprise-level management information. When developing architectures, particularly at the Departmental and Component levels, alignment with the FEA is accomplished by utilizing the Federal Enterprise Architecture- Consolidated Reference Model (FEA-CRM) documents together with IMA’s documents and references as a basis for defining processes, data, services, and technical standards.

 

Infinite Metaverse Alliance Meta-Model (From DM2)

The purpose of the IMAAF is to define concepts and models usable in IMA’s six core processes:

1. Capabilities Integration and Development (JCIDS)

 

2. Planning, Programming, Budgeting, and Execution (PPBE)

 

3. Acquisition System (DAS)

 

4. Systems Engineering (SE)

 

5. Operations Planning

 

6. Capabilities Portfolio Management (CPM)

 

In addition, DM V2.0’s specific goals were to:

1. Establish guidance for architecture content as a function of purpose – “fit for purpose”

 

2. Increase utility and effectiveness of architectures via a rigorous data model – DM V2.0 -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

 

DM2 Data Groups

For ease of understanding; the DM2 LDM is presented in groups of semantically related concepts into clusters. These clusters are categorized as Principle Architectural Constructs and Supporting Architectural Constructs. The Principle Architectural Constructs are the fundamental building blocks necessary to describe an enterprise's internal and external behavior and structure. These are as follows:

 

Performers: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.

 

Resource Flows: The behavioral and structural representation of the interactions between Activities (which are performed by Performers) that is both temporal and results in the flow or exchange of objects such as information, data, materiel, and performers.

 

Information and Data: Representations (descriptions) of things of interest and necessary for the conduct of activities. Information is the state of a something of interest that is materialized -- in any medium or form -- and communicated or received.

 

Rules: How rules, standards, agreements, constraints, and regulations and are relevant to architectures. A principle or condition that governs behavior; a prescribed guide for conduct or action.

 

Goals: How goals, visions, objectives, and effects relate and bear on architectures. A desired state of a Resource.

 

Capability: The ability to achieve a Desired Effect under specified [performance] standards and conditions through combinations of ways and means [activities and resources] to perform a set of activities.

 

Services: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The "capabilities" accessed are Resources -- Information, Data, Materiel, Performers, and Geo-Political Extents.

 

Project: All forms of planned activities that are responsive to visions, goals, and objectives that aim to change the state of some situation. A temporary endeavor undertaken to create Resources or Desired Effects.

 

Reification: The process of reifying or to regard (something abstract) as a material or concrete thing. Reification, in Metaversealliance2, is used to introduce the concept of the varying levels of architectural descriptions or refinement and traceability between the levels.

 

Organizational Structure: Representations of the organization types, organizations and individuals that is present in the architecture. The Supporting Architectural Constructs providing architectural properties and attributes are as follows:

 

  • Measures: All form of measures (metrics) applicable to architectures including needs satisfaction measures, performance measures, interoperability measures, organizational measures, and resource physical measures (e.g., mass.). The magnitude of some attribute of an individual.

 

  • Locations: A point or extent in space that may be referred to physically or logically.

 

  • Pedigree: The origin and the history of something; broadly: background, history.

 

DM2 Data Dictionary and Model Files

The DM2 LDM description provides the essential aspects of the standard terminology used as the basis of DM V2.0. The DM2 provides the standard data lexicon definitions and the logical relationships between elements of the lexicon. The DM2 defines the common architectural description lexicon across the 6 major processes of the DoDAF. That terminology and its mapping to other widely-used terms is contained in the DM2 Data Dictionary. The DM2 Data Dictionary is maintained in Microsoft Excel and has the following structure. It is best used using:

 

1. Microsoft Excel data filters to see only the items of interest. This is particularly useful when examining the "monster matrix", by filtering to the DM2 elements that are necessary or optional in a view.

 

2. Microsoft Excel "freeze panes" to view columns far to the right.

 

3. Row and/or column grouping (some are already included) or hiding to see the information of interest. For instance, you may be interested in the "monster matrix" but not the definitions, sources, etc.

 

The detailed model description including the detailed definitions, relationships and the lexicon mapping to the DM V2.0 views (models) are available as an Enterprise Architect (SPARX) file that can be viewed using a licensed copy of Enterprise Architect or a free viewer only. Since the DM2 is based on IDEAS, not UML, to see the diagrams correctly, an IDEAS profile should be installed.

 

LDM Diagramming and Use of UML as an Ontology Diagramming Tool

The IDEAS Model is represented in UML. The UML language is not ideally suited to ontology specification in its native form. The UML language can be extended through the use of profiles. The IDEAS Model has been developed using a UML Profile - any UML elements that are not stereotyped by one of the IDEAS foundation elements will not be considered part of an IDEAS ontology. The IDEAS Foundation specifies the fundamental types that define the profile stereotypes. The super-subtype structure in IDEAS is quite comprehensive, and showing the super-type relationships on some diagrams can result in a number of crossed lines. In these cases, super types of a given type will be listed in italic text in the top-right-hand corner of the UML element box.

The stereotype of an element in an IDEAS UML model is shorthand for the element being an instance of the type referred to by the Stereotype, though the type must be one that has been defined in the root package of the foundation. Hence, if the stereotype is < > then the element is an instance of an Individual. The following stereotyped classes, with their color-coding are used in the model:

 

1. <<Individual>> An instance of an Individual - something with spatio-temporal extent [Color Name: Grey (80%), Color Codes: R40 G40 B40]

 

2. <<Type>> The specification of a Type [Color Name: Pale Blue, Color Code: R153 G204 B255]

 

3. <<Individual Type>> The specification of a Type whose members are Individuals [Color Name: Light Orange, Color Codes: R255 G173 B91]

 

4. <<Tuple Type>> The specification of a Type whose members are tuples [Color Name: Light Green, Color Codes: R204 G255 B204]

 

5. <<Power type>> The specification of a Type that is the set of all subsets of a given Type [Color Name: Lavender, Color Codes: R204 G153 B255]

 

6. <<Name>> The specification of a name, with the exemplar text provided as a tagged value [Color Name: Tan, Color Codes: R255 G254 B153]

 

7. <<Naming Scheme>> The specification of a Type whose members are names [Color Name: Yellow, Color Codes: R255 G255 B0]

 

The following stereotyped relationships are used in the model:

 

1. <<type Instance>> a relationship between a type and one of its instances (UML: Dependency) [Color Name: Red, Color Codes: R255 G0 B0]

 

2. <<powertypeInstance>> a relationship between a type and its power set (UML: Dependency) [Color Name: Red, Color Codes: R255 G0 B0]

 

3. <<nameTypeInstance>> a relationship between a name and its Name Type (UML: Dependency) [Color Name: Red, Color Codes: R255 G0 B0]

 

4. <<super-subtype>> a relationship between a type and one of its subtypes (UML: Generalization) [Color Name: Blue, Color Codes: R0 G0 B255]

 

5. <<whole Part>> a relationship between an individual and one of its parts (UML: Aggregation) [Color Name: Green, Color Codes: R0 G147 B0]

 

6. <<named by>> a relationship between a name and the thing it names [Color Name: Black, Color Codes: R0 G0 B0]

 

7. <<tuple>>/<<couple> a relationship between a thing (UML: n-ary relationship diamond) [Color Name: Grey (80%), Color Codes: R40 G40 B40]

 

The naming convention for classes, attributes, and association names is camel case as follows:

 

1. Class names start with uppercase.

 

2. Attributes and association names start with lowercase.

 

3. Acronyms are all uppercase. Acronyms in the middle of a name are avoided because of the concatenation of the acronym uppercase and the succeeding string leading uppercase.

 

Note that the size of the icons is not indicative of their importance; the sizes are adjusted to reduce line crossings and bends to make the diagrams easier to understand. In some instances, the data model figures may be hard to read in a hardcopy printout but a version at full-resolution which can be zoomed in is published in the online DM V2.0 Meta-Model Data Dictionary. Definitions for the model terms are contained in the DM V2.0 meta-model data dictionary. This includes a summary of aliases, composite term definitions, authoritative source definitions, and rationale. 

 

Note that foundational classes are generally not shown on data group diagrams; this foundational material is found in the ideas foundation ontology tab. This includes super-subtype, whole- part, temporal-whole-part, overlap, type-instance (member-of), and before-after patterns. Also not shown are the data structures for classification marking of architecture information at the whole and element (portion) levels using the Intelligence Community – Intelligence Standard Markings (IC-ISM). The schema for the IC-ISM is in physical exchange specification (PES) tab. Lastly, note that the size of the icons is not indicative of their importance; sizes are adjusted to reduce line crossings and bends to make the diagrams easier to understand.

 

Presentation Types for DM2 Data

Within the DM V2.0 -model, the elements in the DM2 models (Views) are represented with time periods (temporal extents). Temporal extent can connote the future, thus allowing the models to represent “To-Be” capabilities and processes or the “before-after” aspects of the activities. Generally, Infinite Metaverse Alliance views, models and supporting data are represented in the following general forms:

 

Structural Models comprised of diagrams describing the structural or static aspects of architecture.

 

Behavioral Models comprised of diagrams describing the behavioral or dynamic aspects of architecture.

 

Tree Models-A type of structural model which can represent DM2 elements in a taxonomic form. These can represent “whole-part”, “super-subtype relationships or other relationships. These models are particularly important in maintaining traceability thru the various level of detail in representing the design or architecture. A Work Breakdown Structure (WBS) is an example of a model including both activities and/or performers in a decomposition tree.

 

Mapping: Views that provide matrix (or similar) mappings between two different types of information. This used to represent such things as functional and data allocations and traceability.

 

Tabular: Views which present data arranged in rows and columns, which generally amplify or have a direct relationship to the behavioral, structural (including ontological) models.

 

Pictorial: Views such as free-form pictures.

 

Timeline: Model comprised of diagrams usually describing the programmatic aspects of architecture ((E.g. Gant Chart). This is generally related directly to the WBS taxonomic model. These can also represent time in efficiency analysis of the activities in a process (e.g. LSS analysis).

 

DM2 Data Groups

Performers

Performer is a class of entities that are central to the description of architecture. It is the Who in the Architectural Development Process. The How, tasks, activities, and processes (composite of activities), are assigned to Performers to accomplish the desired outcome. Performers are further subdivided and allocated to organizations, personnel and mechanization. Rules, locations and measures are then applied to organizations, personnel and mechanization. Within this assignment and allocation process there are many major tradeoff opportunities. Automation (mechanization versus people) tradeoffs, analysis for items such as performance and cost/benefit are involved in the process. When these tradeoffs and associated decisions are sufficiently mature, an allocated baseline can be declared and initial work breakdown structures refined.

 

Data Group Descriptions

 

1. The first thing to note about Performer is that it can represent:

a. A Person Type such as described by the Amy’s Military Occupational Specialties (MOS). MOS describe Skills and their measurement. Includes Materiel assigned and necessary for the performance of activities, e.g., as per Army CTA-50. Note that Person Types have temporal whole-parts (states) such as in-garrison or deployed that may have different Materiel compositions and other associations such as applicable Rules.

b. An Organization (type or actual Individual Organization) meaning a mission chartered organization, not limited to just collections of people or locations, e.g., the Federal Bureau of Investigation (FBI) has a chartered mission and it chooses the locations, people, etc., to accomplish such.

c. System in the general sense of an assemblage of components – machine, human – that accomplish a function, i.e., anything from small pieces of equipment to FoS and SoS. 

d. Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types, and organizational elements.

e.  A Service, from a software service to a business service such as Search and Rescue.

f. Any combination of the above.

 

2. The performance of an Activity by a Performer occurs in physical space and time. That is, at some place and time, the Activity is conducted. This is referred to as a spatial temporal overlap, simply meaning that the Activity and Performer overlap in space and time. There are two ways in which a Performer spatial-temporally overlaps an Activity:

a. In the act of performing the Activity. This relationship is sometimes called assigned to for the purposes of traceability.

b. The other way is as part of a larger process (aggregated Activity). This is sometimes called allocated to and forms the initial stages of system or process decomposition. 

c. Allocated Performer elements (parts of Performers) are assigned Activities (or processes, tasks) in the initial stages of Performer definition.

 

3. A standard (Rule) constrains an Activity in general. Some of those constraints might also apply to the performance of the Activity by a Performer.

 

4. A Performer may have Measures associated with the performance of an Activity (e.g., target tracking accuracy.) It may also have Measures associated with the Performer overall (e.g., operational condition.)

 

5. Performers perform at Locations that can be specific positions or areas, regions, or installations, sites, or facilities. Location type requirements/capabilities of a Performer are captured/expressed via the Activities that are performed under certain Conditions (e.g., must be able to perform Maneuver under Desert Conditions.)

 

6. Activities performed by a System can be called system or service functions (i.e., activities and/or processes performed by a system). System or service functions (activities) are allocated to hardware, software, firmware or personnel (when the person is considered integral to the system).

 

7. In typical uses, the Activities are represented by verbs and Performers are represented by nouns. This distinguishes the how from the who. In a typical specification process allocation to performers can take place at varying levels of detail depending on the design maturity or the intended degree of design constraint.

 

8. Performers are represented in many places and stages in the detailed architecture. It should be noted that a pure Requirements Architectural Description may not show allocations or performer. This may be left to later stages of the design process. Further, not all architecture modeling standards explicitly provide for allocation. For example, the Systems Modeling Language (SysML) extensions to the UML modeling standard have added this feature.

 

Usage in Core Processes

Data for Performer are used in the following ways:

 

JCIDS:

1. Person Type processes are typically termed Tactics, Techniques and Procedures (TTP) in Metaverse alliance. Procedures are allocated sets of activities and/or processes, where Tactics and Techniques, typically, are made up of the procedures as influenced by rules, doctrine, paradigms, etc. acquired through skill development during the education and training process.

 

2. A pure Requirements Architectural Description may not show allocations or performer. This may be left to later stages of the design process.

 

PPBE:

1. Programs of Record (PoR) are Projects that can contain both material and nonmaterial Performers (See FYDP Program Structure Handbook (Infinite Metaverse Alliance7045.7-H).

 

2. Program of Record are linked to the PPBE through the Work Breakdown Structure (WBS) (see DAS) depicting Performers related to cost.

 

3. The Planning and Programming*[1] process typically conducts analysis through the evaluation of Capabilities, Performers and the attributes associated with Performers (e.g. Measures). (e.g. "Gap and Overlap analysis", Capability evolution, etc.).

 

DAS:

1. MIL-HDBK-881A, in providing fundamental guidance for specifications, WBS, Statement of Works (SOWs) of the DAS, all require the identification of the Performers and their component parts and types as fundamental elements.

 

2. The acquisition process generally involves Performers either through the material acquisition of systems or the acquisition of processes associated with performers.

 

3. The acquisition process can also involve the Acquisition of Services.

 

SE:

1. Activities are assigned to Performers (organizational, human, materiel, or some combination thereof). Capabilities or lower-level derived capabilities, measures, conditions, constraints and other expressions of requirements are assigned to the various levels of Performer reification. Allocation occurs from level-to-level as part of structural design decomposition or design refinement.

 

2. Allocation is the term used by architects and engineers to denote the organized cross association (mapping) of elements within the various structures or hierarchies of a user view regardless of modeling convention or standard. The concept of allocation requires flexibility suitable for abstract system specification, rather than a particular constrained method of system or software design. System modelers often associate various elements in abstract, preliminary, and sometimes tentative ways. Allocations can be used early in the design as a precursor to more detailed rigorous specifications and implementations. As the requirements definition stage gives way to the design stage and actual components become visible, it becomes important to distinguish between allocated to and assigned to.

 

3. Some types of performers under configuration control called system Configuration Items (CIs). Software Configuration items are termed Computer Software Configuration Items (CSCIs) or Software Configuration items (SCIs) in MIL-HDBK- 881A. Hardware Configuration items may follow the Mil-STD-196E taxonomy (Central, Center, System, Subsystem, Set, Group, Unit.) MIL-HDBK-881A, which guides IMA Work Breakdown Structures (WBS), defines software only by levels (e.g., 1, 2, 3, etc.).

 

Ops Planning:

1. Determines who is going to accomplish the required tasks (activities), where, under what conditions, and to what measures.

 

CPM:

1. Performers are the major items in the portfolio to be managed and optimized.

 

Resource Flows

Resource Flows are used to model the flow of Resources - Materiel, Information (and Data), Geo-Spatial Extents, Performers, or any combination thereof. Resource Flows are key modeling techniques used in the definition of Interfaces and assurance of Interoperability between Activities and their associated Performers (e.g., Systems and Personnel.) Resource Flow models and associated analysis techniques reveal behavior such as:

 

  • The connectivity between resources.

 

  • Resource Flow modeling provides an explicit means to describe the behavior of activities, systems, organizations and their composite effects on the overall enterprise.

 

  • The content of the information flowing between resources (e.g., interface definition).

 

  • The order or sequential behavior (parallel or serial) of the resources in relation to one another (e.g., project task execution and critical path).

 

  • The behavior of Resource Flow between or within organizations (e.g., work flow, information flow, etc.).

 

  • The changes in state during the spatial and/or temporal existence of the resource.

 

  • The rules that modify the behavior of the Resource Flow (e.g., business rules, controls, decisions, etc.).

 

  • The measures that define the quality, constraints, timing, etc. of the Resource Flow (e.g., Quality of Service (QoS), measures of performance, measures of effectiveness, etc.).

 

  • The flow of control orchestrating the behavior of the Resource Flow.

 

Information and Data

Information is the state of a something-of-interest that is materialized, in any medium or form, and communicated or received.  Although this may entail some formality such as describing relationships between concepts, its purpose is to convey the interests in the operator, executive, or business person's frame of reference.

Data is the representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means, and is concerned with the encoding of information for repeatability, meaning, and proceduralized use. While information descriptions are useful in understanding requirements, e.g., inter-federate information sharing requirements or intra-federate representation strategies, data descriptions are important in responsive implementations of those requirements and assurances of interoperable data sharing within and between federates.

 

Data Group Description

1. The key concept in this model is that Information describes some Thing - material, temporal, or even abstract, such as a relationship (Tuple) or set (Type).

 

2. Since Information is a Thing, Information can describe other Information, e.g., metadata.

 

3. A Name is a type of Information in that it describes a Thing. A Name may be short or long - there is no restriction. So a textual description can be thought of a just a long Name. Information is more general than text strings and could be structured, formalized, or include other manners of description such as diagrams or images.

 

4. Information, as a Resource Type, inherits whole-part, super-subtype, and before after relationships.

 

5. If Information is processable by humans or machines in a repeatable way, it is called proceduralized. Not all proceduralized information is necessarily computerized; forms are examples of data proceduralized for human repeatable processing.

 

6. Data to be proceduralized has associations such as parts and types as well as other application specific associations. So for an Entity-Relationship model, Attributes are associations with Entities and Entities are related according to verb phrases and cardinalities. In the physical schema, the fields are associated to data types.

 

7. The representation for Data is not intended to cover all the details of, for instance, a relational data base management system (DBMS) underlying Meta-model, but just those aspects necessary to support the decision-making of the core processes.

 

8. Architectural Descriptions describes architectures. An Activity Model is an example of an Architectural Description. Two subtypes of Architectural Description are called out - the AV-1 and the Manifest - because of their importance in discovery and exchange, respectively. Note that the AV-1 information can also be provided in a structured manner, using the Project data group to describe the architecture project's goals, timeline, activities, resources, productions, rules, measures, etc. In a typical development project, the architecture descriptions will be at increasing levels of detail, what John Zachman calls "levels of reification".

 

It should be noted that all methods, even the most philosophical and methodical, involve the ingestion of some record of the enterprise's processes, legacy information-keeping systems, and descriptions of what types of things it thinks it deals with. Upon collection of this raw data, terms within it are then:

1. Identified. This is done by noting recurring or key terms.

 

2. Understood. Definitions of terms are sought and researched. In most cases, there are multiple authoritative definitions. Definitions selected should be appropriate for the context of use of the term within the enterprise activities.

 

3. Collated and correlated. This is done by grouping seemingly similar or related terms.

 

4. Harmonized. In this step, aliases, near-aliases, and composite terms are identified. A consensus definition is formulated from the authoritative source definitions. Often super-subtype and whole-part relationships begin to emerge.

 

The next step is to relate the harmonized terms. Some of the relationships are implicit in the definitions and these definitions may contribute to the relationship description. At this point, the formality can vary. A formal ontological approach will type all relationships to foundational concepts such as whole-part and super-subtype. However, there are many metaphysical challenges with such an approach and it is not necessary for many applications. This constitutes the conceptual-level of modeling, defined and related terms, now considered concepts because the definitions and relationships lend a meaning to the terms. The conceptual model should be understandable by anyone knowledgeable about the enterprise. Super-subtype and whole-part relationships can provide cognitive economy.

Conceptual models can be done in Entity-Relationship or UML Class model style although any format that documents definitions and relationships is functionally equivalent. Note that the subtype concept in UML generally results in the subclass inheriting properties from the super type while in Entity-Relationship (E-R) modeling only the identifying keys are inherited directly; the other super type properties are available after a join operation.

At the logical-level, relationships may have cardinalities or other rules added that indicate how many of one instance of something relates to an instance of something else, the necessity of such relations, and so on. The concepts may also be attributed, meaning they will be said to have some other concept, e.g., the concept of eye has the concept of color. Often at the logical-level, the relationships are reified or made concrete or explicit. At the logical-level, this is done in case there is something additional that needs to be stated about the relationship, e.g., the quantity of some part of something or the classification of the related information, which may be different from the classification of the individual elements.

There may also be considerations of normalization, meaning that the database structure is modified for general-purpose querying and is free of certain undesirable characteristics during insertion, update, and deletion operations that could lead to a loss of data integrity. The benefits of normalization are to uncover additional business rules that might have been overlooked without the analytical rigor of normalization and ensure the precise capture of business logic. The logical model, though having more parts than the conceptual model, should still be understandable by enterprise experts. At the logical-level, some sort of modeling style is normally used such as Entity-Relationship or UML Class modeling.

At the physical-level, the exact means by which the information is to be exchanged, stored, and processed is determined. At this level, we are talking about data. The efficiency, reliability, and assured repeatability of the data use are considered. The datatypes, the exact format in which the data is stored are determined. The datatype needs to accommodate all the data that is permissible to store or exchange yet be efficient and disallow formats that are not permissible. The entities may be de-normalized for efficiency so that join operations don't have to be performed. Logical associations may be replaced with identifiers (e.g., as associative entities or foreign or migrated keys in Entity Relationship Diagrams [ERDs] or explicit identifier attributes or association classes in class models). Keys, identifiers, and other means of lookup are setup. Indexes, hashes, and other mechanisms may be setup to allow data access in accordance with requirements. The physical target may be any of the following:

1. Database – relational, object, or flat file.

 

2. Message exchange format – document (e.g., XML), binary (e.g., Interface Definition

Language (IDL)).

 

3. Cybernetic (human – machine), e.g., print or screen formats, such as forms.

 

Usage in Core Processes

Information and Data models are used in the following ways:

1. Commonality and Interoperability between Core processes

a. Information models materialize for enterprise participants what things are important to the enterprise and how they are related.

b. Information models can serve as a basis for standardization of terminology and concept inter-relationships for human, machine, and human-machine communications.

c. Information models can provide cognitive compactness for an enterprise's personnel through the use of taxonomies and other relationship structures. This can improve clarity, efficiency, accuracy, and interoperability of action within the enterprise.

d. Information models document the scope of things the enterprise is concerned with in a form that allows comparison with other communities of interest to reveal common interests.

e. COI coordination and harmonization.

f. Authoritative sources identification and management.

 

2. JCIDS and PPBE

a. Data and information models can be used to determine if a proposed capability will interoperate, be redundant with, or fill gaps in conjunction with other capabilities.

 

3. SE and DAS

a. Data models can be used to generate persistent storage of information such as in databases.

b.  Data models can be used to generate formats for exchanging data between  machines, humans, and machine-to-human. For example, an XSD is a physical data  model that is generally an exchange format. Web services can be used with relational DBMS' to generate XML for exchange in the format of the data model implemented in the DBMS. The underlying data models (the physical data model and the exchange  data format) do not have to be the same; a translator or mediator may be invoked to translate during the exchange.

c.  Data models can be used to compare whether Performers are compatible for data exchange.

d.  Interdependent data or information needs.

e. Data and information models can be used during milestone reviews to verify interoperability, non-redundancy, and sufficiency of the solution.

f.  Information models are useful in initial discovery of a service, to know what sorts of information it may provide access to or its accessed capabilities need. An information model is part of a service description.

g.  Data models are useful in knowing how to interact with a service and the capabilities it provides and for establishing the service contract. A data model is part of a service description and service contract.

h.  Database/sources consolidation and migration.

I. Standards definition and establishment.

j. Mediation and cross-COI sharing.

 

4. CPM

Data and information models can be used to determine if components of a portfolio have:

a. Overlapping data or information production (an indication of potential unwanted redundancy).

b. Data assets management.

 

Presentation

Presentation of Information and Data manifest themselves in the presentation of many of the other Data Groups. Modeling information and data have well established techniques and styles. Techniques for constructing and presenting models of Information and Data vary. They are taught in academic and vocational curricula. There is considerable literature, such as books, professional journals, conference proceedings, and professional magazines, on best practices, experiences, and theory. 

 

Rules

Rules are prescriptive sets of procedures regarding the execution of activities within an enterprise. Rules exist within the enterprise whether or not they are ever written down, talked about, or even part of an organization's consciousness. However, it is fairly common practice for organizations to gather rules in a formal manner for specific purposes. Business rules are a type of Rule that govern actions and are initially discovered as part of a formal requirement-gathering process during the initial stages of a Project or during activity analysis, or event analysis. In this case, the collecting of the business rules is coincidental to the larger discovery process of determining the workflow of a process. Projects such as the launching of a new system or service that supports a new or changed business operation might lead to a new body of business rules for an organization that would require employees to conceptualize the purpose of the organization in a new way. This practice of coincidental business rule gathering is vulnerable to the creation of inconsistent or even conflicting business rules within different organizational units, or within the same organizational unit over time.

The Infinite Metaverse Alliance Meta Model provides a set of clear, concise data about rules that facilitates the creation of rules and enables the sharing of those rules with others requiring similar information. A rule is not a process - the two, while related, are very different. A process is a transformation that produces new things (outputs) from existing things (inputs), while a rule prescribes the exact procedures to be used to ensure that the output is as to be expected in each instance that the process is executed.

 

Data Group Description

The following should be noted about the Rules Data Group:

1. A Rule constrains Activities. For example, a speed limit rule constrains driving activity. Some seemingly static rules have the effect of limiting possible activities. For example, a rule that security fences must be 10 feet high constrains the activity of building security fences. This constraint may apply or vary under certain conditions. For example, speed limits can be lower in poor weather conditions.

 

2. Security classification, security marking, releasability, etc. are types of Guidance. Similarly; a Rule is a stronger form of Guidance.

 

3. An important Constraint type is a Service Policy that constrains access to capability Performers.

 

4. Doctrine, by definition, constrains stakeholder action.

 

Usage in Core Processes

Rules data are used to create, document, and share rules of all types that support operational activities and/or the execution of capabilities in operational processes (composite activities). These data can include:

1. Processes that define transactions where data must be exchanged or passed to execute a specified activity, such as PPBE, CPM, JCIDS, or DAS.

 

2. Rules that define methods of accessing information or services within the net-centric environment, such as Ops, PPBE, CPM, or JCIDS.

 

3. The order of steps that occur in a series of actions that must be performed in a specific order, such as DAS, SE, PPBE, or CPM.

 

4. Rules defining analysis of options or future actions, such as Ops Planning, JCIDS, PPBE or CPM.

 

Data for Rules are used in the six core processes in the following ways:

1. JCIDS:

a. For Materiel Facility, Installation, and Site trade-offs as part of DOTMLPF analyses

b. For detailing Interoperability requirements.

c. In constraining requirements dealing with material and non-material solutions.

d. In relating Doctrine and TT&P to material and non-material solutions.

 

2. PPBE:

a. In the Planning and Programming process many rules are applied to cost-benefit tradeoffs, cost estimation, program structure, and program constraints.

 

3. DAS:

a. In both technical and programmatic aspects of the DAS.

b. In specification, standards, directives and guidelines.

 

4. SE:

a. In the architectural descriptions of systems describing both structure and behavior.

b. In standards applied throughout the design and development process.

 

5. Ops Planning:

a. Rules are the basic elements contained in Doctrine, TT&P and training publications. Rules are used throughout the development and architectural descriptions of Operational processes.

 

6. CPM:

a. In describing and governing both the programmatic and technical aspects of the portfolio.

b. In describing the standards and constraints applicable to the portfolio.

 

Presentation

Rules can be represented in many ways. Typically, behavioral and tree structures as well as various logic mapping techniques can be used to depict rules, their relationships and interactions. Conflicting rules can be identified using many well know logic analysis instruments and techniques.

 

DM2 Data Group

Goals

Goals data are defined to represent the desired effect, ends, visions, outcomes, objectives, etc. for which operational processes, projects, or special programs are conducted. Goals are used to help guide the Organizations to ensure that everyday operations are aligned to a strategic direction. A goal is an end toward which long-term, ongoing effort is directed. In general, goals are established to provide a description of the intended future state. They are established to provide a target to aim toward, whereby activity is focused on attaining the effect (goal). Goals provide participants in activities a sense of direction, and a view of what to expect as activity progresses toward some end point. A Goal (and its aliases) describe a desired state of a Resource (Materiel, Information, Performer, or Geopolitical.) Goals data can be expressed as enterprise goals-high-level strategic goals that apply to the entire organization-or as more specific operational goals that define desired outcomes of the work process.

 

Data Group Description

The following should be noted about the Goals Data Group:

1. Although the language sounds different, the meaning of a desired effect (a change in state of some object) is the same as the meaning of goal.

 

2. A desired change in the state of some object leads to activities constrained by Rules that are performed by Performers. Some Activities are considered Events because they are of near-zero duration with respect to the frame of discernment of the Vision, Performers, etc.

 

3. Within Infinite Metaverse Alliance, goals are identified and described to provide direction to Activities and to orient those Activities toward a desired effect. When a Performer executes anv Activity, the Performer does so within the limitations prescribed for the Activity (Rules) and aims toward a desired effect. That effect should either meet, or contribute to meeting, established Goals that reflect the vision of the organization.

 

Usage in Core Processes

Goals are established at all levels of the organization and each of the core Infinite Metaverse Alliance processes. Goals can be applied to the Enterprise or Solution architecture effort. Goals are particularly useful to teams undertaking an architecture development effort to evaluate the success of the effort and how the effort contributes to achieving higher level goals, mission requirements, capability developments, or development of Services and Systems to support Department or organizational business operations.

 

Data for Goals are useful for:

1. Scoping an activity to ensure that resources utilized in executing an activity contribute to the overall goals and vision of the organization.

 

2. Establishing rules under which activities are executed to create boundaries for efficiency and effectiveness (Constraints) and establishing those circumstances under which an activity is executed (Event).

 

3. Establishing measures to determine the success of an activity, consistent with an established goal.

 

Data for Projects can be used in the six core processes in the following ways:

1. JCIDS: In establishing desired and threshold capabilities. Traceability should always be maintained between Goals and capabilities. This should include measures, rules and pedigree.

 

2. PPBE, DAS, SE: Goals are established at all level of the design, development and acquisition process. Traceability throughout the various levels is essential to the proper management a control of cost, systems engineering and acquisition.

 

3. Ops Planning: In establishing Operational Plans Goals and objectives are established related to Missions. Goals can be described as both strategic and tactical.

 

4. CPM: In establishing both the technical and programmatic aspects of the portfolio.

 

Presentation

Goals are typically depicted in tabular or textual form. It is desirable that Goals be presented in a structured manner showing primary and derived goals. This enhances project traceability.

 

Capability

The Capability Data Group provides information on the collection and integration of activities that combine to respond to a specific requirement. A capability, as defined here is "the ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks." This definition is consistent with that contained in the JCIDS Instruction published by the Joint Staff.

 

Data Group Description

1. Ways and means are interpreted in DM2 language to be Resources and Activities

 

2. Because a Desired Effect is a desired state of a Resource (see Goals data group), a Capability is about states (persistence of current ones, or changes to future ones) of Resources.

 

3. Capabilities link to Measures (Metrics) through the Activities they entail and the Desired Effects sought.

 

4. Capabilities relate to Services via the realization of the Capability by a Performer that is a Service. In general, a Service would not provide the Desired Effect(s) but, rather, access to ways and means (Activities and Resources) that would.

 

Infinite Metaverse Alliance Meta Model for Capability

Usage in Core Processes

Data for Capabilities are used to describe the capability; define acquisition and development requirements necessary to provide the required capability; facilitate understanding of capability execution; develop/update/improve doctrine and educational materials in support of capability execution; and to facilitate sharing and reuse of data. The Capabilities Data Group (CDG) has a representation at varying levels, from enterprise level to solutions and applies to all Infinite Metaverse Alliance Corel processes. This includes enterprise goals associated with the overall vision, that provide a strategic context for the capabilities described by an architecture, and an accompanying high-level scope, more general than the scenario-based scope defined in an operational concept diagram. At this level, the CDG enables a high-level description of capabilities in decision-maker’s contexts that can be used for communicating a strategic vision regarding capability evolution. 

 

Factors considered in a Capability Based Analysis are:

1. Doctrine

 

2. Organizations

 

3. Training

 

4. Materiel

 

5. Leadership and Education

 

6. Personnel

 

7. Facilities

 

The following sections document how the Capability Data Group and DM2 support analysis of each of these factors.

 

In Joint Pub 1-02, Dictionary of Military and Associated Terms, doctrine is defined as "Fundamental principles by which the military forces or elements thereof guide their actions in support of national objectives. It is authoritative but requires judgment in application." The concept of judgment required in application deals with decision making and cannot be precisely modeled except perhaps as rules affecting the applicability of other rules. The parts of doctrine that can be modeled are included in the capability data group as follows:

1. Principles are modeled as Rules.

 

2. Military forces and elements thereof are modeled as types and assemblies of Performers.

 

3. Actions are modeled as Activities.

 

Thus, doctrine is contained in the specification of certain fundamental Rules, Activities, and Performers and the relationships among them. These relationships are:

1. Each Performer must be of one or more Activities.

 

2. Each Activity must be by one or more Performers.

 

3. Each Rule may be a constraint on one or more Activities.

 

4. Each Activity may be constrained by one or more Rules.

 

5. Each Rule may be a constraint on one or more Performers.

 

6. Each Performer may be constrained by one or more Rules.

 

Thus, since the DM2 contains the entities and relationships listed above it contains the necessary and sufficient set of entities and relationships to permit the modeling of doctrine and a separate data group for Doctrine is not required.

 

Organization. An organization is a specific real-world assemblage of people and other resources organized for an ongoing purpose. DM2 models Organizations as a type of Performer. Defining an Organization as an assemblage means that each Organization exhibits a whole/part relationship whereby each Organization may be an assembly of other Organizations and each Organization may also be a component of one or more other Organizations. The following DM2 relationships are involved in the capability based analysis of Organization where each Organization is a type of Performer:

1. Each Capability must be the result of one or more Activities.

 

2. Each Activity must be by one or more Performers, where each Performer must be a type of Organization, therefore, each Capability must be provided by one or more Organizations.

 

3. Each Organization must be the Performer of one or more Activities.

 

4. Each Rule may be a constraint on one or more Organizations.

 

5. Each Organization may be constrained by one or more Rules.

 

6. Each Rule may be a constraint on one or more Activities.

 

7. Each Activity may be constrained by one or more Rules.

 

Training is defined as an activity or set of Activities to increase the capacity of one or more performers to perform one or more tasks under specified conditions to specific standards:

1. Each Performer may be either an Organization or a Person.

 

2. Each Performer must be of one or more Activities.

 

3. Each Activity must be performed under one or more Conditions.

 

4. Each Activity must be completed to meet one or more Standards.

 

5. Each Standard must be specified by one or more Measures.

 

Materiel is a type of Resource. Like Organization above, each Materiel exhibits a whole/part relationship whereby each Materiel may be an assembly of other Materials and each Materiel may also be a component of one or more other Materials.

 

The following DM2 relationships are involved in the capability based analysis of materiel where each Materiel is a part of a Performer:

1. Each Performer must be assigned to one or more Organizations.

 

2. Each Performer must be used by one or more Persons, where each Person must be the member of only one Organization at any one time.

 

3. Each Capability must be the result of one or more Activities.

 

4. Each Activity must be by one or more Performers, where each Performer must be either an Organization or a Person using a Performer.

 

5. Each Performer must be the Performer of one or more Activities.

 

6. Each Rule may be a constraint on one or more Performers.

 

7. Each Performer may be constrained by one or more Rules.

 

8. Each Rule may be a constraint on one or more Activities.

 

9. Each Activity may be constrained by one or more Rules

 

Leadership and Education. Joint Pub 1-02 does not define leadership. In the context of the DM2, leadership is defined as the ability to lead. Joint Pub 1-02 defines education as the systematic instruction of individuals in subjects that will enhance their knowledge of science, communication and the arts. Thus, to a certain extent, leadership is a set of skills that can be taught and a smaller set of skills that can be trained as Activities that must be performed under specified conditions to meet specified standards. Leadership is about the judgment required in application of doctrine; it deals with decision making and cannot be precisely modeled except perhaps as rules affecting the applicability of other rules.

 

Personnel. Personnel refer to Persons. Each Person is a type of Performer. The following DM2 relationships are involved in the capability based analysis of materiel where each Person is a type of Performer:

1. Each Person must be assigned to only one Organization at any one time.

 

2. Each Person may the user of one or more Materials.

 

3. Each Materiel must be used by one or more Persons.

 

4. Each Capability must be the result of one or more Activities.

 

5. Each Activity must be by one or more Performers, where each Performer must be either an Organization or a Person using a Materiel.

 

6. Each Person must be the Performer of one or more Activities.

 

7. Each Rule may be a constraint on one or more Persons.

 

8. Each Person may be constrained by one or more Rules.

 

9. Each Rule may be a constraint on one or more Persons.

 

10. Each Activity may be constrained by one or more Rules.

 

Facilities. A Facility is defined as a real property entity consisting of underlying land and one or more of the following: a building, a structure (including linear structures), a utility system, or pavement. Please note that this definition requires that facilities be firmly sited on or beneath the surface of the earth. Things like tents, aircraft, and satellites that are not affixed to a single location on or beneath the surface of the earth are a type of Materiel. Materiel are germane to capability-based analysis through the following relationships:

1. Each Facility may be the site of one or more Performers and any Materiel that is part-of the Performer(s).

 

2. Each Performer may be at only one Facility or within a Materiel enclosure at any one time.

 

3. Because a Facility is an Individual, it has a spatial and temporal extent.

 

An Individual instance of Materiel has a spatial and temporal extent in contrast to a Type which does not. Generally Architectural Descriptions deal with Types of Materiel, not specific Individuals, e.g., not specific serial-numbered items of equipment. However, the DM2 does represent a Performer at a Location and, consequently, any Materiel that is part of the Performer would also be at the Location.

 

Presentation

Capabilities are typically depicted in tabular or textual form. In some cases, a pictorial is used to help clarify the Capability. It is desirable that Capabilities be presented in a structured manner showing primary and derived capabilities. Capabilities should be presented in a manner depicting traceability to both Activities and Goals.

 

Services

A Service, in its broadest sense, is a well-defined way to provide a unit of work, through which a provider provides a useful result to a consumer. Services do not necessarily equate to web-based technology or functions, although their use in the net-centric environment generally involves the use of web-based, or network-based, resources. Functionally, a Service is a set of strictly delineated functionalities, restricted to answering the what question, independent of construction or implementation issues*. Services form a layer, decoupling operational activities from organizational arrangements of resources, such as people and information systems. Finally, Services form a pool that can be orchestrated in support of operational activities, and the operational activities define the level of quality at which the Services are offered. The Services Data Group provides those data that support the definition and use of Services within the net-centric environment. Section 2.7.1 identifies and describes the data within the group; Section 2.7.2 provides an example method for collecting data on services; Section 2.7.3 provides illustrative uses of the data, and Section 2.7.4 provides presentation examples for using the Services-related data for presentation to/for management in decision-making.

 

Data Group Description

Note the following guidance:

1. Services are activities done by a Service provider (Performer) to achieve desired results for a Service consumer (other Performer). A Service is a type of Performer which means that it executes an activity and provides a capability.

 

2. Capabilities and Services are related in two ways. One, the realization or implementation of a Capability by a Performer (usually a configuration of Performers, including Locations) may include within the configuration Services (or Service compositions) to access other Performers within the overall Performer configuration. Conversely, the realization or implementation of a Capability by a Performer (configuration, including Location) may provide the Performers that are accessed by a Service (or Service composition).

 

3. Services in DM V2.0 include business services, such as Search and Rescue. This is important to keep in mind because much of the SOA literature is IT-oriented.

 

3. Although, in principle, anything has a description, the importance of self-description for discovery and use of Services merits its call-out as a class. Further, because only a public-facing side is described, the Service description needs to represent that it describes the Service Port, not the entire Service. A Service Port is a special type of Port that is self-describing and visible. The Service Description of the Service Port is of all aspects necessary to utilize the Service and no more. As such, it may include visible functionality, QoS, interface descriptions, data descriptions, references to Standards or other Rules (Service Policy), etc. The inner workings of the Service are not described in a Service Description.

 

4. Since Service inherits whole-part, temporal whole-part (and with it before-after), Service may refer to an orchestrated or choreographed Service, as well as individual Service components.

 

5. Since Service Ports are types of Ports and Ports are types of Performers, they inherit all of Performer's properties, including Measures associated with the Performer, performance of Activities (Service Functions) with associated Measures, and provision of objects (Materiel, Data, Information, Performers, Geopolitical Extents).

 

6. Any Performer that consumes a Service may have a Service Port that is described in the service request. This description indicates how the Service provider should provide or respond back to the Service consumer. That is, Service Ports are parts of Performers that may or may not be Services themselves.

 

Usage in Core Processes

The Services Data Group captures service requirements for capabilities, performers and operational activities supporting all the core processes. The DM2 data elements describing Services are linkable to architecture artifacts in the Operational, Capability, System and Project Viewpoints.

 

Data for Service are used in the six core processes in the following ways:

1. JCIDS, PPBE, DAS and SE:

a. Services, such as those reified into web or computer based software services (Software as a Service (SaaS), are considered Performers and are used in the same fashion (See Performer Usage in Core Processes 2.1.2).

 

2. Ops Planning:

a. Service functions (activities and processes) and resources support operational Planning and other processes that facilitate the exchange of information among Performers, aid in decision making and support training. TT&P documents together with training materials generally contain the Service used in Operations.

 

b. Business processes (e.g. Administrative, Logistics, etc.) also can be reified as Services both manual and automated.

 

3. CPM:

a. Services such as SaaS can be part of a portfolio.

 

Project

A Project is a temporary endeavor undertaken to create Resources of Desired Effects. Projects are relevant to all six core processes. Projects form the major elements of the DAS and are the primary focus of the Infinite DoDAF PPBE system. The Primary Construct of the PPBE system is the Program Element (PE). The PE is defined as:

 

Program Element: The program element is the basic building block of the Future Years Defense Program. The PE describes the program mission and identifies the organization responsible to perform the mission. A PE may consist of forces, manpower, materiel (both real and personal property), services, and associated costs, as applicable.

The key architectural construct within the Program Element is the Work Breakdown Structure (WBS) subject to DoDAF Instruction. The WBS is the primary instrument connecting an Architectural Description to the Defense Acquisitions System and the PPBE processes. The Work Breakdown Structure (WBS) is defined as:

 

Work Breakdown Structure: "A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item". MIL-HDBK-881A provides guidance for constructing the WBS applicable to programs subject to DoDAF Instruction. The WBS is the process necessary for subdividing the major product deliverables and project work into smaller more manageable components and it serves as a valuable framework for the technical objectives, and therefore it is product oriented.

Its elements should represent identifiable work products, whether they are equipment, data, or related service products. A WBS is a product structure, not an organizational structure, providing the complete definition of the work to be performed by all participants and the required interfaces between them.

Hardware, software, services, data, and facilities are Resources in the DM2. The information captured in the project administrative tool/techniques (e.g., Project Management Body of Knowledge [PMBOK] 2004) provides the basis for resource information in the DM2. The WBS forms the basis of reporting structures used for contracts requiring compliance with ANSI/EIA 748 Earned Value Management System (EVMS) Guidelines and reports placed on contract such as Contractor Cost Data Reporting (CCDR), Software Resource Data Report (SRDR), Contract Performance Reports (CPR), and Contract Funds Status Reports (CFSR). MIL-HDBK-881A states: “the Program WBS and Contract WBS help document architectural products in a system life cycle. The DoDAF defines a common approach for Description development, presentation, and integration for warfighting operations and business operations and processes."

Just as the system is defined and developed throughout its lifecycle, so is the WBS. In the early Project phases of concept refinement, system architecture, and technology development, the program WBS is usually in an early stage of development. The results of the Analysis of Material Approaches and the Analysis of Alternatives (AoA) provide the basis for the evolution of the WBS at all stages of Project evolution. As the architectural design of the project's product or service matures, so should the WBS. The WBS is a primary tool in maintaining efficient and cost effective developments of products and services. 

 

Evolution of the Project WBS

A Project Plan contains the project WBS (including Tasks and responsible Organizations). The Project Data Group (PDG) contains the essential data required for defining a Project Plan, e.g., those required by DodAF:

1. Acquisition Strategy

 

2. Technology Development Strategy

 

3. System Engineering Plan.

 

The Tasks and Performers form the essential elements of the project's WBS. The use of both Tasks and Performers focusing on products to be delivered (e.g., System, Service, etc.) in the WBS is the essential premise of the product-oriented WBS defined in MIL-HDBK-881A. The Project Plan also shows plans and initiatives to coordinate transition planning in a documented program baseline, shows critical success factors, milestones, measures, deliverables, and periodic program reviews.

 

Data Group Description

There are several items to note regarding this model:

1. Like all concepts in the DM2, Project has whole-part, temporal whole-part, and super-subtype relationships so that major Projects can have minor Projects within them, Projects can have time phases, and Projects can be categorized.

 

2. Because a Project involves execution of a plan composed of Activities (Tasks), there is a flow of resources into the project's activities and a flow of products out of them, as described by the Resource Flow data group. So this model can describe a Project that results in a System, a Service, Personnel Types (i.e., Training), Organizations (i.e., organizational development), Materiel, or Locations (e.g., Facilities, Installations).

 

3. Because technology is part of the Project, this group models the analog of the DM2 SV-9 (System and Services Technology Forecast) and SV-8 (System and Services Evolution Description).

 

4. Many kinds of measures may be associated with a Project - needs, satisfaction, performance, interoperability, organizational, and cost.

 

5. Measures and Rules can be assigned at all levels of the Project decomposition. Top-level Measures and Rules (Conditions and Constraints) could be assigned to the Vision, Goals, and Objectives (VGO). Lower-level Measures and Rules can then be derived and assigned to compliance and test criteria. When part of a legal contract, policy, or directive, formal agreement, or contract instrument, the Rules constitute a principle portion of the requirements for the Project.

 

Usage in Core Processes

Data for Projects are used in the following ways:

1. JCIDS

a. Project is the typical outcome of the JCIDS process when material solutions are identified. 2)Non-material solutions may also result in projects b. PPBE, DAS, and CPM. 

b. Project is the core element of the PPBE, DAS and CPM processes. The primary construct of Project is the Work Breakdown Structure (WBS). The WBS is the primary reification within Project that relates Performers and Activities to Cost and Milestones. As stated in MIL-HDBK-881A, the WBS is a continually evolving instrument from Project conception to lifecycle management. This tracks closely with the evolution of the architecture. As key Activities are refined into primary Activities and assigned to or allocated to Performers, the WBS should mature and the project definition can gain additional focus (reification).

c. Early Project WBSs may contain high-level Activities (Tasks, Processes, System Functions, or Service Functions). As the Project matures, the WBS identifies the system components, such as subsystems and software configuration items (SCIs). The SCIs can be software services or individually testable and deliverable packages of software. Depending on the acquisition strategy, all or part of the Project WBS and, depending on acquisition strategy, may become the Contract WBS and form the basic outline of the requirements in a statement of work and the project Statement of Objectives (SOO) or Specification. The figure below illustrates this method.

d. The other, non-materiel portions of the WBS (Work Packages, Task and Activities) are derived in a similar fashion, i.e., Activities assigned to or allocated to Performers that are, in turn, assigned to Organizations, Personnel and Facilities.

 

2. SE

The data derived from Architectural Descriptions, derived through the systems engineering process, directly support the definition and structuring of Projects. The D2 data elements are used in the WBS, Architecture based and Classical Specifications and the SOW essential to the systems engineering process.

The DoDAF classical System Engineering techniques by standardizing the lexicon and relationships. The figure below illustrates the typical systems engineering process and its relationship to DM2 constructs. The process shows how operational needs, as described in description documents such as the Capabilities Description Document (CDD), are translated into structured, engineerable requirements and associated Project constructs. Further, this shows how capabilities and processes are transformed into Solutions through automation tradeoffs and Analysis of Alternatives (AoA). Various alternatives are iterated through the architectural descriptions to meet the required performance, cost, and schedule constraints. From here, Functional and Allocated baselines can be established. As increased detail is added to the architecture, classical systems engineering and design techniques are increasingly applied.

 

3. Ops Planning:

a. Project also is used in Operational Planning in such areas as developing specific Mission Plans and procedures. Any effort in the Operational community requiring identifiable funding and management can be defined as a Project.

 

Architectural Description Usage in Forming Project Structure Reified in the WBS

Presentation

Project presentation techniques are typically use Tree models (WBS), Timeline Models and Tabular information (e.g. spread sheets). Tree models containing products and organizations are represented in the PDG as whole-part breakdowns of the overall end-product and

participating organizations of the project. In the acquisition stages, the level of breakdown of this decomposition is dependent on perspective (e.g., SoS, Enterprise, System, etc.) and acquisition strategy.

 

Reification

Architectural descriptions such as activity models are example of architectural descriptions that reified at many level of detail. In a typical development project, the architecture descriptions (contained in plans, specifications and/or "model based" Computer Aided Design Tools (CAD)) provide increasing levels of detail as the project progresses through the normal DM2 Milestone process. This is what John Zachman calls "levels of reification”.

 

Usage in Core Processes

Reification is used in the six core processes in the following ways:

1. JCIDS: Refinement and increased levels of detail of capability and solution constraint descriptions from ICD to CPD.

 

2. PPBE: Refinement in Project or Program Work Breakdown Structures (WBSs) and Cost to complete estimates.

 

3. DAS: Refinement and Increase detail of design and architectural descriptions through the milestone review process.

 

4. SE:

a. Refinement and Increase detail of design and architectural descriptions through the various design and development stages.

b. Clearly described functional allocations and traceability throughout the various levels of architectural descriptions (e.g. specifications, architectural view and models).

 

5. Ops Planning: Refinement and increasing levels of detail in Tactics, Techniques and Procedures throughout the stages of operational plan development.

 

6. CPM: Refinement and increased detail in the descriptions of the capability, performance, functionality and cost effectiveness of the portfolio.

 

Presentation

Reification is depicted throughout all the elements of the architectural descriptions. It is evident in all levels of design detail or refinement. From one level to another level different people become involved in the architecture and design process. The reification process illustrates that at different levels, "one person's design becomes the next person's requirement". Reification can take all forms of descriptive techniques. Typically, the structural, behavior, tree models and views will be present throughout all the normal programs documentation (e.g. specifications, system engineering plans, procedural documents, training manuals, doctrine publications, etc.)

 

Measures

A measure is the magnitude of some attribute of an object. Measures provide a way to compare objects, whether Projects, Services, Systems, Activities, or Capabilities. The comparisons can be between like objects at a point in time, or the same object over time. For example, a Capability may have different measures when looking at the current baseline and over increments toward some desired end-state. Measures play a much greater, central role in MetaverseallianceV2.0, compared to earlier versions of Metaverse Alliance. This change has multiple drivers, including: Core Process use of architectural data. Those managements and engineering processes depend on quantification as a means of improving objectivity, accountability, and efficiency of the processes. Federal Enterprise Architecture (FEA) Performance Reference Model. There are many kinds of Measures that are applicable to many architecture elements. These are described in the following paragraph.

 

Data Group Description

1. Formally, a Measure defines membership criteria for a set or class; e.g., the set of all things that has 2 kg mass. The relationship between Measure and Measure Type is that any particular Measure is an instance of all the possible sets that could be taken for a Measure Type.

 

2. The lower part of Figure 20 depicts the upper tiers of a Measure Type taxonomy or classification scheme. It is expected that architects would add more detailed types (make the taxonomy more specialized), as needed, within their federate. Note that Service Level has multiple inheritances because a Service QoS or Service Level Agreement (SLA) could address User Needs, User Satisfaction, Interoperability, or Performance.

 

3. All Measure Types have a Rule that prescribes how the Measure is accomplished; e.g., units, calibration, or procedure. Spatial measures' Rules include coordinate system rules. For example, latitude and longitude are understandable only by reference to a Geodetic coordinate system around the Earth.

 

4. As a Measure Type, cost can be captured in the architecture at different levels, based on the Process-owner’s requirements.

 

5. The upper part of the figure above depicts how Measures apply to architecture elements. Note that they apply to relationships between objects; e.g., the Measure applies to a Performer performing an Activity. The Activity has a relationship to Measure Type that says what Measure Types apply to an Activity. This represents Universal Joint Task List (UJTL) tasks and their applicable Measure Types, including Conditions, that is, Condition is quantified by a Measure Type. (The whole-part relationship feature of Condition allows it to be singular.) This is accomplished by Condition's type Instance association, saying an elementary Condition is a member (instance) of a Measure Type class.

 

Usage in Core Processes

Data for Measures are used in the six core processes in the following ways:

PPBE and JCIDS:

1. Planning – adequacy analysis: From an adequacy point of view, Measures that are associated with a Capability (including Capability increment, since Capabilities have whole-part inheritance). Capabilities can be compared with the Measures associated with the Performers to see if the Performer solution(s) are adequate. A set of alternative Performers as part of an Analysis of Alternatives could also be evaluated. Goals or Desired Effects could compare with Measures associated with Performers.

 

2. Programming – overlap analysis: The purpose of an overlap analysis is to determine if there are overlaps, or undesired duplicative capability, in the spending plan, portfolio, capabilities development, or acquisition plan. Similar functionality is often only an indicator of overlapping or duplicative capability. Often Performers with similar functionality operate under different Measures which are not duplicative or overlapping capability. For example, operational-level situation awareness systems may not be as fast or precise as a tactical-level, but they may handle a larger number of objects over a larger area.

 

3. Goal Setting: Measures are often part of Goals; e.g., production or efficiency Goals.

 

4. Requirements: Requirements often have Measure elements.

 

5. Capability Evolution: Measures are part of capability evolution, showing increments of measurable improvement as the capability evolves and allowing monitoring about when the capability is projected to be achieved or has already been achieved.

 

SE and DAS:

1. System Engineering/Design: Measures set the design envelope goals, sometimes called performance characteristics or attributes. They can also set the constraints; e.g., cost constraints.

 

2. Performance–Cost Tradeoffs: Measures of performance (e.g., effectiveness) can be compared to different costs to evaluate and make decisions about alternative solutions.

 

3. Benchmarking: Measures can be used to establish benchmarks of performance, such as for a personnel skill or a radar tracking accuracy test.

 

4. Organizational and Personnel Development: Organizational and personnel goals are often established and then monitored using Measures.

 

5. Capacity Planning: Measures can be used to plan for needed capacity; e.g., for networks, training programs.

 

6. Quality of Service (QoS) Description: In SOA, QoS is often expressed as a Measure; e.g., bit loss rate or jitter. These Measures show up in the service description and are part of service discovery, so users can discover access to capabilities that meet their quality requirements.

 

7. Project Constraints: Measures such as cost and risk can be constraints on Projects.

 

CPM:

1. Portfolio Balancing. Measures can be used to balance a portfolio so that it achieves the right mix of goals and constraints. 

 

Ops Planning:

1. Organizational and Personnel Development. Organizational and personnel goals are often established and then monitored using Measures.

 

Presentation

Presentation Measures are typically displayed in tabular form and are usually tied to Structural, Behavioral or Tree models and their constituent elements. Measures can also be represented in a tree structure illustrating the traceability of derived metric requirements.

 

Locations

A location is a point or extent in space. The need to specify or describe Locations occurs in some Architectural Descriptions when it is necessary to support decision-making of a core process. Examples of core process analyzes in which locations might have a bearing on the

decisions to be made include the following:

1. Base Realignment and Closure (BRAC) (SE process).

 

2. Capability for a new regional command (JCIDS).

 

3. Communications or logistics planning in a mission area (Ops process).

 

4. System and equipment installation and Personnel Type assignments to Facilities (Operations and SE processes).

 

Examples where Locations play little, if any, role in the process are:

1. Prioritization of precision engagement programs (PPBE and portfolio management processes).

 

2. Streamlining of a business process (SE process).

 

3. Doctrine development (JCIDS and Operations processes).

 

The role of Locations in the decision process was implicit in earlier versions of DoDAF. In this version, they are treated explicitly and precisely to allow more rigorous analysis of requirements (e.g., communications or logistics planning) and clearer differentiation among solutions alternatives).

 

Data Group Description

There are several items to note:

1. Addresses such as URLs, Universal Resource Names (URNs), postal addresses, data link addresses, etc. are considered Names for Locations. For example, a postal address is a naming system for the Location of a building. A Universal Resource Locator is a name for a server that is located somewhere on the Web.

 

2. The naming pattern works by identifying the following:

a. the name string,

b. the object being named, and

c. the type of name (e.g., postal address). Name here is used in the broadest sense, such that a description is considered a long name.

d. The lower left of the diagram is a model of types of Location objects. These can be alternatively named using the naming pattern in the upper left and delineated using the Extent pattern in the lower right.

e. Minimal parts of the Spatial Extent (Point, Line, Surface, and Solid Volume) are detailed because of the varying requirements within a federate. That is, member of the federate may need to specialize the Spatial Extents. Some common and simple classes are modeled, such as a Line described by two Points and a Planar Surface defined by a Line and Point.

f. Facilities are types of Locations. In prior versions of DoDAF it was not clear if a Facility could be thought of as a system or just a Location. This is now clarified. To describe the functionality of a Facility, the Activities performed by the Performers located at the Facility are described.

g. Installation, Site, and Facility follow Army guidance from the Real Property Inventory Requirements (RIPR). Similarly, a Facility can be a linear structure, such as a road or pipeline.

h. Geofeatures (called FEATURE in Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM)) cover man-made control features, as well as geophysical features (including meteorological and oceanographic phenomena).

 

DoDAF Meta Model for Locations

For many architecture applications, a locating scheme is some kind of geometric system because many uses (see next paragraph) require geometric calculations. Additional considerations in modeling Location data are as follows:

 

1. Named locations (e.g., facility, base, installation, region names) can be applicable since their use may be merely to describe where performance occurs. In addition, the naming pattern basically can use the name as a surrogate for the geometric location, such as postal addresses are rarely applicable to architectures.

 

2. If a geometric system is needed, the coordinate system, reference frame, and units are chosen. The Geospatial Markup Language (GML) defines 26 different kinds of coordinate systems, including one called user defined. In many cases, a federate may choose reference to GML so issues like handed-ness and orientation don't have to be defined again.

 

3. The accuracy should be determined. For many uses, Locations may not need to be as accurate as some Geospatial system can be, since the use calculation may have many approximations, assumptions, and minor influencing variables that are chosen to be ignored.

 

4. In some cases, there may be need for speed and acceleration ranges. Since these are unusual, they are not part of the core DM2 but would be added as extensions for these kinds of models. The speed could be extended as an attribute or as a trajectory consisting of a set of spatial-temporal points, where the trajectory is a whole and the points are parts.

 

Usage in Core Processes

Data for Locations are used to describe where Performers perform. The Location concept supported the system node in MetaverseallianceV1.0 and V1.5. In DoDAF V2.0, it is generalized and more precisely defined. Examples of the uses of the various types of Locations in all the core processes are:

1. Facility Locations allow description that certain systems or organizations are located at a specific facility. Note that the function of the Facility is determined by the Activities performed by the Performers located at the Facility; that is, the Facility itself is not a Performer.

 

2. Installation Locations allow descriptions of certain organizations that operate or use an installation.

 

3. Region Locations are used to describe what Performers and Activities are performed in certain regions.

 

4. A Point Location can be used to state when a Performer is located at a specific Point; e.g., latitude and longitude. When the location is not that specific, Regions, Countries, and other geometric shapes can be used.

 

5.  Line (set of lines) allows description of Performers located on, beside, or within some enclosing lines. The line could be described mathematically so that it could specify an orbit, e.g., that certain satellites are in some orbit.

 

6. Volume, e.g., that some systems cover a certain volume; e.g., an air defense system.

 

7. Addresses (names for locations) allow descriptions of where something is located using the address scheme; e.g., the URL address scheme allows for looking up the internet protocol (IP) and then the files on the server.

 

Presentation

Location is typically represented in architecture in pictorial diagrams, however tabular and other representations may be used depending on the "Fit-for-Purpose" application. In many instances, locations are depicted in conjunction with typical models and view used in architectural descriptions.

 

Pedigree

The pedigree data group represents the workflow for a Resource. It describes the Activities used to produce a Resource, e.g., a piece of Information. Of particularly high importance for architectural descriptions, is the production of architecture description information. (Architecture descriptions are types of Information since Information describes some Thing and architecture descriptions describe the architecture.) All aspects of the production workflow is describable with the Pedigree data group including:

1. What Resources were consumed in the production of the Resource

 

2. What Performers performed the production

 

3. What Rules constrained the production activity

 

4. What metrics (Measures) applied to the production and the Resources consumed

 

5. Where did the production occur

 

Data Group Description Usage in Core Processes

Pedigree is used to demonstrate the rationale for architecture description choices. In many systems engineering and requirements analysis processes, it is the means by which traceability information is maintained.

 

Presentation

Pedigree information is usually presented in traceability matrices, tables, or indented text. Sometime reverse-traceability information is presented, wherein the source (e.g., requirement) is listed and then the architectural artifacts that satisfy it are shown next.

 

General Pattern for EA Information Sharing and Data Exchange

The information to be shared varies across the core processes and is determined by the information needs of specific use cases within those core processes. 

 

Notional EA Information Sharing Use Cases

Core process use case stakeholders work with EA data developers to determine what information needs to be shared when in order to support the core process. A notional example of the resultant information exchange in shown in the figure below. Note that in this case, the data presented for decisions may not be EA data, but, rather, the analysis results from analyzing EA data.

 

Notional Pattern of EA Information Sharing for Assessment Processes

When exchanging architectural data, the PES is the specification for the exchange. The PES provides an efficient and standard means to ensure that data sharing can occur in a tool set agnostic, methodology-agnostic environment. Use of the by architects to document architectural data and information in tools, through spreadsheets, or other means, and deposit that data and organized information into federated repositories is facilitated by the common understanding underlying the use of the PES.

 

The DM2 PES XML schema (XSD) provides a neutral format for data exchange between EA data and data sources including:

1. EA databases.

 

2. Infinite DM2 Source Databases (e.g., DM2 Information Technology Portfolio Repository [DITPR]).

 

3. Unified Profile for DM2 and Ministry of Defense Architecture Framework (MODAF) (UPDM) and SysML-based Unified Markup Language (UML) Tools.

 

4. Other Information Technology (IT) and enterprise architecture Tools.

 

5. Modeling and Simulation Tools that are used in EA assessments, e.g., AoA’s.

 

6. Reporting Tools, e.g., for Chairman of the Joint Chief of Staff Instruction (CJCSI).

 

7. Systems Engineering Tools.

 

8. Other Federal agencies (e.g., Department of Homeland Security (DHS), Department of Justice (DoJ).

 

9. Coalition partners and North Atlantic Treaty Organization (NATO).

 

10. Other organizations with which DM2 exchanges Enterprise Architecture (EA) data (e.g., industry, States, National Government Organizations [NGO’s]).

 

Note that within any particular community above, there may be a data exchange format particular to that community. A particularly important case is the UPDM-SysML XML Metadata Interchange (XMI) format for data exchange of UML models. XMI provides a neutral way to exchange model data, including diagram data, between UML tools. A universal DM2 PES to XMI translation will allow UPDM-SysML tools to interoperate with the other tools and data sources used in DM2 EA.

 

XSD

The DM2 PES extensible Markup Language (XML) Schema Definitions (XSDs) is auto generated from the DM2 Logical Data Model. No additional semantics are added or changed. There are four DM2 PES XSD’s:

1. IDEAS Foundation, version 1.0

 

2. DM2 additional foundation

 

3. Classification marking (externally controlled)

 

4. DM2 exchange data

 

Top-Level Structure of a the DM2 PES XSD for Exchange The Ideas Data section contains all the DM2 domain data in a flat structure with elements linked together using standard XML document ID ref’s. A piece of this flat structure is shown in the figure below. All of the DM2 data that is to be exchanged is contained in this section.

 

Sample of the Ideas Data Section of the DM2 PES XSD for Data Exchange The Ideas Views section then specifies what DM2 views this data pertains to. A sample of this section is shown in the figure below. If a DM2 PES XML document is received and these views are indicated as being represented in the dataset, this XSD can be used to validate the document, to see that the mandatory data is present and that data that is not optional is not contained. Sample of the Ideas Views Section of the DM2 PES XSD for Data Exchange In-progress examples of DM2 PES XML documents are available to DM2 Working Group members on the DM2 Collaboration Site, and will be made available to the entire EA community.

 

DM2 Formal Ontology

The DM2 is founded upon the International Defense Enterprise Architecture Specification (IDEAS), a formal ontology foundation developed by the defense departments and ministries of the United States, United Kingdom, Canada, Australia, and Sweden in coordination the North Atlantic Treaty Organization (NATO). All DM2 Concepts and concept relationships inherit several rigorously defined mathematical properties from the IDEAS Foundation.

 

IDEAS Foundation Top-Level

The IDEAS Foundation is higher-order. It is extensional (see Extension [metaphysics]), using physical existence as its criterion for identity. In practical terms, this means the ontology is well suited to managing change-over time and identifying elements with a degree of precision that is not possible using names alone. The methodology for defining the ontology is very precise about criteria for identity by grounding reasoning about whether two things are the same using something that can be accurately identified. So, comparing two individuals, if they occupy precisely the same space at the same time, they are the same. 

Clearly this only works for individuals, but the principle can be used to compare types too. For two types to be the same, they must have the same members. If those members are individuals, their physical extents can be compared. If the members are types, then the analysis continues until individuals are reached, then they can be compared. The advantage of this methodology is that names are separated from things and so there is no possibility of confusion about what is being discussed. It is also four dimensionalist so that temporal parts (or states) can be represented, along with before-after behaviors. None of these foundation properties are unusual; they are all used in reasoning every day.

The basic concepts are:

1. Three basic types of Things:

a. Individuals are Things that exist in 3D space and time, i.e., have 4D spatial temporal extent.

b. Types, sets or collections of things. Two important Types are distinguished – ones whose members are Individuals and those whose members are other than Individuals. This is an important distinction between naïve set theory and type theory.

c. Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework.

 

2. Basic relationships:

a. Set theoretic: Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition. Type-instance, similar to “element of” in set theory

b. Mereologic: Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure. Temporal whole-part; e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity).

c. 4D Topologic: Overlap, Before-after Items of note:

1) Types include sets of Tuples and sets of sets.

2) Tuples can have other Tuples in their tuple places.

 

3. The participants in a super-subtype relationship can be from the same class, e.g., the Super type can be an instance of Measure Type as well as the subtype. This allows for representation of as much of a super-subtype taxonomy as is needed.

 

4. Power Type members are generated from some Type by taking all the possible subsets of the members of the Type. For example, consider the Type whose members are a, b, c. The power set would be:

 

5. For example, take the Individual Type AIRCRAFT, whose members include all the aircraft of the world. The power set generated from this set would have:

 

6. Some of these subsets are not used by anyone, e.g., the full set, the null set, or just some random subset. However, the second one, which might be name F-15 Type, is quite useful. The last example is not useful to most unless you are interested in the first (assuming the subscript 1 means first) of any particular aircraft type, e.g., if you were doing a study of first-off-the-line aircraft production lessons-learned. This is the usefulness of Power Types and why they are employed in DM2: they allow for multiple categorization schemes, according to someone else’s use, yet traceability back to the common elements so that the relationships between multiple categorization schemes can be understood.

This was a DM2 requirement – multiple categorization schemes or taxonomies – because across a large enterprise it is not possible to employ a single categorization scheme; rather schemes vary depending on function. For example, a weaponeer’s classifies ordnance is naturally different from a logistician’s, the former concerned with delivery means, lethality, etc. and the latter with weight, size, and other transportation issues.

 

7. Note also that a power set can then be taken of the power set. This allows for build up of what is often called a taxonomic hierarchy. These are quite useful in enterprise Architectural Descriptions. 

 

The DM2 utilizes the formal ontology of IDEAS because it provides:

1. Mathematical rigor needed for precision Architectural Descriptions that can be analyzed and used in detailed processes such as Systems Engineering and Operations Planning. type (~set) theory 4D mereotopology.

 

2. Deals with issues of states, power types, measures, space -- what is truly knowable vs. what is assumed.

 

3. Separates signs and representations from referents.

 

4. DM2 domain concepts are extensions to the formal foundation: Rigorously worked-out common patterns are reused: Super-subtype, whole part, temporal whole-part, type-instance, before-after, overlap Saved a lot of repetitive work – “ontologic free lunch” Model compactness through inheritance of superclass properties and common patterns. Economizes implementations Higher quality and consistency throughout due reuse of the rigorously worked out common patterns

 

5. Improved interoperation with Unified Profile for DM2 and MODAF (UPDM)-SysML tools which are following IDEAS concepts.

 

6. Improved opportunities for Coalition and NATO data exchange since MODAF is following IDEAS and NAF is interested in following IDEAS.

 

7. Agreed-upon analysis principles that provide a principled basis for issue analysis.

 

8. Better ability to integrate and analyze EA data for EA purposes. The advantage over free-text, structured documents, and databases in using this type of mathematically structured information is somewhat explained by the figure below that shows a spectrum of information structuring.

 

A Spectrum of Information Structuring

This shows that databases are really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings). The nature and purposes of EA require more than just storage, retrieval, and exchange, e.g., integration, analysis, and assessment across datasets. Founding DM2 on IDEAS provides the ontologic foundation supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).

Some of these structures are so fundamental in human reasoning that it's hard to see that computers don't have it at all. But they are needed if we want to use them for something more than just storage and retrieval. They have to be encoded it into them with formal methods.

 

DM2 Common Patterns

It is important to remember that even though these are not repeated in the descriptions of the data groups, they are nevertheless present in the model and apply to the data group concepts according to the Doman Class Hierarchy shown in the figures below.

 

IDEAS Foundation Concepts Applicable to all DM2 Data Groups

Description Scheme A Representation Scheme and Description Type whose members are intentionally descriptions.

 

Individual Performer A specific thing that can perform an action.

 

Information The state of a something of interest that is materialized -- in any medium or form -- and communicated or received.

 

Information Type Category or type of information.

 

Location A point or extent in space that may be referred to physically or logically.

 

Location Type The power type of Location.

 

Measure The magnitude of some attribute of an individual.

 

Measure Type A category of Measures.

 

Performer Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.

 

Representation A Sign Type where all the individual Signs are intended to signify the same Thing.

 

Representation Scheme A Representation Type that is a collection of Representations that are intended to be the preferred Representations in certain contexts.

 

Resource Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.

 

Rule A principle or condition that governs behavior; a prescribed guide for conduct or action

 

Service Level A measurement of the performance of a system or service.

 

Thing The union of Individual, Type, and tuple.

 

Associations 

Before After A couple that represents that the temporal extent end time for the individual in place 1 is less than temporal extent start time for the individual in place 2.

 

Before After Type An association between two Individual Types signifying that the temporal end of all the Individuals of one Individual Type is before the temporal start of all the Individuals of the other Individual Type.

 

Described by A tuple that asserts that Information describes a Thing.

 

Description Scheme Instance a Representation Scheme Instance that asserts a Description is a member of a Description Scheme.

 

End Boundary A temporal whole part couple that relates the temporal boundary to the whole.

 

End Boundary Type A temporal whole part couple that relates the temporal boundary to the whole taken over a Type.

 

Measure of Individual End Boundary End Boundary is a member of Measure

 

Measure of Individual Start Boundary Start Boundary is a member of Measure

 

Measure of Type End Boundary Type End Boundary Type is a member of Measure

 

Measure of Type Start Boundary Type Start Boundary Type is a member of Measure

 

Named by A couple that asserts that a Name describes a Thing. 

 

Naming Scheme Instance Name is a member of a Naming Scheme.

 

Overlap A couple of whole Part couples where the part in each couple is the same.

 

Overlap Type an overlap in which the places are taken by Types only.

 

Representation Scheme Instance a Type Instance that asserts a Representation is a member of a Representation Scheme.

 

Represented by A couple that asserts that a Representation represents a Thing.

 

Start Boundary The beginning of a temporal Boundary.

 

Start Boundary Type The beginning of a temporal Boundary Type.

 

Super Sub Type An association in which one Type (the subtype) is a subset of the other Type (super type).

 

Temporal Boundary The start and end times for the spatio-temporal extent of an Individual

 

Temporal Boundary Type The start and end times for the Individual members of a Type.

 

Temporal Whole Part A Whole Part that asserts the spatial extent of the (whole) individual is co-extensive with the spatial extent of the (part) individual for a particular period of time.

 

Temporal Whole Part Type A couple between two Individual Types where for each member of the whole set, there is a corresponding member of the part set for which a whole Part relationship exists, and conversely.

 

Type Instance A Thing can be an instance of a Type - i.e. set membership. Note that IDEAS is a higher-order model, hence Types may be instances of Types.

 

Whole Part A couple that asserts one (part) Individual is part of another (whole) Individual.

 

Whole Part Type A Couple Type that asserts one Type (the part) has members that have a whole-part relation with a member of the other Type (whole).

 

DM2 Domain Concepts Are Subtypes (Extensions) of IDEAS Foundation concepts. DM2 Associations Are Subtyped to IDEAS Mathematical Associations.