Models and Illustrative View Examples - Enterprise Architecture Standards

1. Models & Illustrative View Examples <Org> <Date> Mr. Charles Thornburg Enterprise Architecture & Standards Directorate Office of the DoD Deputy Chief Information Officer (703) 412-7937 Thornburg_Charles@bah.com

2. Agenda • Foundational Concepts • Model Concepts and Examples • A “Fit-for-Purpose” Presentation Example

3. Audience and Presentations • This audience for this presentation is Operational Architects and the Architecture Team • This is the second of three presentations: • The first presentation is the overview for DoDAF V2.0 • This presentation covers “Models and Views” • The third presentation is a “Architect’s Walkthrough” • This presentation builds upon the overview presentation.

4. Performer Activity Organization System Measure Service . . . Foundational Concepts in DM2 • To understand one of the basic principles of DM2, it is necessary to understand the DM2 foundational concepts • These foundational concepts (and attributes) are inherited by the DM2 Classes and Associations: • Before After – captures sequence • Overlap – captures a connection • Super Sub Type – captures sets of things • Whole Part – captures assemblies or decompositions • Temporal – capture time or duration The foundational concepts are a primary principle of the DM2 and need to be understood as “automatically” being part of every Class or Entity and Association or Relationship in the DM2.

5. Concepts in AV-1 Overview and Summary • Activity • Constraint • Guidance • Information • Measure • Organization • Performer • Project • Resource • Rule • Vision

6. AV-1 Overview and Summary Information - DARS Registration Example

7. AV-2 Integrated Dictionary • The AV-2 presents all the CDM key concepts data used in an architectural description. • The AV-2 will mature over time. • The AV-2 could be generated at several stages in the architecture development. • Key Concepts are defined in the DM2 Conceptual Data Model

8. Capability Viewpoint Articulate the capability requirement, delivery timing, and deployed capability • The Capability Viewpoint was to standardize the way architecture efforts were capturing Capabilities in their Architecture Descriptions. By capturing the capabilities, their hierarchy, their dependencies, and their deployments, the CVs capture the appropriate data to identify gaps and overlaps, based on capability dependencies and deployment schedules. • Describes the scope and vision for the capability • The delivery phasing and dependencies of the capability • The deployment of the capability in a solution

9. Concepts in CV-4 Capability Dependencies • Capability • Performer May include: • Activity • Condition • Data • Desired Effect • Guidance • Location • Measure • Organization • Person Type • Project • Resource • Rule • Service • Skill • System

10. CV-4 Capability Dependencies Example

11. Concepts in OV-1 High Level Operational Concept Graphic • Architectural Description

12. OV-1 High Level Operational Concept Graphic Example

13. OV-1 High Level Operational Concept Graphic Example 2

14. OV-1 High Level Operational Concept Graphic Example 2 IDref 001 IDref 002 = graphic OV-1 IDref 003 = name “UPDM SAR Example” IDref 004 = graphic repscheme IDref 005 = name namescheme (001, 002) (001, 003) Name of RepScheme=“MIMEdGraphic” (002, 004) (003, 005) Name of NameScheme=“AlphanumicEnglish” “UPDM SAR Example”

15. Concepts in OV-2 Operational Resource Flow Description • Guidance • Measure • Information • Materiel • Organization • Performer • Resource Concepts that was “Node”

16. OV-2 Operational Resource Flow Description - NCES

17. OV-2 Operational Resource Flow Description - NCES

18. OV-2 Operational Resource Flow Description Example (Traditional) –This example also depicts Command Relationships

19. OV-2 Operational Resource Flow Description Example (Net-Centric) - Does not depict Command Relationships This can be high level (Network Resources) or detailed. The OV-2 can have several layers, with more detail. Correspondingly, on the SV-2 or SvcV-2 that supports the OV-2, it can have more details (a website URL) or have several layers, additional layers with more details (specific server names that support a website)

20. OV-2 Comparison

21. Concepts in OV-4 Organization Relationships Chart • Organization • Organization Type • Person Type Whole Part

22. OV-4 Organization Relationships Chart Example

23. Concepts in OV-5a Activity Decomposition Tree • Activity Whole Part

24. OV-5a Activity Decomposition Tree Example This is the decomposition of activities, e.g., a tire is part of a car. It does not indicate a Supertype-Subtype relationship (“IS-A”), e.g., a car is a vehicle, a truck is a vehicle.

25. Concepts in OV-6c Event Trace Description • Activity • Performer • Resource • System • Service Whole Part Temporal

