DoD Enterprise Architecture & Standards The Future of Architecture 16 September 2009 Walt Okon Senior Architect Engineer Senior Architect Engineer for Information Sharing Enterprise Architecture and Standards Directorate DoD Chief Information Officer (703) 607- 0502 . walt.okon@osd.mil

DoD Agenda for OMG 0900 - 0915 Future of Architecture; Vision, Mission, Deliver 0916 – 0945 DoD Organization, Governance, and Process 0945 – 1010 Refreshment Break 1010 – 1030 DoD IT Standards Program (DISR) 1030 – 1050 DoDAF Version 2.0 1050 – 1110 DoD Information Enterprise Architecture v1.1 1110 – 1120 EA Federation 1120 – 1130 Information Sharing Segment Architecture 1130 – 1140 Break 1140 – 1155 DoD Architecture Education & Training 1155 – 1210 DoD Architecture Exchange – UPDM V2.0

UPDM – Unified Profile for DoDAF/MODAF Unalienable Rights: Life, Liberty and pursuit of Happiness Defense Architecture Framework 3

DoD Architecture Federation Solution Architectures DoD Enterprise Architecture Tech Stds DISR Arch Guidance DoDAF Ref Models DoD EA RM Laws, Regs, and Policy Laws Regs Policy Tools DITPR DARS Force Application Building Partnerships Command & Control Protection Logistics Force Support Corporate Management & Support Net-centric Battlespace Awareness Joint Capability Areas Information Enterprise Architecture Dept of Army Dept of Navy Army Architecture DON Air Force SOCOM DISA DLA NSA NRO NGA DIA Other Dept of Air Force 5 5

DoDAF V2.0 Viewpoints That Fit-the-Purpose Renamed New New New Overarching aspects of architecture context that relate to all models 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 New In DODAF 2.0 we have described an expanded number of viewpoints (categories of models and views expressing differing aspects of a common architecture need) to include those shown on the slide. Some of the viewpoints were introduced in earlier versions of DoDAF, others, such as Project and Capability are new to DoDAF 2.0. An architecture viewpoint can be displayed in a number of formats, such as dashboards, fusion, textual, composite, or graphs, which represents data and the architecture description which represents an architecture. In DoDAF 2.0, the ability is provided to create an architectural description which can be expressed in many of the same formats normally used for briefing, analysis, and decision-making. The next few slides present a view of data from an architecture developed for the US Air Force at Arnold Engineering Development Center in Tennessee. This is the Air Force Center for R&D, testing and Analysis of aircraft, engines, and other components. Both Charles and I are using these views today with the permission of the Air Force. Architecture viewpoints are composed of data that has been organized to facilitate understanding. 6 6

DoDAF Version 2.0 Metamodel 7

“Fit for Purpose” DoDAF Architecture Descriptions

DoDAF V 2.0 Delivery DoDAF V2.0 is available at: https://www.us.army.mil/suite/page/454707 http://www.defenselink.mil/ http://www.defenselink.mil/cio-nii/docs/DoDAF%20V2%20-%20Volume%201.pdf It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience. If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts. There are six steps is the DoDAF methodology: 1-Determine the intended use of the architecture 2- Determine the scope of the architecture 3- Determine data required to support architecture development 4- Collect, organize, correlate and store data 5- Conduct analysis in support of architecture objectives 6- Document results Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed.

http://www.defenselink.mil/cio-nii/sites/diea/ 10 10

Architecture Exchange - Why Motivation US DoD and UK MOD interested in leveraging commercial standards for their Military Architecture Framework Military Architecture Framework Tool Interoperability Key Goal for DoD, MOD, NATO Formal MetaModel basis for the Military Architecture Framework Critical to Interoperability Objectives Proliferation of Military Architectural frameworks DoDAF, MODAF, DNDAF, NAF, AGATE, ADOAF, MDAF, etc.

UPDM – Unified Profile for DoDAF/MODAF Walt Okon Matthew Hause UPDM RFC Group Adaptive Artisan Software ASMG BAE Systems DoD DND embeddedPlus Generic IBM Thales Lockheed Martin Co Mitre L3 Comms MOD NoMagic Raytheon Rolls Royce Sparx Systems VisumPoint Selex 12

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 13

