DoDAF Delivering Architectures to the World DoDAF Delivering Architectures to the World Presentation to GTRA Architecture GOV Symposium 07 December 2008 Walt Okon Senior Architect Engineer for Standards Architecture and Interoperability Directorate Deputy Assistant Secretary of Defense for Information Management, Integration, and Technology & DoD Deputy Chief Information Officer (703) 607- 0502 . walt.okon@osd.mil

Strategy and Direction Discussions: DoDAF Version 2.0 Architecture Training - Architects Competencies DoDAF Metamodel “Fit for Purpose” Architecture Defense-Industry Challenge – DoDAF + MODAF = UPDM DoD IT Standards Registry (DISR) IC & DoD IT Standards Integration DoD GIG Technical Guidance (GTG) Architects Career Path, Competencies & Certifications DoD Information Sharing Environment

Key Policies Requiring DoDAF Joint Staff CJCSI 3170.01F, 1 MAY 2007, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” CJCSM 3170.01C, 1 MAY 2007, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” CJCSI 6212.01D, 8 MAR 2006, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS” Direct support for the Warfighter

DoDAF Evolution To Support “Fit For Purpose” Architecture CADM Separate Baseline For DoDAF 1.5 Removed Essential & Supporting Designations Expanded audience to all of DoD (Published in 2003) DoDAF 1.5 Addresses Net-Centricity Volume III is CADM & Architecture Data Strategy Addresses Architecture Federation Baseline for DoDAF 2.0 Shifted away from DoDAF mandating a set of products (Published in 2007) DoDAF 2.0 Cover Enterprise and Program Architecture Emphasize Data versus Products Tailored Presentation AV-1 to capture federation metadata Quality Support to Decision Processes FEA & Allied/Coalition Support Journal - Errata & Interim Releases DoDAF 2.0 (To Be Published) (Late 2008)

Focused on DoD Decisions Cost View Capability View SE View Acquisition etc. Architecture Views “Fit for Purpose” DoD Core Decision Processes PPBE/PfM JCIDS DOTLMPF Acquisition Systems Eng M C E P Federated Architectures E – Enterprise M – Mission Area C – DoD Component P - Program Architecture IT Technology Governance Link Technology to Objectives Institutionalize IT Best Practices Protect digital assets

DoDAF V2.0 DoDAF Metamodel (DM2) Fit For Purpose Presentation Dashboards Graphical Depictions Reference Models Fusion Products Composite DoDAF V2.0 DoDAF V1.5 Standards View Operational Rest of OVs All TVs All All AVs Systems View All “Systems” Versions of SV Products Data & Information View OV-7 Net-Centric SV-11 All “Service” Versions of SV Products DoDAF Metamodel (DM2) DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions. In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.). Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience. DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues. BUILD ONE: The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views. BUILD TWO: The new Systems view better accommodates our legacy system descriptions. The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services. The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships. The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective. BUILD THREE: The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both. Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View. There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker. Capability View Project System Engineering New Updated Moved

DoDAF 2.0 Viewpoints Capability Viewpoint Operational Viewpoint VERSION 15 4/15/2017 20:47 DoDAF 2.0 Viewpoints Overarching aspects of architecture context that relate to all views All Viewpoint Articulate the data relationships and alignment structures in the architecture content Data and Information Viewpoint Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts Standards Viewpoint Systems Viewpoint Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions Operational Viewpoint Articulate operational scenarios, processes, activities & requirements Capability Viewpoint Articulate the capability requirement, delivery timing, and deployed capability 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. Project Viewpoint CT 7 7

Vision Statement To enable the development of architectures that are meaningful, useful, and relevant to the DoD Requirements, Planning, Budgeting, Systems Engineering, and Acquisition decision processes.

DoDAF Metamodel 9

DoDAF Conceptual Model 10

“Fit for Purpose” Architecture Descriptions

