Presentation is loading. Please wait.

Presentation is loading. Please wait.

DoDAF Delivering Architectures to the World

Similar presentations

Presentation on theme: "DoDAF Delivering Architectures to the World"— Presentation transcript:

1 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)

2 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

3 Key Policies Requiring DoDAF

4 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)

5 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

6 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

7 DoDAF 2.0 Viewpoints Capability Viewpoint Operational Viewpoint
VERSION 15 4/15/ :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

8 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.

9 DoDAF Metamodel 9

10 DoDAF Conceptual Model

11 “Fit for Purpose” Architecture Descriptions

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 Federated Architectures The Connection

21 What the Operator Sees Today

22 What the Operator Expects to See

23 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

24 DoD EA Federation Strategy
Available on DARS Website:

25 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

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

27 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 D Joint Staff J-6 Interoperability Requirements Certification Process DoDI 4630.8 C CJCSM 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)

28 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.

29 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

30 IT Standards Governance Organization Membership
Technical Working Groups

31 DoD GIG Technical Guidance (GTG)
Walt Okon

32 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

33 Architects Career Path Architects Competencies
Architects Certifications

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!

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

36 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

37 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 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

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

39 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…

40 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.

41 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.

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

43 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

44 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

Download ppt "DoDAF Delivering Architectures to the World"

Similar presentations

Ads by Google