DoDAF/CADM v2.0 The State of DoD Architecting Improving the Practice of DoD Architecting

1. DoDAF/CADM v2.0The State of DoD ArchitectingImproving the Practice of DoD Architecting Steven J. RingPrincipal Information EngineerMITRE Corporationsring@mitre.org June 23, 2006

2. DODI 8115.bb Jan 2006 Why?Architectures And Decision-Making Process Policies DODI 8115.bb, Information Technology Portfolio Management (ITPM) Establishes DoD policy for managing Information Technology (IT) investments as portfolios within the DoD Enterprise (to include mission areas, subportfolios and Components) that focus on improving DoD capabilities and mission outcomes

3. ) Overall Mission Outcome Process: Aligning Architectures to Mission Outcomes Mission Outcomes Architectures are a means to an end and not anend to themselves mission decisions Decisions courses of action Decision Making Process analysis data Alignment Analytics:Tools/Methods architecture data IntegratedArchitectures Executable Architectures

4. State of DoD Architecting • Inability to support JCIDS capabilities-based planning processes with a useful architecture description of ends, ways, and means expressed as full range of DOTMLPF architecture alternatives • Inability to support Information Technology Portfolio Management (ITPM) [DoDI 8115.bb, 2006] process of managing investments as portfolios • Inability to support Systems acquisition and portfolio planning/ investment processes in an unambiguous way to compare architecture alternatives • Inability to link with enterprise systems engineering processes by providing information to support requirements development and analysis • Inability to support Service Oriented Architectures (SOA) As we near the end of the first generation of DoD architecting…DoD architecting, in general, is failing to meet expectations, that is, producing results in the language of those who need them – actionable decision information in support of core organizational processes

5. Why? Immature Practice • Product-Driven (versus Purpose-Driven) Architecting– Emphasis on discrete product development obscures real purpose in describing an architecture – results in “architecture for architecture’s sake” • Cottage Industry Architecting – Variations in methods, practices and results constrain DoD architecting to being a “cottage-industry” • Applying DoDAF in any repeatable way is improbable without first “interpreting some formalism into it” – usually dependent upon a few key practitioners who can “explain” away DoDAF’s gaps and inconsistencies • Less sophisticated practitioners, who are in the majority, remain confused and unsure how to apply DoDAF • Practice “check the box” and “PowerPoint” architecture just to get to the next program/ project development stage Characterized by (1) differing interpretations and definitions of DoDAF concepts combined with (2) variations in architecture development workflow processes, practices Results in architectures that cannot be federated, compared, analyzed, or assessed

6. DoDAF/CADM v2.0 Recommendations • Provide data-centric (not product-centric) approach to integrated architecting • Be unambiguous and semantically rich - eliminate semantic overloading of architecture data elements • Eliminate semantic overloading of an Operational View • Eliminate semantic overloading of requirements and solutions • Identify a core set of architecture elements • Ensure DoDAF architectures do not become dis-integrated • Support executable architecture development and analysis • Enable linking (“Federating”) producing and consuming architectures • Capture sufficient architectural detail for full DOTMLPF analysis (not just Material) • Support more than just Information Technology architecting • Support cost-benefit analysis through cost & constraint entities • Support multiple architecture methodologies including Service Oriented Architectures (SOA) • Support COI requirements for linking Information (data) perspectives to processes and system perspectives • Support all phases of JCIDS Capability-Based Planning and Analysis (capabilities, effects, ways and means) • Elevate DoDAF to the Enterprise Architecture Level • Support other Structured/Object Methodologies

7. 1. Provide Data-Centric Approach To Integrated Architecting • Lack of a single holistic model of all the concepts as the underlying foundation of 26 DoDAF products characterizes DoDAF as product-centric rather than data-centric • CADM (700+ tables, 2000+ attributes, 200+ value lists) is all about an efficient, normalized data model supporting storage of architecture data • More appropriate approach is to specify a holistic collection of descriptive concepts, in the form data types, that fully describe architectures and to use it as the foundation for architecture description • From this specification, views could be created as needed • Basis of a data-centric approach to architecture description

