1. Tim Hunnicutt Senior Associate Booz Allen Hamilton Session Title: Beyond a Product View of Architecture

3. The primary usage of architecture… Wallpaper

4. The foundation of any architecture is integrated information… Before we can create presentation and visualizations, we have to go through a process of gathering and relating information about the enterprise. Using some sort of modeling notation and tool.

6. BPMN Relationship to DoDAF The OV-6c portrays a relative order to Operational Activity execution Each Operational Activity has a trigger (start) Each Operational Activity has a conclusion (end) The process flows within each diagram are categorized by the Actor responsible for the activity/event These “swimlanes” also map to the OV-2 roles All process models use a common modeling notation (BPMN) Data Objects map to OV-3 Information Exchanges Gateways reflect OV-6a Business Rules

7. The product-centric view in DoDAF is a compromise between Zachman and most modeling notions

8. DoDAF 1.5 seems to be only a partial solution wrt to Zachman… DoDAF Products Mapped to the Zachman Framework Presentation and visualization can help fill in the gaps. Integrated Dictionary Activity Model (List) Operational Node Connectivity Description Command Relationships Chart Operational Event Trace Logical Data Model Activity Model Information Exchange Matrix Physical Data Model System Functionality Description System Interface Description (Detailed) Operational Activity to System Function Matrix System Interface Description (High-Level) System Interface Description (Detailed) System COMMS Description System Interface Description (Detailed) Activity Model Operational Event Trace/System Event Trace An Aspect Of Multiple Products DoD Architecture Framework Products Operational View System View Technical View* *Rules Not Explicit in Zachman

9. During this session we’re going to take several looks at how process modeling relates to this… Phase 4 Integrate (Weeks 13-15): The example process model had 304 “steps”, plus multiple swimlanes and dozens of data objects. We’re going to relate this to both DoDAF and presentation/visualization.

10. The DoDAF is moving to a “Fit-for-Purpose” concept… The intent is to go beyond the product-centric view to a data-centric view. This will be more flexible and address the gaps in the current framework. To understand the implications of this change we have to look “under the hood”.

11. Using Presentation and Visualization techniques INCREASES the need for well-formed architecture data… Before we can create presentation and visualizations, we have to really understand the information that is the core of architecture.

12. The building blocks of architecture align to the primitives in the Zachman framework. Policy Standards Information Exchanges System Data Exchanges Data Operational Activities Systems Business Processes Business Rules System Functions Operational Roles

13. The heart of the DoDAF (or any framework) is the relationships between these primitive concepts…

14. Policy is a documented plan of action to guide decisions and achieve rational outcomes. It guides the process of making important organizational decisions, such as programs or spending priorities, and choosing among them on the basis of the impact they will have. Policy

15. Department of Defense ● Human Resources Management Civilian Human Resources Management ● Military Health System ● Military and Other Human Resources Management Operational Activities ACART DITPR Reference Models Operational Activities populate the BEA Operational Activities organize RMs Operational Activities are fed to DITPR for mapping Operational Activities are fed to ACART for mapping BEA Operational activities describe the capabilities that are normally conducted in the course of achieving a mission or a business goal. They represent a hierarchical decomposition of business activities and are discovered through reference analysis and SME interviews.

16. The team created an Operational Activity, Node Tree (OV-5) by abstracting the detailed process steps… Phase 5 Validate & Refine (Weeks 16-18):

17. Reference Models DoD Net-Centric Data Strategy BEA Information Exchanges Information Exchanges identify who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur. Information exchanges express the relationship across operational activities, operational nodes, and information flow. Information Exchanges populate the BEA Information Exchanges are mapped in RMs Information Exchanges identify authorized and anticipated users for the NCDS Information Exchanges are mapped to Core HR Information Standards Core Human Resources Information Standards

18. Operational roles define who is responsible for what activities within an organization, what information is exchanged between roles, and how responsibilities within an organization shift over time. Organizational roles can also define stakeholder relationships. BEA Reference Models DoD Net-Centric Data Strategy Operational Roles identify net-centric service providers Operational Roles are mapped in RMs Operational Roles populate the BEA Operational Roles

