Do DAF CADM v 2 0 The State of

Do. DAF/CADM v 2. 0 The State of Do. D Architecting Improving the Practice of Do. D Architecting Steven J. Ring Principal Information Engineer MITRE Corporation sring@mitre. org June 23, 2006

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

3 Overall Mission Outcome Process: Aligning Architectures to Mission Outcomes Architectures are a means to an end and not an end to themselves Mission Outcomes mission decisions Decisions courses of action ) Decision Making Process analysis data Alignment Analytics: Tools/Methods architecture data Integrated Architectures Executable Architectures © 2005 The MITRE Corporation. All rights reserved.

4 State of Do. D Architecting As we near the end of the first generation of Do. D architecting…Do. D 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 n 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 n Inability to support Information Technology Portfolio Management ( ITPM) [Do. DI 8115. bb, 2006] process of managing investments as portfolios n Inability to support Systems acquisition and portfolio planning/ investment processes in an unambiguous way to compare architecture alternatives n Inability to link with enterprise systems engineering processes by providing information to support requirements development and analysis n Inability to support Service Oriented Architectures (SOA) © 2005 The MITRE Corporation. All rights reserved.

5 Why? Immature Practice Characterized by (1) differing interpretations and definitions of Do. DAF concepts combined with (2) variations in architecture development workflow processes, practices Results in architectures that cannot be federated, compared, analyzed, or assessed n 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” n Cottage Industry Architecting – Variations in methods, practices and results constrain Do. D architecting to being a “cottage-industry” – Applying Do. DAF in any repeatable way is improbable without first “interpreting some formalism into it” – usually dependent upon a few key practitioners who can “explain” away Do. DAF’s gaps and inconsistencies – Less sophisticated practitioners, who are in the majority, remain confused and unsure how to apply Do. DAF Practice “check the box” and “Power. Point” architecture just to get to the next program/ project development stage © 2005 The MITRE Corporation. All rights reserved.

6 Do. DAF/CADM v 2. 0 Recommendations 1. Provide data-centric (not product-centric) approach to integrated architecting 2. Be unambiguous and semantically rich - eliminate semantic overloading of architecture data elements 3. Eliminate semantic overloading of an Operational View 4. Eliminate semantic overloading of requirements and solutions 5. Identify a core set of architecture elements 6. Ensure Do. DAF architectures do not become dis-integrated 7. Support executable architecture development and analysis 8. Enable linking (“Federating”) producing and consuming architectures 9. Capture sufficient architectural detail for full DOTMLPF analysis (not just Material) 10. Support more than just Information Technology architecting 11. Support cost-benefit analysis through cost & constraint entities 12. Support multiple architecture methodologies including Service Oriented Architectures (SOA) 13. Support COI requirements for linking Information (data) perspectives to processes and system perspectives 14. Support all phases of JCIDS Capability-Based Planning and Analysis (capabilities, effects, ways and means) 15. Elevate Do. DAF to the Enterprise Architecture Level 16. Support other Structured/Object Methodologies © 2005 The MITRE Corporation. All rights reserved.

7 1. Provide Data-Centric Approach To Integrated Architecting n Lack of a single holistic model of all the concepts as the underlying foundation of 26 Do. DAF products characterizes Do. DAF 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 n 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 © 2005 The MITRE Corporation. All rights reserved.

8 2. Be Unambiguous And Semantically Rich Eliminate Semantic Overloading Of Architecture Data Elements n Overloading - descriptive element conveys more than one semantic concept – ambiguous subject-to-differing-interpretations” by architects n 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 n Do. DAF 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 Do. DAF’s inconsistent expression of semantics for the six interrogatives that characterizes it as semantically incomplete © 2005 The MITRE Corporation. All rights reserved.

9 2. Three-way Association Can Be Observed n From this fundamental architecture principle, three-way association between three of the column interrogatives can be observed – How at Where by Who WHAT PRODUCT HOW WHERE FUNCTION NODE WHO WHEN RESOURCE WHY EVENT RULE How at Where by Who How by Who WHERE Who at Where groups generates HOW ntr o WHAT ls s de clu In co es m su s ce WHO n co s om c ac u od p pr p ou gr es ish l WHEN WHY How at Where © 2005 The MITRE Corporation. All rights reserved.

10 3/4. Eliminate Semantic Overloading Of OV & Solutions n 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] n 4. Eliminate Semantic Overloading of Requirements and Solutions – Do. DAF/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 © 2005 The MITRE Corporation. All rights reserved.

11 3/4. Two System Sub-Views: Performer & Asset WHAT PRODUCT Operational View HOW WHERE FUNCTION NODE Information, Material Op Node Performer Activities Data Standards/ Components EVENT WHY RULE Op Activity Asset Functions Technical Standards View WHEN CONOPS Op Product System Views WHO RESOURCE Standards/ Components Op Resource Processes & Events Design Strategy Performer View Performer Node Performer (Role) Processes & Events Design Strategy Asset View Asset Node Asset (System) Processes & Events Technical Strategy Standards/ Components © 2005 The MITRE Corporation. All rights reserved.