Notional DoDAF v2.0 Development Schedule (cont) 2nd QTR 08 3rd QTR 08 QTR 08 4th Feb Mar Apr May Jun Jul Aug Sep Oct Nov EA Summit 23 Jan 08 EA Conf 14-19 Apr Approval DoD CIO Plenary 22 July Vwendor Tool Session Develop Writing Technical Editing Cood Plenary 1 Apr PfM WS PPBE WS Feb 08 Post to DARS Validation SPIRAL II 4 Apr 08 SPIRAL III 27 Jun 08 SPIRAL IV 12 Sep 08 Phase I Phase II Phase III

DODAF Version 2.0 in Coordination Core Management Group - 10 December 2008 Discuss DoDAF Version 2 Spiral 4 Draft. Comment and adjudication Next Step: OSD NII Informal coordination EA Summit – Services, Agencies, and COCOMs DoD Executive Coordination Committee

Metadata Registration Service Federation Client Services Menu DARS Federated Catalog DARS Federation Web Services Register Provider View Provider Update Provider Register Metadata Search Holdings SOAP DDMS + Metadata (XML) AV-1 metadata captured and extracted by repository/tool environment Federation Web services Federation Client Federation Repository Repository/Tool Environment

DoD Architecture Federation DoD Enterprise Architecture Tools Ref Models Tech Stds Arch Guidance Laws, Regs, and Policy DITPR DoD EA RM DISR DODAF Laws Regs Policy Force Application TAMD Building Partnerships Joint Capability Areas Command & Control GLOBAL C2 JC2 Net-centric COMMS & Transport IEA IA Architecture Battlespace Awareness BEA Protection Logistics MS&SM JDDA Force Support RP&ILM HRM HRM Architecture Corporate Management & Support WSLM FM Other DISA DLA NSA NRO NGA DIA Dept of Army Dept of Navy Dept of Air Force Army Architecture DON Architecture Air Force Architecture Solution Architectures

Defense-Industry Challenge: Synchronization of DoDAF-UPDM Lifecycles Produces Develops Generic Modeling & Engineering Standards 3. Vendors Produce Product Versions Defense Domain Tools “Just-In-Time” Governments Produce Baselines Develop, Evolve & Harmonize Defense Enterprise Architecture Frameworks For Acquisition RFC Leverages Vendors Standards- Based Tools & Government Frameworks 16

UPDM – Unified Profile for DoDAF/MODAF Adaptive Artisan Software ASMG BAE Systems DoD embeddedPlus Generic Lockheed Martin Co Mitre MOD No Magic Raytheon Rolls Royce Sparx Systems VisumPoint UPDM RFC Group 17

UPDM in General The UPDM Group was setup to: UPDM is an OMG initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF) The UPDM Group was setup to: Significantly enhance the quality, productivity, and effectiveness of architecture modeling Promote architecture model reuse and maintainability Improve tool interoperability and communications between stakeholders Reduce training impacts due to different tool implementations and semantics Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling DNDAF NAF UPDM DoDAF 1.5 MODAF 1.2 UPDM is an Object Management Group (OMG) initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF). The modeling standard is called the Unified Profile for DoDAF and MODAF (UPDM). The UPDM Group was setup to: Significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling Promote architecture model reuse and maintainability Improve tool interoperability and communications between stakeholders Reduce training impacts due to different tool implementations and semantics Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling The UPDM Group consists of fourteen companies distributed around the world. You can see a list of these companies in the member section on this web site. 18

Need for UPDM Motivation Significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling, promote architecture model reuse and maintainability, improve tool interoperability and communications between stakeholders, and reduce training impacts due to different tool implementations and semantics. Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling. UPDM fully supported by DoD, MOD, IDEAS Statement and slides available on OMG website

Federated Architectures The Connection

What the Operator Sees Today

What the Operator Expects to See

A Federation of Data Producers Strategy Reporting (OMB, GAO, etc) DARS DoD EA Reference Models CADM DoDAF NCOW RM COI x MILDEP COCOM AGENCY COI y DATA REQTS. COI = Community of Interest CADM = Core Architecture Data Model DoDAF = DoD Architecture Framework NCOW RM – Net-Centric Operations & Warfare Reference Model UPDM = UML Profile DoDAF & MODAF DoD Decision Processes

