JAIWG Data Federation Sub-Working Group Planning Meeting Phase 2 Mtg #3 September 3, 2009 Use following Teleconference Numbers for Voice. Telcon for voice Phone # 877-714-4577 Pass code: 2692256 Slides on JKO Portal https://www.us.army.mil/suite/page/596533

Agenda Portal Design Requirements Phases to Development Meeting Schedule

Federation Partners Knowledge Sources Current Partners: JACAE (USJFCOM) MCAE (MCSC) CADIE (Army TRADOC/AIMD) AFMC (AF Wright-Patterson) SADIE (Navy) JFCOM Internal/JACAE Users JCCD, J892, JTF J7, J9, JTC-I, J3/4, J6 STRATCOM, CENTCOM, USFK Potential External Architecture Development Environments JIAMDO JPEO-CPD TRANSCOM J6 Knowledge Sources ADS Registry DISR JCAMS/UJTL Database C2-Pedia/Registry? Other Architecture Information Sources DARS** (OASD-NII/CIO) NARS** (Navy) MCASE** (MC) NAERG (Navy) E-ISP (OASD-NII/CIO) Joint Program Executive Office for Chemical and Biological Defense (JPEO-CBD) Syscom Architecture Development and Integration Environment (SADIE)

Website Planning The absolute basics we all need to know before starting portal development

The Process Determine the goal of the portal Identify the Standards Organize the basic structure Create the Design (look and feel) Plan and Gather Assets

Goals of Portal (Critical Customer Needs) Federation Catalog of Reusable Architecture Objects (including JCSFL) Discoverability of Federated Architecture Products Authoritative Library Sources Links to other important sources Link for access to JACAE Customized reports to support decision makers Others???

Standards We must meet current and emerging standards i.e.: PKI (NIPR)/DKO/JKO Pass Through Browser compatibility CSS Web 2.0 Technologies Accessibility

Organize USER-CENTERED DESIGN Level 0 Level 1 Level 2+ What is critical to be on the home page Level 1 Most important, frequently used information that can be accessed in 1 click Level 2+ Layers of depth in priority/customer need

Organize Organize by categories of information Flowchart out moving through the portal Do we need a News Feed/Blog/Wiki (Web 2.0)? Plan for Phases of implementation What do we need to have now? In 6 months? 1 year? Long-Term?

Design Same look and feel across pages Transition from portal should be almost seamless Consistent (Same buttons in same locations on all pages) User Friendly Visitors need to know where they are in the navigation Search Features readily available Feedback button in case errors are detected or questions

Plan and Gather Already started Need to have location to gather and CM all information for portal

Other Considerations Design Document is critical to ensure scope and purpose are clearly defined (and for reuse) Maintenance of the Portal and Content Plans for Back-Ups Contact/About Us/Leadership Pages Sizing? 1124/768 or 800/600 etc… Speed of Loading

Phase 1 November 2009

Task 1 List of Architecture Development Efforts and Associated Products Collect Information Develop User Interface/Matrix (Front-End) Requirements Back End Requirements (Web Service or Static View?)

Task 2 Catalog of Reusable Architecture Elements JFCOM Army MC Key Elements of Capability Mapping Baseline and associated mappings JTF Templates Army MC Navy (NAERG) Air Force

Deliverables September 1, 2009 Documentation CONOPS/Business Plan-Include plans for future development spirals System Requirements Documentation (Draft) Configuration Management Plan (Draft) Data Management Strategy (Draft) Action Plan to accomplish each deliverable Comprehensive List of Architecture Development Efforts and associated architecture products held in each repository Storyboard of Portal Interface for accessing Architecture Products and Catalog/Rough Working Model (Use Cases for Portal Interface)

Deliverables November 15, 2009 Automated DARS registration of AV-1’s contained in the federated repositories** Standardized interface (portal) for viewing federated data Joint Standard for sharing system information in the federated environment Data under Configuration Management Authoritative Source Traceability Data Model and XSD’s publication DM2 mapping and information exchange standard implementation commenced Web Services Use of NCES messaging and security services Pass through authentication using DKO Meet all Information Assurance Guidelines

Other Milestones Federation with: Navy Sources: SADIE/NAERG/NARS DISR ADS Registry

Takeaways All Army JFCOM/JHU-APL MC OASD-NII Architecture Projects, Products Available, Location Army JFCOM/JHU-APL ?? MC OASD-NII