12 5. Identify a Core Set of Architecture Elements n While Do. DAF 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 n 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 © 2005 The MITRE Corporation. All rights reserved.

13 6. Ensure Do. DAF Architectures Do Not Become Dis-integrated n With no core elements identified, there is no consistent workflow process ordering of framework product development n It is precisely because one can start anywhere, that Do. DAF 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 n 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 © 2005 The MITRE Corporation. All rights reserved.

14 6. Standard Architecture Development Workflow n Borrow workflow from ABM as implemented by our three Do. DAF tool vendor partners – Telelogic, Troux, Provision (1 a) Create FUNCTION Model (1 b) Create PRODUCT Model Data Entry (5) Generate Exchanges (Operational, System) (3) Create RESOURCE Model (2) Create NODES (4) Associate FUNCTIONS with NODES with RESOURCES (6) Complete NODE products OV-2, SV-1 with Need Lines & Interfaces NODE FUNCTION RESOURCE (7) Generate OV -3 & SV-6 Automation © 2005 The MITRE Corporation. All rights reserved.

15 7. Support Executable Architecture Development and Analysis n Majority of current twenty-six Do. DAF 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 n 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 n Do. DAF 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 © 2005 The MITRE Corporation. All rights reserved.

16 7. Link Structural Entities To Behavior n Through an Action_Assertion_Rule such as: If (Condition) (Current_State) Then (Function) (Standard) (Constraint) (Next_State) © 2005 The MITRE Corporation. All rights reserved.

17 8. Enable “Federating” Producing & Consuming Architectures n Do. DAF does not provide for separate producing and consuming architectures that can be linked and federated n 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 Producing External Source Activity A 1 @ External Node 1 by External Role 1 Consuming External Input External Context Activity A 0 output External Sink Activity A 2 @ External Node 2 by External Role 2 © 2005 The MITRE Corporation. All rights reserved.

18 9. Capture Architectural Detail for DOTMLPF Analysis n Do. DAF does not capture sufficient architectural detail needed for full DOTMLPF analysis – OV-4 is missing from Do. DAF 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 n Need to base an architectural taxonomy on 6 interrogatives which, in turn, can then be mapped to full range of DOTMLPF © 2005 The MITRE Corporation. All rights reserved.

19 9. Mapping to DOTLMPF: Full Range of Analysis Doctrine Activities, Nodes Performers (Roles), Assets (Systems) Examine Tactics, Techniques and Procedures Organization Org Units Examine organizational structure Training Activities, Performers (Roles), Assets (Systems) Train personnel on their activities and the systems they use Leadership Org Units, Performers (Roles), Assets (Systems) Examine leadership issues Material Asset (Systems) Functions, Assets (Systems), Asset (Systems) Nodes Examine materiel solutions – a new system? Personnel Performers (Roles) Examine personnel solutions – new personnel or personnel with better qualifications Facilities Performer Nodes, Asset Nodes Examine fixing, building or modifying facilities © 2005 The MITRE Corporation. All rights reserved.

20 10/11 n 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) n 11. Support Cost-Benefit Analysis through Cost & Constraint Entities – Add cost and constraint architecture elements to the 6 interrogative elements © 2005 The MITRE Corporation. All rights reserved.

21 12. Lack of support for Service Oriented Architectures (SOA) n One can not architect at a level of abstraction needed in SOA that separates service (i. e. requirement) from the “solution” n 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… 1. One does not know a specific Operational Resource (human / machine) resource solution 2. Resource is identified as responsible for a mission but does not necessarily perform the mission 3. Dynamic range of human/ machine resource solutions are possible from totally manual to totally automated – © 2005 The MITRE Corporation. All rights reserved.

22 12. Dynamic Range of SOA RESOURCE Solutions n Dynamic range of human/ machine resource solutions goes from fully manual to fully automated 1. Human, alone, performs an activity (totally manual) 2. Human, requiring a high skill set, accomplishes the same activity but with a relatively simple system (semi-automatic A) 3. 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) 4. System provides all the functionality to accomplish the same activity so that no human in-the-loop is needed (totally automatic) (1) Human alone (2) Smart Human semi-automatic system (3) Less-skilled Human Highly-automatic system (4) System alone © 2005 The MITRE Corporation. All rights reserved.

23 13. Support Requirements For Linking Information (Data) Perspectives To Processes And System Perspectives n 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” [Do. DAF, 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 n 1) Define all inputs and outputs of OV-5 & SV-4 – i. e. , Products (information, data, material) – as one of four core architecture elements n 2) Define OV-7 and SV-11 as source products for these elements © 2005 The MITRE Corporation. All rights reserved.