8. 2. Be Unambiguous And Semantically Rich - Eliminate Semantic Overloading Of Architecture Data Elements • Overloading - descriptive element conveys more than one semantic concept – ambiguous subject-to-differing-interpretations” by architects • Ex: “Operational Node” (combines WHO and WHERE) • [1] “…represent Organizations, Organization Types, and Occupational Specialties” • [2] “…produces, consumes, or processes information” • [3] Increasingly interpreted as platforms (ground, air, and sea), facilities, and systems in many architectures • DoDAF must be based on a fundament architecture principle that architectural elements be grouped according to the six Zachman interrogatives – WHO, WHERE, WHAT, WHY, WHEN, and HOW • It is primarily DoDAF’s inconsistent expression of semantics for the six interrogatives that characterizes it as semantically incomplete

9. WHATPRODUCT HOW FUNCTION WHERENODE WHORESOURCE WHENEVENT WHYRULE How at Where by Who How by Who Who at Where HOW generates WHEN WHERE groups controls consumes Includes groups produces accomplishes WHO WHAT WHY How at Where 2. Three-way Association Can Be Observed • From this fundamental architecture principle, three-way association between three of the column interrogatives can be observed • How at Where by Who

10. 3/4. Eliminate Semantic Overloading Of OV & Solutions • 3. Overload of Operational View • OV describe both (1) a human performer-only view and (2) an undifferentiated view that treats performers as neither human nor machine, but instead as resources composed of both • Only by examing context of each OV can one resolve the intention of the architecture • Eliminated by clearly delineating two separate ‘System View’ sub-views (Performer [human only] and Asset [machine-only] • 4. Eliminate Semantic Overloading of Requirements and Solutions • DoDAF/CADM treats a resource (i.e. requirement) tasked to accomplish a Function as the same thing as a role (i.e., solution) specified as needed to physically perform the Function • Treat Operational Resource (i.e. requirement) as set of Knowledge, Skills and Abilities (KSA) needed, or required, to accomplish a Function…and then treat “Performer/Asset (Role/System)” (i.e., ‘solution’) as existing human or machine tasked to perform the Function

11. WHATPRODUCT HOW FUNCTION WHERENODE WHORESOURCE WHENEVENT WHYRULE 3/4. Two System Sub-Views: Performer & Asset Operational View CONOPS Op Activity Op Product Op Node Op Resource Processes & Events System Views DesignStrategy Performer View PerformerActivities Information, Material Performer Node Performer(Role) Processes & Events Design Strategy Asset View Asset Functions Data Asset Node Asset(System) Processes & Events TechnicalStandards View Technical Strategy Standards/ Components Standards/ Components Standards/ Components Standards/ Components Standards/ Components

12. 5. Identify a Core Set of Architecture Elements • While DoDAF defines a set of products that make up an integrated architecture, it doesn’t identify any architecture elements within those products as being core building block foundations of integrated architecture • For example, while OV-3 is part of integrated product set, some architectures that only consist of an OV-3 are declared to be integrated without one ever producing an OV-2 or OV-5 • OV-3 is my architecture “syndrome” Need to define set of 4 core architecture elements – NODES (Where), RESOURCES (Who), PRODUCT (What), FUNCTIONS (How) from the 6 interrogatives – serve as basis and foundation of an integrated architecture

13. 6. Ensure DoDAF Architectures Do Not Become Dis-integrated • With no core elements identified, there is no consistent workflow process ordering of framework product development • It is precisely because one can start anywhere, that DoDAF architectures can become dis-integrated and inconsistent over time • One could start with an OV-3, jump to OV-2 and then develop an OV-5 • However, because an OV-3 is made up of activities and nodes coming from an OV-2 and OV-5, one could define activities and nodes in an OV-3 that never appear in OV-2 and OV-5 • Results in an architecture that is dis-integrated, out of sync and not useful for any purpose • Standard workflow procedure, associated with the capture of four core architecture elements, can be established to provide a consistent, repeatable, ordering of framework product development

14. NODE FUNCTION RESOURCE Data Entry 6. Standard Architecture Development Workflow • Borrow workflow from ABM as implemented by our three DoDAF tool vendor partners – Telelogic, Troux, Provision (1a) CreateFUNCTION Model (3) Create RESOURCE Model (2) CreateNODES Art of Architecture (1b) CreatePRODUCT Model (4) Associate FUNCTIONSwithNODES withRESOURCES (6) Complete NODE products OV-2, SV-1 with Need Lines & Interfaces (7) Generate OV-3 & SV-6 (5) Generate Exchanges(Operational, System) Automation

15. 7. Support Executable Architecture Development and Analysis • Majority of current twenty-six DoDAF products capture only “static” information • OV-6/SV-10 provide for “dynamic” views of operations • Need to analyze and assess operational and system dynamic “behavior” of how organizations and resources interact with each over time as part of DOTMLPF analysis • However, these products do not adequately address how to • Capture time dependencies and organizational resource (human and system) responsibilities • Integrate representations of rules, state dynamics and sequencing with structural descriptions depicted in OV/SV products • DoDAF architectures need to be able to capture sufficient details from six interrogatives (especially HOW, WHAT, WHO, WHEN, and WHY) to enable them to be transitioned and transformed from static to dynamic architecture

16. 7. Link Structural Entities To Behavior • Through an Action_Assertion_Rule such as: If (Condition) (Current_State) Then (Function) (Standard) (Constraint) (Next_State)

17. Producing Consuming External Source Activity A1 @ External Node 1 by External Role 1 External Sink Activity A2 @ External Node 2 by External Role 2 External Input External output Context Activity A0 8. Enable “Federating” Producing & Consuming Architectures • DoDAF does not provide for separate producing and consuming architectures that can be linked and federated • Can be accomplished by • 1) Explicitly defining new “External” core architecture elements (i.e., NODES, FUNCTIONS, RESOURCES) • Outside scope, “external”, of one producing architecture but inside scope, “internal”, of a second consuming architecture • 2) Extending Exchange definitions (OV-3, SV-6) to include these producing and consuming External core elements