DoD EA Federation Strategy Available on DARS Website: https://dars1.army.mil/IER/index.jsp

DoD EA Federation Pilot Use BTA/USTRANSCOM/Marine Corps: Federate the BEA with JDDA and Marine Corps Logistic architectures and register in DARS to gain visibility into “end to end” logistics process Army: Create a “knowledge base” through architecture federation for Army communities. Test tools and concepts through federation, i.e. social networking (ontology development, semantic indexing,) architecture data analysis, UPDM applicability Air Force: Establish interface and search capability between DARS and AFARS. Demonstrate search capability Navy: Implement and use procedures outlined in the GIG Enterprise Architecture Federation Strategy and DARS CONOPS to create a repeatable federation process Joint Staff/J6I: Identify interface points and alignment between Mission Area-level architectures to obtain enable a horizontal view across mission areas and drill down to Program level. DARS: Develop registration template for AV-1 and DDMS metadata

DoD IT Standards Registry (DISR) IC/DoD IT Standards Registry

IT and NSS Interoperability and Supportability Policy and Process Overview DoD Sponsored Policy JCIDS Documents (ICD, CDD, CPD) ACAT I - III & Special Interest J6 Interoperability Requirements Certification of All JCIDS Docs (JCPAT-E Tool) ITS & NSS Predecessor Doc. System Profile Requirement - IT Standards Profile (DISRonline) - IIC Profile (LISI) Maintain OASD(NII) JCIDS/ISP Assessment Capability (JCPAT-E Tool) Maintain IT Standards and Profiles (DISRonline) Certify Standards Conformance ITS and NSS Interoperability Requirements Certification Assessments of NR-KPP in JCIDS Docs KM/DS Joint Staff J-8 CJCSI 6212.01D Joint Staff J-6 Interoperability Requirements Certification Process DoDI 4630.8 3170.01C CJCSM 3170.01 DoDD 5000.1 JROC FCB JCPAT-E ITS & NSS Registration DISR Online LISI InspeQtor J6 Interoperability Requirements Certification = • UAM / JCPAT- E System Registration Technical View (CDD & CPD) Interoperability & Interconnectivity Profile (CDD & CPD) J6I Stage I, II & III Assessments JCPAT JCPAT Joint Staff J-6 OASD(NII)

