Presentation is loading. Please wait.

Presentation is loading. Please wait.

NATO Architecture Capability Team (A-CaT) Workshop

Similar presentations


Presentation on theme: "NATO Architecture Capability Team (A-CaT) Workshop"— Presentation transcript:

1 NATO Architecture Capability Team (A-CaT) Workshop
USA on DoDAF-DM2 NATO Architecture Capability Team (A-CaT) Workshop Mr. Walt Okon 10 September 2012

2 Briefing Topics DoDAF, DoD Architectures, and DoD Processes Recap
Restructure and re-write of DoDAF version 2.03 Next initiatives: Federal Government Common Approach Systems engineering and architecture integration

3 DoDAF Focus Remains on DoD’s Six Core Processes
Periodic (annual): PPBE CPM DoD PPBE CPM White House Military Staff HQ (JCS) JCIDS Combatant Commands Doctrine Commands Training Commands Legend: BES — Budget Estimate Submission COCOM — Combatant Commander CPA — Chairman’s Program Assessment DAWG — Deputies Advisory Working Group FYDP — Future Years Defense Program MBI — Major Budget Issues Program ManagerPB — President’s Budget PEO/PM — Program Executive Officer/Program Manager  POM — Program Objectives Memorandum RMDs — Resource Management Decisions Event Driven: JCIDS DAS SE OPS Presidential Cabinet Civilians OPS DAS SE Acquisition Organizations

4 Six Core Processes, DoDAF Models, DM2, and IDEAS
Model (view) specifications Operational Capabilities Services Systems Data and Information Standards Projects DM2 The 52 DoDAF models and the DM2 are related via a matrix

5 The DM2 Has Three Levels DIV-1 (CDM) DIV-2 (LDM) DIV-3 (physical)
(This is where almost all the design and analysis work is done) DIV-3 (physical) (Auto-generated from the LDM) Logical Data Model (LDM) Reified and Formalized relationships Conceptual Data Model (CDM) Concepts and concept relationships Physical Exchange Schema (PES) XML encoding of LDM The DM2 has several levels, each of which is important to a particular viewer of Departmental processes. A conceptual level or Conceptual Data Model (CDM) defines concepts and relationships between them business language of the enterprise normative across the six core processes A logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematically A physical level or Physical Exchange Specification (PES) adds required NCDS metadata for security and pedigree to the LDM is generated from the LDM as a set of XSD’s, one schema per DoDAF-described Model

6 DoDAF Conceptual Data Model
anything can have Measures Condition Guidance is-performable-under Rule Activity Capability Standard Agreement constrains requires-ability-to-perform has consumes-and-produces is-performed-by is-realized-by Project achieves-desired-effect (a state of a resource) is-the-goal-of Resource describes-something Information Not shown but implied by the IDEAS Foundation: Everything is 4-D and so has temporal parts, i.e., states Everything has parts Everything has subtypes Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state. Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed. Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes. Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received. Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields. Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose. System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements. Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture. Service: 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. 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. Condition: The state of an environment or situation in which a Performer performs. Desired Effect: A desired state of a Resource. Measure: The magnitude of some attribute of an individual. Location: A point or extent in space that may be referred to physically or logically. Guidance: An authoritative statement intended to lead or steer the execution of actions. Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action. Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in. Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel. Project: A temporary endeavor undertaken to create Resources or Desired Effects. Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties. Materiel Performer Data System Organization is-at Location GeoPolitical Service PersonRole is-part-of

7 Conceptual Data Model Terms
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state. Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed. Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes. Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received. Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields. Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose. System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.* Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture. Service: 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. * Includes human operators

8 Conceptual Data Model Terms
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. Condition: The state of an environment or situation in which a Performer performs. Desired Effect: A desired state of a Resource. Measure: The magnitude of some attribute of an individual. Location: A point or extent in space that may be referred to physically or logically. Guidance: An authoritative statement intended to lead or steer the execution of actions. Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action. Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in. Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel. Project: A temporary endeavor undertaken to create Resources or Desired Effects. Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties.

9 DM2 Logical Data Model Builds on IDEAS
Four dimensionalist -- xyzt Extensional -- physical existence is the criterion for identity Signs and representations are separated from referents Mathematics: Type theory ~ Set theory Mereology (wholes and parts) 4D Mereotopology (spatio-temporal relations) Then domain concepts inherit several important properties. None of these foundation properties are unusual; they are all used in reasoning everyday: Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent. Types, sets of things. 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. 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). Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition. Interface; e.g., an overlap between two things. [1] Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.) mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology. or 9