Backups

Goals, Objectives, Tasks

The Goals Establish the capability to discover authoritative data in federated Joint/Service repositories in order to access, visualize, and use/reuse the data in support of the Warfighter (our original goal). Provide the necessary framework, standards and governance for a federated, joint, architecture information sharing and development environment by adhering to the principles contained in the DoD Information Sharing Strategy. Become a key contributing factor for Joint Architecture Excellence in support of development of Joint, Interoperable, Capability Solutions Leverage partnerships with mature DoD architecture development efforts in order to maximize use of existing resources.

Objectives Assist decision makers across the DoD by providing the ability to search, discover and visualize integrated, authoritative data and products from a secure, Joint/Service federated environment in support of Warfighter capability development. Provide a secure, federated Joint/Service repository of reusable architecture products and reports to enable architecture developers to improve speed of development, reduce or eliminate duplication of effort, and create more efficient, collaborative architecture development and analysis processes in support of developing Joint, interoperable solutions for the Warfighter. Provide a common infrastructure that is agile, scalable and reusable so that other architecture development efforts can easily integrate into the federation. Reduce resource requirements through use/reuse of already existing technical expertise and previously developed architecture products and services.

Capability Mapping Baseline “Periodic Table” for Operational DOTMLPF-P Analysis Policy Standards Architectures Policy Joint Capability Areas (JCAs) Systems Functions CPM Areas Standards Tier I Analysis Joint Common System Functions List (JCSFL) Technical Policy USN Accreditations Standards C2 Portfolio* JCAs USMC - Programs of Record - Systems - Sub-systems - New Capabilities USA Policy USAF Platforms/Weapons NCES/NECC Other CPMs Standards ADS & Data Models Policy Joint Staff J7 Mapping Standards Operational Activities Applications/Services Policy JTF Operational Activities / Tasks / Sub-tasks Networks/Comms UJTL SN X.X ST X.XX OP X.X.X TA X.X.X.X Standards Policy Assessments Joint Tasks PROVIDES JCA-BASED Framework: Establishes a joint lexicon, based on authoritative sources and a consolidation of mapping efforts Detailed mapping process links JCAs – UJTs-activities-system functions-systems- policy and standards. Critical to focusing analysis on total capabilities vice individual programs and systems. Can help identify the impact(s) (intentional or unintentional) on any operational, programmatic, or technical change across the entire joint enterprise. The “ripple effect.” Allows for cross-portfolio analysis Provides essential elements of capability assessments – through joint mission threads (which start with UJTs) or other avenues of analysis MAPPING TYPES: Joint Capability Areas (JCAs) to UJTL Mapping – Re-uses Joint Staff J7 Mappings To better capability portfolio management efforts, align with the prescribed DoD lexicon and taxonomy for capability development, and establish priorities for capability assessment; C2 CPM issues are aligned with Joint Capability Areas (JCAs). JCAs are the overarching organizational constructs that begin to provide a common lexicon for capability efforts. There are 9 Tier 1 JCAs, all of which have Capability Portfolio Managers (CPMs) assigned to them, including Command and Control (C2), which JFCOM has the lead for. The UJTL to Joint Capability Mapping identifies the UJTs which support a JCA. JCAs have been mapped to appropriate UJTs by the Joint Staff J7, and vetted with the FCBs as the initial step in integrating JCAs into the future UJTL as directed by the SecDef. This mapping is being re-accomplished, following the extension of the JCA Tier 3s and below in Jan 2009, and is being formally staffed with all stakeholders. For the purposes of the C2 mapping process, this mapping provides the authoritative data source to be used for Program Review and POM analysis, as well as the Optimum Capability Mix Study, and C2 Portfolio Baseline updates. UJTs to Operational Activities Mapping CJCSM 3500.04D; 1 August 2005 provides the authoritative set of Joint Task Force (JTF) activities. The UJTL to Operational activities mapping identifies the activity/tasks/sub tasks which support a UJTL, at both the Service level (via various Service Task Lists) and the JTF level. In this context, the term “Operational Activities” refers to actual operations that are normally conducted in the course of achieving a mission (Not to the operational level of warfare). Tasks and sub tasks are descriptions of clearly defined and measurable activities to be performed by organizations or individuals. The Department of Defense Architecture Framework (DoDAF) 1.5 Deskbook reference defines Operational Activities as follows: An activity is an action performed in conducting the business of an enterprise. It is a general term that does not imply a placement in a hierarchy (e.g., it could be a process or a task as defined in other documents and it could be at any level of the hierarchy of the Operational Activity Model). It is used to portray operational actions not hardware/software system functions. The operational activities represent a hierarchy and relationship mapping of UJTs–to–Joint Mission Essential Tasks (JMETLs), Service Task Lists and other subordinate activities, tasks, and subtasks. Currently, UJTs are mapped to operational activities from the CJCSM 3500.05A, September 2003, JTF HQ Master Training Guide, in the USJFCOM JTF HQ Baseline Template and Architectures. As integrated architectures continue develop in support of C2 CPM assessments, UJTs will be mapped to appropriate operational activities, tasks and sub tasks at all levels of the architecture. Moreover, the UJTs and Service Task Lists inform the Training requirements required by any changes across the capability mapping enterprise. Because CJCSM 3500.05A, JTF MTG, will not undergo further revision, the enterprise-level version of the JTF Enterprise Architecture is derived directly from the expanded UJTs, and the Service Tasks called out in the UJTL, as provided in the Joint Capability Area Management System (JCAMS) via JDEIS. Operational Activities to Operational Nodes & Billets: While JTF Operational Activities are helpful, without including the individual JTF Boards, Bureaus, Centers, and Cells (operational nodes) that perform an activity, and the human beings that will execute those activities for the operational nodes (billets), a process mapping of any mission area would be incomplete. Together, the Operational Activities and Operational Nodes form the Organizational, Personnel, and Facilities (if included or required for assessment) portions of DOTMLPF analysis. Leadership is synthesized from the ability to understand the organizational, personnel, and facilities. Operational Activities to Systems Functions Mapping Operational activities, tasks, and sub tasks can be decomposed so they can be traced to systems functions. For the purposes of C2 portfolio management, products from the development of the JC2 Integrated Architecture will map operational activities to system functions. A higher level of operational activity to system function mapping fidelity is achieved when the operational activities are broken down to the lowest level practical to identify what the system functions/systems are performing. The Activity to System Function Mapping identifies the transformation of an operational need into a purposeful action/task (i.e. System Function) performed by a system. The related System Functions implement the automated portions of the Operational Activity it is mapped to. The analysis of system functions performed across an integrated architecture requires a common point of reference to normalize the identification and description of system functionality. This enables the mapping of systems that provide similar functionality to capabilities and activities, and systems from different Services. Further mappings may associate operational nodes, operational billets, networks, and system applications depicting comprehensive threads across the architecture. The USJFCOM Joint Common System Function List (JCSFL) has provided this common point of reference for describing a common lexicon for system functions. JCSFL v1.0, which focused primarily on C4ISR functions, and a lesser set of support tasks, including Logistics and Medical, was JSAP 136’ed, and published on 30 Apr 08. Joint Common System Function List (JCSFL) Since each Service has a set of definitions for system functionality, USJFCOM J89 developed the JCSFL to provide the common point of reference, or lexicon for system functionality depicted in Joint Integrated Architectures. Using Service provided CSFLs as source data, the JCSFL fuses the Service information into a single representation of Joint Force system functionality employed across the range of Joint Force operations. System Functions to C2 Portfolio (Including Systems’) Mapping The System Function to C2 Portfolio Mapping identifies the systems that execute System functions. For C2 CPM actions, USJFCOM J89 / JSIC performed this mapping, using the most authoritative source available. This begins an excursion into the Materiel portion of DOTMLPR analysis Authoritative Sources Every node within the capability mapping baseline is linked to at least one authoritative source. This provides requirements traceability throughout joint architecture development and integration, or for joint mission thread analyses. Because authoritative sources often include JCIDS documents, Joint Pubs, or other regulatory or policy-based documentation, authoritative sources often represent the Doctrine portion of the DOTMLPF analysis and assessment. C2 Portfolio For Programs of Record (POR), the preferred authoritative source is data acquired through Program Manager interface. When available, program system functions provided using a Service CSFL will be traced through the JCSFL pedigree to the appropriate joint system function. Otherwise, the best available programmatic data available will be used to map systems directly to the JCSFL functions through analysis. In cases where a system/application is not yet a POR but clearly needs assessment in support of CPM, the best available data from various sources including manufacturer, C/S/As, and operational Subject Matter Experts (SMEs) will be fused to derive joint system functions. The C2 Portfolio attempts to bound CPM in the near term for PR/POM analysis, and a “list of lists” have emerged for PR09, POM 10, CENTCOM Best of Breed (BoB), and JTF C2 equipping core lists. The pedigree of these lists are maintained in JACAE to allow for comparative analysis and to re-use the information from previous CPM analyses and assessments. C2 Portfolio CPM Areas: Attributes / Enablers Each system in the portfolio can be decomposed to system attributes/enablers. It is within this decomposition that the portfolio manager will find addressable gaps, overlaps, and redundancies for acquisition recommendations. There are three main categories of attributes: technical, operational, and programmatic Technical Area Each system is made up of applications that support the system functions. Many of these applications will be common from one system to another, and more importantly there may be many applications in various systems that perform the same function. By mapping these applications we will be able to see these relationships clearly, identifying potential areas of management within the portfolio. Each system requires some form of data management, data integration, or normalization of data models. Some systems share the same data management process, others do not. Again, by mapping these out the portfolio manager may finds focus areas of management. Each system interfaces to networks in some fashion, and the resulting mapping will provide critical interoperability insight as to how to improve the network capabilities across the portfolio. Many systems exist in various forms designed to support activities at the platform level. These relationships need to be understood and defined during CPM assessments. As with the other CPM Area attributes, the policy and standards enacted by each element within the Technical CPM Area will reveal the heart of non-interoperability issues and integration challenges. Operational Area The operational system characteristics can be defined in terms of available testing (DT&E and OT&E) or other assessments (JSIC, MRX, etc.), various capability and fielding documents (including JCIDS), as well as other Program Management Office-generated systems documentation. Additionally, CONOPS, Functional Plans (FUNCPLANs) Operational Plans (OPLANs), or other documentation that describes the operational attributes of an capability will be used to assess whether the capability is meeting operational requirements, including the development of metrics. . Programmatic Area Perhaps the hardest area to map, programmatic attributes of each system will need to have the complete technical mapping discussed above in order to determine the areas within Service budgets that apply. OSD PA&E supports the CPMs’ needs in this area by mapping the Program Element Codes (PEC) to the JCAs. It is expected that, over time, the PEC-to-JCA mapping will become more granular so that the overarching JCA for any sub-system within a platform can be traced by the PECs. Architecture Driven Analysis of Standards and Policy The primary purpose of developing the Capability Mapping Baseline is to enable the assessment of standards and policy, down to the tactical level for bit-level implementation. By having all the elements of the baseline mapped together, it is possible to assess the affect of any element’s change across the entire DOTMLPF spectrum. Therefore, the Capability Mapping Baseline becomes the common backbone for DOTMLPF analysis, and should be used as the “periodic table” of capability through which the analysis of all joint mission threads should be “pulled” or cross-checked. Acronyms: UJTL – Universal Joint Task List AUTL – Army Universal Task List MCTL – Marine Corps Task List NTTL – Navy Tactical Task List AFTL – Air Force Task List PA&E – Program Analysis and Evaluation (Director under the Secretary of Defense) PEC – Program Element Code DOTMLPF – Doctrine, Organization, Training, Materiel, Leadership, Personnel, and Facilities CENTCOM – United States Central Command COAs – Courses of Action (AKA recommendations) Operational Standards AUTLs, MCTL, NTTL, AFTL Documentation Service Tasks Policy Operational Nodes & Billets Concepts/Plans Standards Joint Warfighter Billets Op Nodes Programmatic JCAs- to- PECs JCAs PA&E Mapping Joint Integration & Interoperability Recommendations via Detailed DOTMLPF Analysis Authoritative Sources:

Timeline Phase 1 – November 2009 Phase 2 – May 2010 (EA Conference) Matrix of Architecture Products First Phase Reusable Catalog of Joint Architecture Elements linked to Service Architecture Elements Phase 2 – May 2010 (EA Conference) Integrated (Dare I say Federated?) Architecture Products and Reports Use Cases include JAIMDO and JCAS

Phase 2 May 2010

Use Cases AV-1 AV-2 Desired Outcome: Traceability through Architecture Products developed in various environments

Timeline - Milestones Sep 09 Nov 09 May 10 Phase 2 Tasking Completed 2010 EA Conference Phase 1 Tasking Completed Documentation

Deliverables September 15, 2009 AV-1 for Use Cases for Integration (May 2010)