26. OV-6c Event Trace Description Example

27. Project Viewpoint Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process. • Associates the Programs, Portfolios, Projects, or Initiatives to requirements • Describes a timeline with milestones and dependencies • Describes an Organizations’ effort to acquire and deliver Capabilities

28. Concepts in PV-1 Project Portfolio Relationships • Activity • Constraint • Project May Include: • Measure • Organization • Performer • Resource • Rule • Vision

29. PV-1 Project Portfolio Relationships Examples

30. Resource Rule Service Skill System Vision Concepts in PV-2 Project Timelines • Activity • Constraint • Project • Performer May Include: • Condition • Location • Materiel • Measure • Organization • Person Type Temporal Note: The concepts initalicsindicates additional concepts in PV-2 that do not/or may not exist in the PV-1

31. PV-2 Project Timelines Example This is High Level, geared toward Decision-makers and associated with activities and capabilities. It is NOT to replace day-to-day project management.

32. Concepts in SvcV-6 Services Resource Flow Matrix • Activity • Condition • Data • Guidance • Information • Location • Materiel • Measure • Performer • Resource • Rule • Service • Standard

33. SvcV-6 Services Resource Flow Matrix Example

34. Standards Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts • Renamed from Technical Standards View • Adds the Operational, Business and Industry standards to the Technical Standards

35. Concepts in StdV-1 Standards Profile • Activity • Agreement • Condition • Constraint • Data • Guidance • Location • Materiel • Measure • Organization • Performer • Project • Resource • Rule • Service • Skill • Standard • System • Vision

36. StdV-1 Standards Profile Example

37. Concepts in StdV-2 Standards Forecast • Activity • Agreement • Condition • Constraint • Data • Guidance • Location • Materiel • Measure • Organization • Performer • Project • Resource • Rule • Service • Skill • Standard • System • Vision Temporal

38. StdV-2 Standards Forecast Example

39. Concepts in SV-1 Systems Interface Description • Guidance • Information • Location • Materiel • Measure • Performer • Person Type • Resource • Rule • Standard • System

40. SV-1 Systems Interface Description Example NCES is deploying to both the SIPRNet and the NIPRNet. The intent is to have the two environments be as similar as possible. Because of resources available for testing, certification and accreditation, and deployment; there will be temporary differences as new versions are made available. Also, it is known that there will be some other differences at Initial Operational Testing and Evaluation. The largest ongoing difference between implementations on each network is the lack of a hardware token (which on the NIPRNet is the Common Access Card (CAC) for the DoD PKI) and the relative unavailability of SIPRNet PKI certificates for users. So the user-facing systems shall support the use of, but will not require, a PKI certificate on SIPRNet.

41. Concepts in SvcV-4: Services Functionality Description

42. SvcV-4: Services Functionality Description – NCES Collaboration Product Line Services End users invoke the Service through a client, web browser, or User Access Portal. The collaboration server establishes and manages virtual teams and collaboration sessions. The conference servers, typically deployed in multiple strategic locations across the network, provide whiteboard, application sharing, application broadcasting, and audio and video conferencing (streaming media). The chat and instant message servers, on the other hand, provide online chat, instant messaging and presence information. The virtual spaces (e.g., shared folders) allow geographically dispersed teams to share documents.

43. VDC-400 TACLINK 2000 C2 GCCS-J CPOF AFATDS F.P. GCSS-MC IOS(V)2 IOW MSIDS LOG. FIRES DNS Exchange IOS(V)1 IOW INTEL C2PC MAN. TSM Print Server Router Switch AN/PRC-150 PRC-117 EPLRS AN/MRC-142 SATCOM A “Fit-for-Purpose” View - The Cube Has Three Dimensions of Interfaces in DM2’s Concept of System - from USMC EAWG Across WF Functions – an interaction amongst Systems, itself a SoS which is a System. Abstracting the actual Network and Transport systems. As a “vertical” stack that provides the complete means for end-devices to communicate down to transport layer systems (e.g., through MODEM’s, gateways). This “system” is a type of dynamic or ad-hoc system, e.g., dynamic routing Within device-compatible “networks”, e.g., EPRLS. A network is a type of system in DM2 because it is a bunch of systems working together. As another “Fit-for-Purpose” variation, organizational dependencies can be added to this view.

44. Summary • DoDAF V2.0 does not provide examples of the Views. • DoDAF V2.0 focus is about the data. • Focus should be on the data needed for the Decision-makers and the appropriate Decision Support Systems (or Services). • The format of Views are up to the Decision-makers.

45. Questions?