10 DM2 Extends from IDEAS IDEAS Foundation DoDAF 2 Domain Concepts 10

11 Even Relationships Extend from IDEAS
IDEAS Foundation Associations DoDAF 2 Domain Concept Relationships Whole-part for Types Overlaps of Types Before-after for Types Type-Instances Description and naming Whole-parts Super-subtypes Temporal Whole-part of Types A&D Similarly, we type the associations by classifying them under their IDEAS foundation class. 11

12 DoDAF version 2.03 has new structure
Vol. I - Normative DM2 Conceptual Data Model (CDM) documentation DoDAF Viewpoints & Models Vol. II - Normative DM2 Logical Data Model (LDM) documentation DoDAF Model Specs DoDAF Glossary SparxEA .EAP DM2 LDM file Vol. III - Normative DM2 Physical Exchange Specification (PES) XSD file and documentation SparxEA .EAP IDEAS Foundation file and documentation Vol IV - Informative DoDAF Informative material (e.g., 6-step, approximately 30 articles) DM2 OWL-DL file and documentation NOT under formal CM 31 July 2012 12 12

13 Re-write of Names and One-Line Descriptions

14 New Names and One-Line Descriptions

15 Re-write of Descriptions Example: Organizations & Resources (OV-2)
Description. This model identifies and describes resources consumed and produced by activities performed by organizational-performers. Narrative. This model emphasizes the exchange of resources among organizational performers, that is, performers capable of responsibility. These resources include information, materiel, and performers. The dependency between a resource to be consumed by one activity and a resource produced by another activity may be described as the flow of resources from producer to consumer. Activities are modeled in OV-2 models only in detail sufficient to show the relationships between resources produced by the activities of one organizational performer and the resources consumed by the activities of other organizational performers. Activities are seen in OV-2 models much as they are in other DoDAF models. An activity consumes resources to produce resources. Performers in OV-2 models are resources who are capable of responsibility rather than resources that are materiel, systems, or services. Such performers—organizations and persons in roles—follow guidance, rules, and standards to carry out their activities. Performers carry out their activities under conditions that affect their performance.

16 Re-write of Descriptions Example: Organizations & Resources (OV-2)
Performers and other resources are related to their locations to ensure that resources to be consumed are available to activities when and where those resources are needed and that performers are there to carry out those activities when those resources are available. Activities and resources may be measured. Guidance of various sorts may refer to types of applicable measures, and specific measures for specific activities may be drawn from such guidance. Activities and resources shall be modeled. In particular, resources that are information shall be modeled. Types of organizations shall be modeled; specific organizations may be modeled. Persons in roles may be modeled. Types of locations of resources may be modeled, and specific locations may also be modeled. Rules and conditions may be modeled. Measures related to activities, resources, performers, locations, rules, and conditions may be modeled.

17 Short Descriptions Relating to DM2 Example: Organizations & Resources (OV-2)

18 Short Descriptions Relating to DM2 Example: Systems Composition and Interface Identification (SV‑1)
Description. This model identifies system resource flows and describes the composition (parts) of systems. and describes resources consumed and produced by system-activities performed by systems within a described architecture; in presentation, architectural-data are grouped by system. Narrative. This model emphasizes performers that are systems and interfaces between these performers, specifically, the overlaps between systems performing activities that produce resources and systems performing other activities that consume those resources. The role of a resource with respect to these activities changes from resource produced to resource consumed at such an interface. Activities are seen in SV-1 models as they are in other DoDAF models. An activity consumes resources to produce other resources. At least one performer carries out an activity. An activity is constrained by guidance, rules, and standards. Performers may carry out activities under conditions that affect its performance. The sorts of locations where resources are produced and consumed by these activities may affect the specification of performers to carry out those activities. Resources produced and resources consumed include information, performers, and materiel. In SV-1 models, resources are produced by activities that are performed by systems and performers capable of responsibility; these performers include organizations and persons in roles. These produced resources are consumed by other activities similarly carried out by other systems and other performers capable of responsibility.

19 Short Descriptions Relating to DM2 Example: Systems Composition and Interface Identification (SV‑1)
SV-1 models may use whole-part relationships to examine the composition of performers. A system may be considered as a part of encompassing performers. Similarly, a system may be considered as a whole whose parts comprise resources of all sorts, including information, materiel, performers capable of responsibility, and other systems. The DoDAF does not prescribe nor limit the details or levels of composition that SV-1 models may provide. Interfacing systems and the activities they perform shall be modeled. The resources produced and consumed by these activities as performed by these interfacing systems shall be modeled. Performers capable of responsibility, including persons in roles and types of organizations, may be modeled. Guidance for activities carried out by systems as performers and conditions that affect the performance of these activities may be modeled. The types of locations of resources may be modeled. The composition of systems as performers may be modeled: thus, resources that include these interfacing systems may be modeled, and resources that are included in the composition of interfacing systems, such as information, materiel, types of organizations, and persons in roles may be modeled. Measures of systems, activities, resources, other performers, materiel, types of locations, rules, and conditions may be modeled. Services shall not be modeled by SV-1 models.