19. * Source: MODAF Version 1.1 Data is used to document the business information requirements and structural business process rules of the architecture. It describes the information that is associated with the information exchanges of the architecture and that are required to support a mission or business goals. It includes data elements, their attributes, their relationships and data-specific business rules. BEA Reference Models DoD Net-Centric Data Strategy Core Human Resources Information Standards ACART Data populates the BEA Data organizes Data RMs Data is fed to ACART for mapping Data is built to support the NC Data Strategy Data is the core of the HR Information Standards Data

21. BEA Reference Models Business Processes populate the BEA Business Processes are mapped in RMs Business Processes Business processes describe a time-ordered examination of the information exchanges that occur between operational roles. They help define the role interactions and capture end-to-end business processes.

23. Business Rules specify operational or business rules that are constraints on the way that business is done in the enterprise. At a top level, rules will at least embody the concepts of operations and will provide guidelines for the development and definition of more detailed rules and behavioral definitions that will occur later in the architecture definition process. BEA Business Rules Core Human Resources Information Standards Business Rules populate the BEA Business Rules constrain HR Information Standards ACART Business Rules are fed to ACART for mapping

24. System Data Exchanges BEA System Data Exchanges populate the BEA System Data Exchanges specify the characteristics of the system data exchanged between systems. System data exchanges focus on the specific aspects of the system data flow and the system data content.

25. System functions are actions performed by systems to support the operational activities required by a mission or business goal. System functions BEA System Functions populate the BEA Reference Models System Functions populate RMs for system mapping ACART System Functions are fed to ACART for mapping DITPR System Functions are fed to DITPR for mapping System Functions

26. Systems BEA ACART DITPR Systems populate the BEA Systems are fed to ACART for mapping Systems are fed to DITPR for mapping Systems support organizations and operational roles by automating the information exchanges between operational activities that support a mission or capability.

28. Well-formed architecture data, residing in a capable repository presents infinite opportunities for business use… Working with the DoDAF community, we are trying to create some best-practices to help the architecture and business communities understand each other.

29. An architect’s two primary jobs are communication and mediation… The EA MUST be understandable to ALL the stakeholders! But not ALL of the EA has to be understandable to ALL stakeholders! Graphics Reference Models Low detail Highly structured models Physical models Highly Detailed Graphics Logical Models Moderate detail

33. Graphical representations must tie back to the architecture they introduce… Major operational concepts called out. Highest level actors identified. Strategic goals integrated into the graphic.

34. Our example Operational Concept Graphic abstracts very detailed process model data… Phase 5 Validate & Refine (Weeks 16-18):

35. Presentation Technique: Reference Models Reference models provide linkages from operational activities to key architectural concepts, both within and outside of the enterprise Presenting the architecture linkages in a desk reference, versus a set of diagrams and reports, provides a means for quickly retrieving multiple pieces of information BRM driven by underlying OV-5 What’s the role of taxonomy in enterprise architecture?

38. Conclusion - Architecting and Engineering ─ Two Sides of the Same Problem* Architecture Specification Engineerible Requirements collective vision, goals, constraints, and other needs of the stakeholders representations of economically producible components that can be assembled to construct the functional whole Analysis of Function Synthesis of Form Engineering Architecting Critical point *Walt Okon, DoD Architecture Training Town Hall Meeting Dec 12, 2007 If architecture and engineering are not the same thing, then the approaches might be different. Iteratively decompose and separate a primarily functional representation of a whole Iteratively compose separate elements to form a coherent whole

42. Though originally directed to only use BPMN, as complexity increased, stakeholders found value in using other EA products too Achieved consensus by adapting to fit stakeholder needs Individual Process Models 15 process models consisting of 304 processes and 35 data objects High Level Process Model 19 processes outlining the entire continuum and the simultaneous and iterative nature of many processes Node Tree (OV-5) 80 operational activities providing an overview of all 15 process models High Level Operational Concept Graphic (OV-1) Executive-level diagram to socialize new concepts Integrated Process Model 1 process model including all processes, data objects, swim lanes, and gateways from the 15 sub-process models Integrated Dictionary (AV-2) Definitions for all processes, events, gateways, data objects, and swim lanes