Architecture Models + Data = Architectural Description Operational Model Example Things Individuals Types or classes of individuals or things The framework enables architecture content to be built that is “Fit for Purpose”, defined and described in Volume 1 as architecture, which is consistent with specific project or mission objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or use of architecture at each level will be different in content, structure, and level of detail. Pulling everything together that we know about an architecture—the viewpoints, requirements, and expected outcomes, we have an architectural description. In order to ensure that architectural descriptions meet program and mission objectives, the approach to architecture development must be tailored to address a specific, well-articulated, and understood purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, is undertaken, completed, and supportive of specific decisions or objectives. Architectural description: A collection of products to document an architecture. An architectural description generally contains one or more viewpoints to express the business, service, system and other elements of the overall project or program. Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Architecture Data + Metadata Architecture Models Architectural Description Fit-for-Purpose (FFP) Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs. 14 14

DoDAF V2.0 Focus Results: Better ANALYSIS and Decisions. Focus: architecture DATA, not Products DoDAF 2.0 significantly refocuses the architectural concepts that have been in play for many years. First and foremost, the focus is on DATA, not architecture products. Data is needed for good analysis and better decisions. How these decisions are made within the culture of an organization should not artificially change just because we publish a Framework. Instead, this version discusses how to collect the data needed, validate that data, organize that data, and THEN form it into models, views, and viewpoints that graphically express the data. For those that have been happy with the older ‘DoDAF products’, please be assured that they are still being supported, along with many other views. The difference is that you can choose HOW to express your data in ways that better fit both your organizational preferences, and your specific project needs. DoDAF V2.0 provides overarching architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development. 15 15

Improving DoD’s Architecture Guidance DoDAF v2.0 Federated Architecture Strategy Tools DoD Architecture Registry System (DARS) DoD IT Standards Registry (DISR) GIG Technical Guidance (GTG) Tool Education and Training DoD Architecture Training Effort All this is nothing without Certified Architects!

Architecture Training DKO Site URL - https://www.us.army.mil/suite/page/530507

DoD Architecture Education & Training DoD must identify Architect’s opportunities for Education & Training Identifies core KSAs Architects must have to be able to design, develop, and deliver DoD architectures that enable senior leader decision making and engineering design Analyze and define the types of architecture training at different levels of architecture DoD – IT Architects Career Path–Architects Series Define a certification requirement and process

White Paper: Outline Preface Introduction Purpose, Scope, and Approach Findings Recommended Way Ahead The DoD Architect Competency Framework A culmination of input gathered through research, interviews, and workshops on the standard knowledge, skills, and abilities DoD Architects should obtain at varying levels of maturity. https://www.us.army.mil/suite/doc/10757012

DOD Architect Levels Level 1 Development Level 2 Analysis Primary function is to develop architectures based on user requirements and input from subject matter experts Level 2 Analysis Primary function is to analyze architectures for the purposes of integration, interoperability, gap analysis, risk assessment, leveragability, compliance, and business decision making Level 3 Management Primary function is to lead and manage an architecture effort through its entire lifecycle, from development to execution/implementation White paper identifies the functions and associated KSAs for each level. These KSAs are independent of educational degree, working domain (contractor, civilian, military), or career title (GS level, rank, or role).

Roadmap to the Future Deliver an IT EA Education & Training Strategic Plan Deliver an architect careers plan Establish architecture specialties in Office of Personnel Management (OPM) Formalize a Architect’s Competency Framework Implement certification across architecture specialties Work with academic and educational institutions to enhance their curricula

DOD IT ENTERPRISE ARCHITECTURE TRAINING & EDUCATION Strategic Plan 2009 Draft 1.7a

DKO Site URL - https://www.us.army.mil/suite/page/530507

DoD Enterprise Architecture Conference 2010, San Antonio, TX May 10-14, 2010 DoD Enterprise Architecture Conference 2010, San Antonio, TX Save the date!