18. 9. Capture Architectural Detail for DOTMLPF Analysis • DoDAF does not capture sufficient architectural detail needed for full DOTMLPF analysis • OV-4 is missing from DoDAF products identified as making up an integrated architecture • OV-4 fundamental to providing architecture detail for organizations and people • “[O]rganization” and “[P]ersonnel” of DOTMLPF • No current way to define “[T]raining” and “[L]eadership” aspects without OV-4 • Need to base an architectural taxonomy on 6 interrogatives which, in turn, can then be mapped to full range of DOTMLPF

19. 9. Mapping to DOTLMPF: Full Range of Analysis

20. 10/11 • 10. Support more than Information Technology Architecting • Activities and System Functions are only capable of producing and consuming Information Elements and Data Elements • 1) Products (Information, Data and Material) as inputs and outputs • 2) Events as outputs of Functions (e.g., Op Activity, Performer Activity, Asset Function) • 11. Support Cost-Benefit Analysis through Cost & Constraint Entities • Add cost and constraint architecture elements to the 6 interrogative elements

21. 12. Lack of support for Service Oriented Architectures (SOA) • One can not architect at a level of abstraction needed in SOA that separates service (i.e. requirement) from the “solution” • Current specific human/ machine resource implies one and only one unique RESOURCE solution • Enable OV to focus on how missions are accomplished at a level of abstraction independent of any specific RESOURCE solution • Can model at a level of abstraction where one is not constrained to a specific human/ machine solution… • One does not know a specific Operational Resource (human / machine) resource solution • Resource is identified as responsible for a mission but does not necessarily perform the mission • Dynamic range of human/ machine resource solutions are possible from totally manual to totally automated

22. (1) Humanalone (2) Smart Humansemi-automaticsystem (3) Less-skilled HumanHighly-automaticsystem (4) Systemalone 12. Dynamic Range of SOA RESOURCE Solutions • Dynamic range of human/ machine resource solutions goes from fully manual to fully automated • Human, alone, performs an activity (totally manual) • Human, requiring a high skill set, accomplishes the same activity but with a relatively simple system (semi-automatic A) • Human that doesn’t require such a high skill set accomplishes the same activity but with a system that provides a very high degree of functionality (semi-automatic B) • System provides all the functionality to accomplish the same activity so that no human in-the-loop is needed (totally automatic)

23. 13. Support Requirements For Linking Information (Data) Perspectives To Processes And System Perspectives • OV-7 and SV-11 can not support requirements for interoperability certification • OV-7 and SV-11 are “Logical Data Model” and “Physical Data Model” that “describe the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s Operational View) that govern the system data” [DoDAF, Vol II, pg 4-62] • Intent is to support interoperability between architectures • Not the case because there is no consistent agreement on what these products represent or where the data to populate these products comes from • 1) Define all inputs and outputs of OV-5 & SV-4 – i.e., Products (information, data, material) – as one of four core architecture elements • 2) Define OV-7 and SV-11 as source products for these elements