20 Short Descriptions Relating to DM2 Example: Systems Composition and Interface Identification (SV‑1)

21 Initiatives: Federal Government Common Approach
Four primary outcomes Eight levels of scope Eight basic elements of an EA program Six sub-architecture domains 50 document artifacts Six reference models There are four primary outcomes that are enabled by the common approach to federal EA:  Service Delivery  Functional Integration  Resource Optimization  Authoritative Reference There are eight levels of scope for implementing an architecture using the common approach:  International  National  Federal  Sector  Agency  Segment  System  Application There are eight basic elements that must be present and be designed to work together in each agency EA program:  Governance  Principles  Method  Tools  Standards  Use  Reporting  Audit There are six sub-architecture domains in the common approach to Federal EA:  Strategic  Business Services  Data and Information  Enabling Applications  Host Infrastructure  Security There are six reference models in the common approach to Federal EA:  Performance Reference Model - PRM  Business Reference Model - BRM  Data Reference Model - DRM  Application Reference Model - ARM  Infrastructure Reference Model - IRM  Security Reference Model - SRM

22 Draft Artifact Working Group Strategic Plan Examples (6 of 11)
PRM Performance Reference Model Descriptions Other Framework Names S-1 Strategic Plan A description of the organization's vision, strategic objectives, a prioritization of the desired outcomes from achieving those objectives, the measurements that will demonstrate achievement, and the resources to be used to achieve them DoDAF CV-1, 2, 3, 5, 6 (Capability Effects, Hierarchy, Schedules, Deployments, and Activities) S-2 Concept Overview Diagram The high-level graphical/textual description of the operational concept. DoDAF OV-1 (Operational Concept) S-3 Capability Effects Supports the Strategic Plan by defining effects caused by activities conducted for capabilities and measures for these effects DoDAF CV-1 (Capability Effects) S-4 Capability Deployments and Dependencies Supports the Strategic Plan by defining schedules for the deployment of capabilities in terms of timelines, organizations, and locations and dependencies among effects caused by capabilities DoDAF CV-3, 4, 5 (Capability Schedules, Dependencies & Deployments) S-5 Capability Hierarchies Presents one or more hierarchies of capabilities and the types of hierarchical relationships between these capabilities DoDAF CV-2 (Capability Hierarchies) S-6 Organization Chart Presents the composition and relationships among organizational performers DoDAF OV-4 (Organizational Relationships)

23 Draft Artifact Working Group Business Services Examples (8 of 11)
BRM Business Reference Model Descriptions Other Framework Names B-1 Business Service Catalog Presents the business services, taken from the BRM, that are provided within the scope of the architecture and may also indicate business services that are consumed or used internally within the architecture DoDAF SvcV-1 (Service Composition) B-2 Business Service Capabilities A mapping between the business services and the capabilities that these services support DoDAF CV-7 (Capabilities Services) B-3 Business Case / Alternatives Analysis A summary of the planning, budgeting, acquisition, and management of federal capital assets sufficient to determine if investment funding should be recommended or continued OMB Exhibit 300 B-4 Business Value Chain Describes the information or resource flows between organizational performers DoDAF OV-2 (Organizations and Resources) B-5 Business Process Model Presents the hierarchical structure of organizational activities and activities performed by organizational performers to consume and produce resources DoDAF OV-5a&b (Operational Activities), Operational Activity Diagram, Business Process Diagram B-6 Business Process Services A mapping of business services provided by business processes. DoDAF SvcV-5 (Service Operational Activities Support) B-7 Business Process Sequences Supports the CONOPS by presenting sequences of activities performed by organizational performers OV-6c (Operational Activity Sequences) B-8 Concept of Operations (CONOPS) Organizes Business Processes Sequences into scenarios DoDAF OV-6c (Operational Activity Sequences)