DISR and DISRonline Architecture View Objectives: Champion DoD’s Re-Engagement of the IT Standards Communities Online IT standards Registry Tri-Annual Update of IT Standards Registry Tied to JCIDS IT Standards Conformance and Compliance Process Intelligence Community Cross Coordination (ICSR) Improved DoD Visibility and Participation in IT Standards Development Organizations Develop and Register PM Standards Profiles (TV) Standing IT Standards Working Groups Aligned to GIG Portfolio Management DoD IT Standards Registry (DISRonline) Lifecycle Tagged: Emerging and Retired Standards Profile Assistance Software Organization-Unique Bins - - - - - - - - - - Information / Guidance (I/G) Informational Standards Best Practices Procedures Policies Manuals Handbooks Other IT Documents Change Request Tool Software PM System IT Standards Profiles TVs * Governance and General Information Area Policy FAQs CM Procedures User Guides Links SOP POCs GIG Mission Area Management Voting Tool Software Collaboration Tool Software * May Contain Standards from Lifecycle Categories other than Mandated DISR Mandated Standards Mandated “Net-Centric” & Mandated Sunset “Interoperability” Standards DISR Profile Registry Area Key Interface Profiles * (KIPs) Prescribed Technology Profiles * (IPv6, PKI etc.) Future Enhancements THIS SLIDE IS MORE OR LESS A NOTIONAL MODEL MEANT TO GIVE YOU IDEA OF BOTH THE FUNCTIONAL CAPABILITIES AND THE MANDATED CORE AND PROFILE REGISTRY AREAS WITHIN DISR. THE AREAS CODED IN BLUE PROVIDE THE MANDATED STANDARDS FROM WHICH PRESCRIBED STANDARDS PROFILES ARE BUILT, SUCH AS TECHNOLOGY PROFILES LIKE IPV6, KEY INTERFACE REFERENCE IMPLEMENTATIONS, AND INDIVIDUAL PM PROFILES MAKING USE OR TAKING ADVANTAGE OF THE OTHER BLUE AREAS. THE LEFT AND RIGHT WINGS IN THIS MODEL IDENTIFY THE OTHER CAPABILITIES OF DISR AND INFORMATION LINKS SUCH AS THE CHANGE REQUEST TOOL, THE VOTING AND COLLABORATION TOOL, AND STATIC DOCUMENTS SUCH AS THE SOP, USER GUIDE ETC. UNDER OBJECTIVES, YOU SEE SOME OF THE POINTS I MENTIONED BEFORE BUT I’D ALSO LIKE TO POINT OUT THAT WE RECENTLY HAVE PLACED A GREATER EMPHASIS ON COORDINATING I-T AND INTEL STANDARDS WHERE THEY APPLY TO BOTH COMMUNITIES. IN FACT, WE ARE IN THE PROCESS OF SUPPORTING THE IC CIO ON THE STAND UP OF A DISR LIKE STANDARDS TOOL TO BOTH SUPPORT THEIR UNIQUE INTEL STANDARDS REQUIREMENTS AND THAT LIKE IT STANDARDS ARE CONSIDERED. I WOULD ALSO NOTE THAT THE MANDATED SET OF STANDARDS STILL NEEDS TO ALLOW FOR A CERTAIN LEVEL OF LEGACY STANDARDS TO EXIST WITHIN THE CORE ALBEIT THEY MAY BE TAGGED AS A SUNSET STANDARD THUS SIGNALING TO OUR WORKING GROUPS THE NEED TO KEEP AN EYE ON EMERGING CANDIDATE STANDARDS.

Lifecycle of a Standard Emerging Upgradeability Should be a Concern May be Implemented but Not in Lieu of Mandated Standard Expected to be Mandated within Three Years Mandated Essential for Interoperability and Net-Centric Services in DoD Minimum Set of Essential Standards for the Acquisition of All DoD Systems that Produce, Use, or Exchange Info, and, When Implemented, Facilitates the Flow of Info in Support of Warfighter Sunset Tag Identifies an Event and Date to Retire a Standard Inactive / Retired New Standards / Technology Now Available and Implemented Require Waiver and Migration Plan Remain in the Registry

IT Standards Governance Organization Membership Technical Working Groups

DoD GIG Technical Guidance (GTG) Walt Okon