24. 14. Support All Phases of JCIDS Capability-based Planning And Analysis • Capability – “Ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks” • Define • Effects as a change to a condition, behavior, or degree of freedom resulting from the application of Capabilities and includes physical, behavioral, or knowledge changes. • Capabilities as combination of means (operational and support resources) and ways (activities) to achieve an Effect to a standard under specified conditions • Thus, a DoDAF v2.0 Operational Activity is accomplished by Performer/ Role fulfilled by an Operational Resource that provides a means to model “ways and means” of a Capability • Outputs (Products and Events) of Operational Activities/Processes are used to set Condition of a Rule that represents an Effect

25. 14. Capability-Based AnalysisRelating Solutions to Standards (Requirements and Constraints) DESCRIPTION REQUIREMENTS CONSTRAINTS EFFECTS “effect” “product” quality “product” cost results in satisfies OUTCOMES satisfies “condition” sets “product” requirement “product” constraint sets achieved thru sets budgets specified by measured by function constraint function requirement mission CAPABILITY comprises budgets achieved thru function resource requirement resource constraint accomplishes satisfies satisfies specified by measured by CAPABILITY SOLUTION resource cost resource resource characteristic

26. 15. Elevate DoDAF to the Enterprise Architecture Level • DoDAF architectures today are targeted at the system, project, and program level and not at the Enterprise level • DoDAF does not presently capture any details at the Enterprise level with regards to an enterprise’s strategic vision, mission, goals, objectives, performance measures, guidance, etc. • Define a new “Strategic View” with product(s) and architecture elements that provide definitions for • 1) Strategic vision, goals,, missions, etc • 2) Their linkages to four core architecture elements – NODES (Where), RESOURCES (Who), PRODUCT (What), FUNCTIONS (How) – and RULES (Why) within the OV/SV

27. 15. “Strategic View”

28. 16. Support Other Structured/Object Methodologies • We must grow and evolve to embrace new structured/object technologies and modeling methodologies like ABM, BPMN, and UML • DoDAF/CADM already directly supports IDEF0 so precedence has already been established for supporting methodologies • BPMN models could, possibly, replace OV-5 and OV6-C products • We need to establish a single holistic collection of descriptive concepts for the structured/object architecting communities as the bridge for bringing together concepts among structured/object methodologies • Based on the fundamental architecture principle – Architectural elements are grouped and classified according to the six Zachman interrogatives – WHO, WHERE, WHAT, WHY, WHEN, and HOW • Differing structured/object methodologies mapped to 6 taxonomies • IDEF0 activities, BPMN processes, ABM activities, UML activities all would get mapped to the HOW element • People, System, Actors, and all other human/machine resources get mapped to the WHO element • Data, Information, and material flow all get mapped to WHAT • …etc.

29. BPMN ABM Others UML 16. Mapping Differing Methodologies to Six (6) Fundamental Architecture Taxonomies IDEF0 CADM SV-1a OV-2 OV-5 SV-1b SV-4 OV-3 Others Others

30. Pillar 4Top Level DoDAF v2.0 Data Model WHERENODE WHENEVENT HOW FUNCTION WHYRULE WHATPRODUCT WHORESOURCE

31. What is Needed? A small yet powerful set of DoD architecture description concepts that will provide a semantically complete shared vocabulary for the DoD architecting community of interest that could serve as a formal foundation for development of a next-generation DoD Architecture Framework that will support interoperability between DoD architecting practices and also support architecture-based analysis in support of DoD core processes

32. WHATPRODUCT HOW FUNCTION WHERENODE WHORESOURCE WHENEVENT WHYRULE Separation into Three DoDAF “Views” Op Activity at Op Nodeby Op Resource Op Activity by Op Resource Op Resource at Op Node generates groups Op Node Op Activity Event Operational View controls consumes Includes groups produces accomplishes Op Resource Rule Op Product Op Activity at Op Node System Views

33. Performer Node Asset Node Performer Activity Asset Function Performer (Role) Asset (System) Info, Material Data Pillar 2Symmetrically Aligned Core DoDAF Elements System Operational Entities Entities CONOPS Design Strategy RULE Relationships Relationships Why Attributes Attributes Info, Material,Data Op Product PRODUCT Generated Generated What Need Line Interface Op Activity FUNCTION Op Exchange Data Exchange How Op Node NODE Where Org ResourceStructure Op Resource RESOURCE Knowledge Skills & Abilities Who Core Core ResourceAbilities Performance Process & Events Process & Events Network EVENT When