24 14. Support All Phases of JCIDS Capability-based Planning And Analysis n Capability – “Ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks” n 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 Do. DAF v 2. 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 © 2005 The MITRE Corporation. All rights reserved.

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

26 15. Elevate Do. DAF to the Enterprise Architecture Level n Do. DAF architectures today are targeted at the system, project, and program level and not at the Enterprise level – Do. DAF 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. n 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 © 2005 The MITRE Corporation. All rights reserved.

27 15. “Strategic View” © 2005 The MITRE Corporation. All rights reserved.

28 16. Support Other Structured/Object Methodologies n We must grow and evolve to embrace new structured/object technologies and modeling methodologies like ABM, BPMN, and UML – Do. DAF/CADM already directly supports IDEF 0 so precedence has already been established for supporting methodologies – BPMN models could, possibly, replace OV-5 and OV 6 -C products n 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 IDEF 0 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. © 2005 The MITRE Corporation. All rights reserved.

29 16. Mapping Differing Methodologies to Six (6) Fundamental Architecture Taxonomies F 0 DE I BPMN ABM rs he Ot UM L CADM OV-2 SV-1 a OV-5 SV-1 b OV-3 Others SV-4 Others © 2005 The MITRE Corporation. All rights reserved.

30 Pillar 4 Top Level Do. DAF v 2. 0 Data Model WHERE WHEN HOW NODE EVENT FUNCTION WHAT WHY RULE PRODUCT WHO RESOURCE © 2005 The MITRE Corporation. All rights reserved.

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

32 Separation into Three Do. DAF “Views” WHAT PRODUCT HOW WHERE FUNCTION NODE WHO WHEN RESOURCE WHY EVENT RULE Op Activity at Op Node by Op Resource Op Activity by Op Resource Op Node Op Resource at Op Node groups generates Op Activity ntr o s de Op Product ls clu co In es m u ns s ce Op Resource co s om c ac u od p es ish l pr p ou gr Operational View Event Rule Op Activity at Op Node System Views © 2005 The MITRE Corporation. All rights reserved.

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

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

35 NODE Representations n NODE is a grouping (collection of) RESOURCES performing FUNCTIONS Op Node Prod Operational Activity n NODES encapsulates these RESOURCES and FUNCTIONS NODE RESOURCE A FUNCTION F FUNCTION G FUNCTION B RESOURCE B FUNCTION C FUNCTION D FUNCTION K © 2005 The MITRE Corporation. All rights reserved.

36 Pillar 4 Data Centric Do. DAF Top Level OV Architecture Data Model Operational View OV-2 OV-5 Op Node Op Activity OV-7 Op Product Op Node Prod Operationa l Activity Prod Op Resource OV-4 Op Structures OV-4 Operational Exchange Need Line OV-3 © 2005 The MITRE Corporation. All rights reserved.

37 Pillar 4 Data Centric Do. DAF Top Level SV Architecture Data Model System View Performer Architecture Asset Architecture SV-5 a SV-1 a SV-4 a Perf Node Perf Activity Perf Node Info Performer Activity Org SV-11 a SV-7 a Asset Node Asset Function Asset Node Data /Mat Performer (Role) SV-3 a SV-5 b Info SV-1 b SV-4 b SV-11 b SV-5 c Data Asset Function Data Asset (System) SV-7 b SV-3 b Network Performer Exchange SV-6 a Performer Need Line Asset Exchange Asset Interface SV-6 b © 2005 The MITRE Corporation. All rights reserved.

38 Pillar 4 Top Level Do. DAF v 2. 0 Data Model © 2005 The MITRE Corporation. All rights reserved.

39 Pillar 4 Top Level Do. DAF v 2. 0 Data Model WHERE NODE WHEN HOW EVENT FUNCTION WHY WHAT RULE PRODUCT WHO RESOURCE © 2005 The MITRE Corporation. All rights reserved.

40 Do. D Architecture Survey Recommendations – 1/2 n 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 n Training ideas suggested - apprentices n Required that architectures be developed by a DOD certified architect as part of Do. D approval process n “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 n DOTLMPF analysis methodologies & techniques lacking n Continue evolving DARS interoperability specification and continue certifying COTS's tools based on the spec © 2005 The MITRE Corporation. All rights reserved.

41 Do. D Architecture Survey Recommendations – 2/2 n Increase collaborative efforts on architecture products (Arch Federation effort) n 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 n Tool interoperability…tools that work well to adopt directives to mandate Do. DAF and DAR n Do. D “version” of JP 1 -02 Acronyms and Abbreviations (or an extension, update? ) n Promote architecture success stories n Address Do. DAF weakness issues n Increase awareness of value and need for Executable Architectures in the full spectrum of DOTLMPF analysis and Do. DAF v 2. 0 overlays n 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 Do. DAF products that are being least produced (SV-10 a, SV-10 b), maybe reduce or even add new products? ? © 2005 The MITRE Corporation. All rights reserved.