24 Draft Artifact Working Group Applications Examples
ARM Applications Reference Model Descriptions Other Framework Names A-1 Application Inventory A registry of applications and services, the system functions or service activities they perform, and, optionally, prioritized or ranked. A-2 Application Service Matrix Interface relationships between services and applications DoDAF SvcV-3a&b (Service Interfaces to Services and Systems) A-3 Application Performance Matrix The measures (metrics) of applications DoDAF SV/SvcV-7 (System and Services Measures) A-4 Application Interface Diagram The identification of application resource flows and their composition DoDAF SV-1 (System Composition and Interfaces) A-5 Application Interface Matrix The interface relationships among systems DoDAF SV-3 (System - System Interfaces) A-6 Application Data Exchange Matrix The details of resource flows among systems; the activities performed; the resources exchanged; and the attributes (rules and measures) associated with these exchanges DoDAF SV/SvcV-6 (System and Service Resource Flows) A-7 Application Communication Diagram The means by which resource flows between applications occur DoDAF SV/SvcV-2 (Systems and Services Interface Means) A-8 Event Sequence Diagram A sequence of triggering events associated with resource flows and systems DoDAF SV/SvcV-10c (System and Service Activity Sequences) A-9 State-Transition Diagram The states systems transition to in response to events DoDAF SV/SvcV-10b (System and Service State Transitions) A-10 Software License Inventory A list of Commercial-off-the-Shelf (COTS) assets with details about each (installation date, original cost, condition and such). A-11 System/Application Evolution Diagram The planned incremental steps toward migrating a suite of systems and/or applications to a more efficient suite, or toward evolving a current system or application to a future implementation DoDAF SV/SvcV-8 (System and Service Evolution)

25 Draft Artifact Working Group Infrastructure Examples
IRM Infrastructure Reference Model Descriptions Other Framework Names I-1 Asset Inventory A list of assets with details about each (installation date, original cost, condition and such) Asset register I-2 Network Diagram Describes the means by which resource flows between systems occur DoDAF SV/SvcV-2 (Systems and Services Interface Means) I-3 Enterprise Service Bus Diagram TBD I-4 Hosting Concept of Operations Presents the high level functional architecture, organization, roles, responsibilities, processes, metrics and strategic plan for hosting and use of hosting services I-5 Technical Standards Profile Collects the various systems standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of an architecture DoDAF StdV-1 (Standards Profile) I-6 Technology Forecast The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future infrastructure development DoDAF SV/SvcV-9 (System and Service Technology and Skills)

26 Initiative: Better Alignment of Architecture and Systems Engineering
RD CBA System O & M DoDAF Viewpoints All (AV) Capabilities (CV) Operational (OV) Data / Information (DIV) Systems (SV) Services (SvcV) Standards (StdV) CV Validation & VAL Acquisition Model Decisions & Milestones MS-C TEMPcapabilities MSA System Validation CPD Capabilities Based Assessment (CBA) Material Solutions Analysis (MSA) OV Verification Technology Development (TD) MS-A DIV1 SVR JCIDS Documents Initial Capabilities Doc (ICD) Capabilities Design Doc (CDD) Capabilities Production Doc (CPD) Information Support Plan (ISP) ICD TEMPoperational Engineering & Manufacturing Development (E&MD) Prototyping System Verification REQM SRR VER SRD System Engineering Technical Reviews System Requirements Reviews (SRR) System Functional Reviews (SFR) Preliminary Design Reviews (PDR) Critical Design Reviews (CDR) Test Readiness Review (TRR) System Verification Review (SVR) SV SvcV DIV2 StdV TRR TEMPsystem SFR System Design Subsystem Verification CDDprelim; ISPprelim Typical Systems Engineering Work Products System Requirements Document (SRD) / Technical Requirements Document (TRD) / System Segment Specification (SSS) System Design Document (SDD) / System Segment Design Document (SSDD) Software Requirements Specification (SwRS) Software Design Document (SwDD) Interface Requirements Specification (IRS) Interface Control Document (ICD) / Interface Design Document (IDD) Data Base Design Document (DBDD) Test and Evaluation Master Plan (TEMP) SDD MS-B SV SvcV DIV2 StdV Component Design Component Verification PDR CDDfinal; ISPfinal SwRS; IRS CMMI Process Areas Requirements Development (RD) Requirements Management (REQM Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) CDR DIV3 SwDD; IDD; DBDD TS PI Build Unit Test Notional Systems Development “V”

27 Summary DoDAF 2 is responsive to DoD’s processes
DoDAF Meta Model (DM2) is conceptually simple yet highly expressive due to leveraging of IDEAS DoDAF version 2.03 is the a major re-write to align with: DM2 and IDEAS Federal Government Common Approach Systems Engineering

28 Questions?


Download ppt "NATO Architecture Capability Team (A-CaT) Workshop"

Similar presentations


Ads by Google