34. Op Activity (T) O=T(I) Pillar 3Four Core Architecture Building Blocks Elements WHATPRODUCT Info, Material,Data I O • Formalized representation of data subject to a functional process • Decomposes to component parts • –NO- dynamic time or dollar costs properties • Associated with Information Exchanges that DO have dynamic time and dollar cost$ properties • Representation of a means (transformation T) by which an Activity acts on some input (I) to produce a specific output (O) • Decomposes to sub-activities • Dynamic time and dollar cost$ properties • Zero dimensional topological primitive that defines topological relationships • Decomposes to sub-nodes • Collection of similarly related Activities (System Functions) performed by a Role usually at a place or location. • May represent an organization or organization type • Logical or functional grouping • Does NOT represent operational/ human roles • Roles represent Roles • –NO- dynamic time or dollar costs properties • Means (“mechanism”) used to perform an Activity • Decompose to sub-roles and sub-systems • Resource representations (“characteristics”) or KSAs) assigned to humans that perform activities • Roles analogous to a job title or job responsibility • Dynamic time and dollar cost$ properties

35. RESOURCE A FUNCTION A RESOURCE B FUNCTION B FUNCTION C NODE FUNCTION C FUNCTION D FUNCTION F FUNCTION G FUNCTION K NODE Representations • NODE is a grouping (collection of) RESOURCES performing FUNCTIONS • NODES encapsulates these RESOURCES and FUNCTIONS Op Node Prod OperationalActivity Prod

36. Op Node Prod OperationalActivity Prod Pillar 4Data Centric DoDAF Top Level OV Architecture Data Model Operational View OV-2 OV-5 OpNode OpActivity OV-7 OpProduct OpResource OV-4 OV-4 Op Structures Need Line Operational Exchange OV-3

37. Asset Exchange Performer Exchange SV-6b SV-6a Pillar 4Data Centric DoDAF Top Level SV Architecture Data Model System View Asset Architecture Performer Architecture SV-5a SV-1a SV-1b SV-4a SV-4b AssetNode PerfNode PerfActivity AssetFunction SV-5b Info/Mat Data Info Data Asset Node Perf Node Data Data Info PerformerActivity AssetFunction Info Performer(Role) Asset(System) SV-11b SV-11a SV-5c SV-3a SV-3b SV-7a SV-7b Network Org PerformerNeed Line AssetInterface

38. Pillar 4Top Level DoDAF v2.0 Data Model

39. Pillar 4Top Level DoDAF v2.0 Data Model WHERENODE WHENEVENT HOW FUNCTION WHYRULE WHATPRODUCT WHORESOURCE

40. DoD Architecture Survey Recommendations – 1/2 • EDUCATION-EDUCATION-EDUCATION • Vendor neutral • Aimed at 3 different levels: ground-level (architects), mid-level (project managers), high-level (upper management…GS-15/O-6 & above) • Concentrate on training young architects on analysis that provides answers to acquisition and program management…give architecture value that users can see • Institutionalize architecture certification as a core element for development of Services or any agency development of architectures • Training ideas suggested - apprentices • Required that architectures be developed by a DOD certified architect as part of DoD approval process • “Management View”…presenting architectures to upper management in their language [Richard Burk “OUTCOMES” – analysis results] • Simple AS IS, TO BE and OBJECTIVE Architectures at a high level to brief FLAG officers and Senior management who have no IT/architecture background • DOTLMPF analysis methodologies & techniques lacking • Continue evolving DARS interoperability specification and continue certifying COTS's tools based on the spec

41. DoD Architecture Survey Recommendations – 2/2 • Increase collaborative efforts on architecture products (Arch Federation effort) • Develop Joint Common Operational Activity List (COAL) and Joint Common System Function List (CSFL) to enable common context and content of architecture products across all Services architectural efforts • Tool interoperability…tools that work well to adopt directives to mandate DoDAF and DAR • DoD “version” of JP 1-02 Acronyms and Abbreviations (or an extension, update?) • Promote architecture success stories • Address DoDAF weakness issues • Increase awareness of value and need for Executable Architectures in the full spectrum of DOTLMPF analysis and DoDAF v2.0 overlays • Emphasis must be shifted away from “Product-Centered” architectures to “Data Centric” architectures • Need disciplined approach to developing fully integrated, unambiguous, and consistent architectures • Aligning integrated architectures to the decision making process can only be achieved by defining the core architecture data elements, their views, how they are all related together, and the resulting analysis used in the decision making process • Investigate DoDAF products that are being least produced (SV-10a, SV-10b), maybe reduce or even add new products??