DoD Technical Guidance Concept Query & Retrieve Identified Interoperability Standard, Specifications, And Interfaces Capability Development Areas Joint Capability Areas Standards Specifications Mission Area Portfolios Community Of Interest GIG Governance Processes Structured and Unstructured Sources for Standards and (Notional) DARS . . . DKO CADM 4630 80XX XML Metadata Registry SFIS Taxonomy Detailed Standards & Information DISR NCID Technical Direction Query Technical Direction Query Capability GIG Technical Guidance Standards & Specifications For Interoperability From the left side of the figure, the Type II Technical Direction detailed standards and specifications information are obtained from Structured and Unstructured sources such as DISR, DARS, DOL, CADM, 4630, etc. which provide the necessary content and references contributes to the Type II Technical Direction. From the right side of the figure, the identified interoperability standards and specifications that are applicable to the capability development area contribute to the Type II Technical Direction. These interoperability standards and specifications will have to be identified by system engineers and functional experts for each. As indicated by the green arrows in the figure, the “assembling” of the set of interoperability standards and specifications for the capability portfolio area, JCA, COI, and GIG Governance Processes that a developing capability touches becomes the Type II Technical Direction (for that developing capability). The mapping of these comprise the targeted Type II Technical Direction for the user. A portal for the delivery of Type II Technical Direction will allow a developer to determine the minimum interoperability standards and specifications. By querying on the capability portfolio area/JCA/COI that are drawn on for the capability to be developed, the portal can “assemble” the Type II Technical Direction. For example, A team building a Spend Analysis Capability under the acquisition portfolio needs to implement the following functions: 1) provide financial information to users on the GIG 2) publish the financial reporting service to the GIG Using the Type II portal, the team can query for the capability portfolio/JCA/GIG Governance process/COI utilized. Based on the identified interoperability standards and specifications within the Business Mission Area portfolio to exchange financial information on the GIG, the portal (portlet, service) retrieves the detailed information from the standards source. Also, within the EIEMA Portfolio, the portal (portlet, can find the publication standards for the Enterprise Service Discovery Service. XML Schemas/ Components

Architects Career Path Architects Competencies Architects Certifications

IMPROVING DOD’S ARCHITECTURE Guidance DoDAF v2.0 Federated Architecture Strategy Tools DoD Architecture Registry System (DARS) DoD IT Standards Registry (DISR) Type II – GIG Technical Direction Education and Training DoD Architecture Training Effort All this is nothing without Certified Architects!

ARCHITECTURE TRAINING Expanded need for architectures and their significance in achieving defense of our nation results in the need for qualified architects Therefore, we are confronted with questions: Is there a pool of qualified architects? What are the competencies of an architect? Is there a core body of knowledge? What education and training courses exist? DoD– IT Architects Career Path–Architects Series

RECOMMENDED WAY AHEAD Deliver an architect career plan Establish architecture specialties in Office of Personnel Management (OPM) Formalize a competency framework Implement Certificates & Certification across architecture specialties Work with academic and educational institutions to enhance their curricula

ACCOMPLISHMENTS WHITE PAPER - Phase I: A Competency Framework Defines a path for a quality architecture workforce Provides collected data on the competencies of an architect https://www.us.army.mil/suite/doc/10757012 Architecture Education and Training DKO Site OPM Job Family Standard Review Clinger-Cohen Core Competency Review for Architecture Delivered two Architecture Training Tutorials at 2008 EA Conference

Chief Architect, DoD Information Sharing Sharing Environment Walt Okon Chief Architect, DoD Information Sharing Architecture & Interoperability Directorate Office of the DoD CIO/ASD NII

DoD is part of this complex, extended information sharing enterprise… Complexities of Information Sharing Northeast Power Blackout Counter Terrorism Failed States (Haiti) Terrorist Actions Natural Disasters Warfighter Operations Coalition Humanitarian Pandemic Flu DoD is part of this complex, extended information sharing enterprise…

DoD Information Sharing Environment Description: – Provide a DoD Information Sharing architecture and standards capability which will support cross-community, institutional approach to the sharing of information within DoD and can apply across Federal Departments, state, and local governments – Provide architecture and engineering guidance for DoD Information Sharing Executive and DoD Information Sharing – Provide PM-ISE DoD’s Shared Space architecture and standard guidance to enable cross-community sharing for identifying, planning, installing, and operating capabilities that will become the ISE.

DoD Information Sharing Environment FY08 Key Taskings: – PM-ISE Chief Architect Roundtable and the CTISS Committee – Design and deliver a CTISS Federated Standards Registry pilot – Develop a DoD ISE Shared Space use case and concept capabilities with Net-Centric direction – Partner with other ISE architects in the Federal Departments – Partnership with DISA on analysis and engineering.

DoD Enterprise Architecture Conference 2009 Bring It All Together DoD Enterprise Architecture Conference 2009

DoD Enterprise Architecture Conference 2009 All DoD Architecture Professionals Only official Architecture Conference Enterprise Architecture & Standards Deliver Interoperability 1 – 5 June 2009; DoD Enterprise Architecture Conference 2009 in St Louis, MO Deliverables http://www.afei.org/brochure/9a05/index.cfm

Chief Architect, DoD Information Sharing Questions/Wrap-Up Walt Okon Chief Architect, DoD Information Sharing Enterprise Architecture & Standards Directorate Office of the DoD CIO/ASD NII 07 December 2008 walt.okon@osd.mil 703-607-0502