(U) NGA_Systems_Engineering_Plan_SEP_Rev B.pdf

UNCLASSIFIED

NGA SEP, Rev B

23 September 2021

Total Pages: 76

National Geospatial-Intelligence Agency (NGA)

SYSTEMS ENGINEERING PLAN (SEP)

Revision B

Abstract: (U) This document describes the NGA’s conduct, management, and control of the systems engineering aspects of NGA, and provides a framework for the systems engineering of NGA’s activities such as acquisition programs, projects, and studies.

Keywords: (U) Acquisition, Agile, Architecture, Configuration Management, DevOps, DevSecOps, Systems Engineering, Interface, Management, Performance, Quality, Requirements, Release, Review, Risk, SAFe, Scaled Agile Framework, Security, Service, Standards, System, Test, Transition, Verification ii

Table of Contents

1 (U) INTRODUCTION

1.1 (U) The National System for Geospatial-Intelligence (NSG)

1.2 (U) Technical Approach

1.3 (U) SEP Scope

1.4 (U) NSG Systems Engineering Activities Scope & Relationships

1.5 (U) NGA Acquisition Lifecycle

1.6 (U) De-confliction of Priorities

1.7 (U) SEP Configuration Control

2 (U) APPLICABLE DOCUMENTS

3 (U) ENGINEERING ELEMENTS AND PROCESSES

3.1 (U) Enterprise Release Management (ERM)

3.1.1 (U) Enterprise Agility

3.1.2 (U) Enterprise-Level Visibility

3.1.3 (U) Normalized Artifacts

3.1.4 (U) Epic Creation

3.1.5 (U) Enterprise to Contract Traceability

3.1.6 (U) Normalized Capability Roadmaps

3.1.7 (U) Benefits

3.2 (U) Digital Engineering (DE)

3.3 (U) Architecture Engineering

3.3.1 (U) Levels of Architecture for NGA

3.3.2 (U) Architecture Governance

3.3.3 (U) Architecture References

3.4 (U) Configuration Management (CM)

3.4.1 (U) Configuration Baselines

3.4.2 (U) The CM process includes five main components

3.4.3 (U) Configuration Control Authority

3.5 (U) Readiness and Technical Reviews

3.6 (U) Requirements Engineering

3.7 (U) Risk, Issue, and Opportunity Management iii

3.8 (U) Schedule Management

3.8.1 (U) Effectivities and the Mission Needs Taxonomy

3.9 (U) Security Engineering

3.9.1 (U) Security Engineering Objectives

3.9.2 (U) Security Engineering Approach

3.9.3 (U) Security Engineering Software Approval

3.10 (U) Standards Management

3.10.1 (U) GEOINT Standards

3.10.2 (U) IT Standards

3.11 (U) Test and Evaluation

3.12 (U) Additional Systems Engineering Elements

3.12.1 (U) Agile Acquisition

3.12.2 (U) DevSecOps Development Approach

3.12.3 (U) Cloud Guidance

4 (U) ENGINEERING ROLES, RESPONSIBILITIES AND ENGINEERING

GOVERNANCE

4.1 (U) Roles and Responsibilities

4.1.1 (U) NGA Chief Engineer

4.1.2 (U) Enterprise Engineering Office

4.1.3 (U) Programs

4.1.4 (U) Program Offices

4.1.5 (U) Development and Support Contractors

4.1.6 (U) Stakeholders

4.2 (U) Engineering Governance

5 (U) ENGINEERING TOOLS

6 APPENDIX A – (U) ACRONYMS

7 APPENDIX B – (U) MSA MILESTONE DOCUMENTATION REQUIREMENTS, ICS

801-01

8 APPENDIX C – (U) APPLICABLE DOCUMENT AND TOOLS LINKS

9 APPENDIX D – (U) PROGRAM-LEVEL SYSTEMS ENGINEERING PLAN (PSEP)

TEMPLATE

iv

List of Figures

Figure 1.4-1 (U) A Multi-Tiered Approach to Systems Engineering

Figure 1.5-1 (U) Examples: NGA Acquisition Lifecycle Activities

Figure 3.1.1-1 (U) Scaled Agile Framework® Overview

Figure 3.1.1-2 (U) Large Solution SAFe® Configuration

Figure 3.1.3-1 (U) Epic Framework

Figure 3.1.5.1-1 (U) Requirements and Mission Needs Taxonomy

Figure 3.1.5.2-1 (U) Expanded Mission Needs Taxonomy

Figure 3.2-1 (U) NGA’s Digital Engineering (DE) Ecosystem

Figure 3.3.3.2-1 (U) JARM 10-Layer Model

Figure 3.6-1 (U) NERP Processes and Artifacts by Requirements Layer

Figure 3.6-2 (U) NERP Processes

Figure 3.7-1 (U) RIO Tiers

Figure 3.7-2 (U) RIO Jira Taxonomy

Figure 3.8.1-1 (U) Effectivity to Mission Needs Taxonomy Relationship v

(U) TBD/TBR LOG

Paragraph/ Figure/Table

TBD TBR Description vi

(U) CHANGE LOG

Title: (U) NGA Systems Engineering Plan (SEP)

SCN/

REVISION

DATE ITEMS AFFECTED

REMARK/CHANGE

AUTHORITY

000 22 Mar 2018 Initial Issue RFC N01-0644

CCB 0013-18

dtd 22 March 2018

CN-001 This Change Notice incorporates the following RFC:

001 13 June 2018 Change Log, 2.1 RFC N01-0646J

CCB 0028-18

dtd 25 June 2018

Rev A This Revision incorporates the following RFC:

002 09 Oct 2019 All – Revision A RFC N01-0668

CCB 0035-19

dtd 18 October 2019

Rev A CN-001 This Change Notice incorporates the following RFC:

003 26 May 2021 Change Log, 2.1, 3.6, Appendix A RFC N01-0704

CCB 0074-21

dtd 07 June 2021

Rev B This Revision incorporates the following RFC:

004 23 Sep 2021 All – Revision B RFC N01-0711

CCB 0042-21

dtd 28 September

1 (U) INTRODUCTION

(U) This document describes the approach to Systems Engineering followed by the National Geospatial-Intelligence Agency (NGA). The description includes principles and policies that enable NGA to strengthen systems engineering and its support to the continuing evolution of the National System for Geospatial-Intelligence.

(U) The intended audience of this Systems Engineering Plan (SEP) includes NGA systems engineers, architects (system, business, and data), program managers, and mission partners supporting systems engineering activities from the strategic to the system/segment level. The audience also includes other NSG stakeholders such as NGA management and oversight members who must understand the general engineering and technical approaches being applied in support of the NSG.

(U) This section provides a general description of the NSG and sets the context for its systems engineering practices. It also identifies key SEP related documents and information, describes the process for updating the SEP, and describes the basic structure of the document. The practices identified in this SEP are recommended at all program levels and all phases of the systems lifecycle. For the purposes of this SEP, programs are defined and inclusive of Major System Acquisitions (MSA), Integrated Program Offices (IPOs), Sensor Integration Program (SIP) Offices, Government Program Management Offices (GPMOs), Programs, Integration Projects, Segments, and Teams.

1.1 (U) The National System for Geospatial-Intelligence (NSG)

(U) The NSG is defined as “the combination of technology, policies, capabilities, doctrine, activities, people, data, and communities necessary to produce Geospatial Intelligence (GEOINT) in an integrated multi-intelligence, multi-security domain environment”. Based on this definition, the NSG includes elements that extend beyond the control of NGA. The technical approach described in this SEP applies to those elements of the NSG that NGA funds and directly manages.

1.2 (U) Technical Approach

(U) The technical approach provided in this SEP addresses activities necessary to support the life cycles of systems/segments/services/capabilities within NGA. For the purposes of this SEP, the term activity is defined to include any acquisition program, project, study, and task that involves a systems engineering function.

1.3 (U) SEP Scope

(U) This SEP is:

• a plan to guide NGA’s systems engineering practices in support of the NSG;

• intended to cover acquisition programs, regardless of type, size, length, or cost;

• supportive of initiatives such as service-centric orientation and agile acquisition at all levels, Enterprise to System/Segment that are pushing the NSG toward smaller elemental pieces and quicker more responsive activities.

1.4 (U) NSG Systems Engineering Activities Scope & Relationships

(U) As a System of Systems (SoS), the NSG has a life span that encompasses and transcends the lifecycle of each of the Systems/Segments/Services/Capabilities that it comprises. The Defense Acquisition Guidebook (DAG) Chapter 3 and the curriculum of the Defense Acquisition University (DAU) define processes that are applicable to both technical management systems and technical engineering. DAG/DAU technical management system processes include: technical planning, Configuration Management (CM), interface management, technical data management, requirements management, risk management, technical assessment, and decision analysis. The DAG/DAU technical engineering processes are: stakeholder requirements definition, requirements analysis, architecture design, development, integration, verification, validation, and transition which may be applicable to both traditional and agile engineering and acquisitions initiatives. These processes should be tailored to meet the program’s needs and development methodology.

(U) Figure 1.4-1 illustrates a multi-tiered approach to systems engineering; specifically, how enterprise-level systems engineering activities relate to the execution of the program-level systems engineering activities. All activities use systems engineering and technical management processes, but the depth and focus of the application of those processes is a key differentiator of large versus small activities. It is important to understand the size, scope, and significance of the program in order to understand how to tailor systems engineering processes to achieve maximum flexibility and agility in achieving program goals/objectives and delivering capabilities to the user in the minimum amount of time necessary.

Figure 1.4-1 (U) A Multi-Tiered Approach to Systems Engineering

1.5 (U) NGA Acquisition Lifecycle

(U) Figure 1.5-1 highlights the five sub-phases of the NGA Standard Acquisition Process (i.e., from technology development to operations and sustainment) and aligns technical processes to an agile development cycle or a traditional lifecycle.

(U) Technology Development. Both agile and traditional development activities begin with a technology development phase that includes such activities as an initial concept definition (e.g. Concept of Operations (CONOPS), Statement of Capabilities (SOC)) preliminary requirements are defined and Analysis of Alternatives (AoAs) and prototyping activities are conducted.

• (U) Engineering: In agile development, NGA uses Solution Epics (SEs) to capture development efforts at an Enterprise-level. An SE consists of multiple SE Minimum Viable Product functions (MVPf(s)). The SE MVPf(s) are further decomposed into Program Epics (PE). There is no set timeframe in developing these artifacts (section 3.1 offers further discussion on SEs, PEs, and MVPf(s)).

Traditional development requirements can be captured in either a System

Requirements Document (SRD), Capability Oriented Requirements (COR), or Design Document (DD).

• (U) Manufacturing, Development, Integration and Test: Both agile and traditional development conduct these activities, the major difference is when capabilities are going to be available to the user. Agile manufacturing, development, integration, and testing are iterative processes where capabilities are released every 8 to 12 weeks. In traditional manufacturing and development these activities occur in a serial manner and once completed, capabilities are delivered to the Integration and Test team for final testing. The time duration for these activities can be up to a year (or greater) in duration.

• (U) Deployment: In both agile and traditional development, after the developer has completed internal Manufacturing, Development, Integration and Testing of new capabilities, both are delivered to the NGA Test Organization (NTO) for independent Testing and Evaluation (T&E) of changes to the NSG Enterprise baseline prior to operational deployment. It is at the NTO where Authority to Operate (ATO) is granted.

• (U) Operations and Support: Regardless of the systems engineering method used, once capabilities have completed NTO testing and achieved ATO, capabilities are deployed into operations by User Facing Services (UFS) and once accepted for use by the Missions Owners, the capability is now in Sustainment.

(U) The purpose of the NGA Enterprise Readiness (ER) Review process is to facilitate efficient and effective Acquisition Readiness reviews that assess whether segments, systems, services, capabilities, and/or applications are ready to be moved through the various milestones in the NGA Acquisition Lifecycle, including into or out of the operational environment. The ER process is tailorable to include the type and number of program reviews that may be required and documentation required at each review.

(U) For MSAs, NGA must adhere to the milestones as prescribed in IC Directive 801, and deliver the required documentation for each milestone (Appendix C). The three high-level milestones are:

Milestone A: Occurs prior to the beginning of the Technology Development phase of the acquisition lifecycle.

Milestone B: Occurs upon completion of the Technology Development phase and prior to entering the Engineering and Manufacturing phase of the acquisition lifecycle.

Milestone C: Occurs at the end of the Engineering and Manufacturing phase and prior to the beginning of the Production and Deployment phase.

(U) The execution of these milestones is governed by the criteria and thresholds established by ICD 801 and DoD Directive 5000.01.

Figure 1.5-1 (U) Examples: NGA Acquisition Lifecycle Activities

(U) Enterprise-level Systems Engineers are integral to this process, as they must evaluate, monitor, and orchestrate the acquisition and upgrade of multiple systems/segments/services at the different stages of the systems engineering lifecycle which covers initial concept development through deployment, sustainment, and retirement.

1.6 (U) De-confliction of Priorities

(U) Programs and their suppliers need to be attentive and timely to users’ needs throughout the community, priorities may become conflicted on occasion require de-confliction. De-confliction of priorities must take into account mission, technical, cost, and scheduling impacts to the program.

(U) In the event that a program and its internal suppliers are unable to resolve prioritization to an acceptable level, the prioritization issue will be escalated to CIO-T senior leadership and senior level user representatives for joint adjudication. For engineering efforts, in instances where programs and their external suppliers are unable to resolve priority disagreements at the program or IPO levels, issues can be escalated to the Engineering Review Board (ERB), as applicable.

1.7 (U) SEP Configuration Control

(U) The NGA Configuration Control Board (CCB) is the approval authority over future versions/updates to the SEP. However, technical ownership of this document falls within the responsibility of the NGA Chief Engineer.

2 (U) APPLICABLE DOCUMENTS

(U) The information provided in this SEP reflects enterprise-level systems engineering guidance from a variety of information sources. These sources include Department, Community, and Agency-level guidance documents. Overall, NGA systems engineering activities are influenced by direction and guidance from a variety of internal/external policies, processes, procedures, standards, and frameworks. The sources for this information include government, industry, academic, and professional sources.

GEA GEOINT Enterprise Architecture version 4.5 Jun 2019

NCMP NGA Configuration Management Plan Jun 2021

NERP NGA Enterprise Requirements Process May 2021

NGA ADE NGA Acquisition Design Elements Aug 2020

NGA ERP NGA Enterprise Readiness (ER) Process Document

Jan 2020

NGA TEMP National System for Geospatial-Intelligence (NSG) Enterprise Test and Evaluation Master Plan

Jun 2018

NSMP NGA Schedule Management Plan Sep 2020

Tier 2 CM Procedure

Tier 2 Configuration Management (CM) Procedure May 2018

DAG Defense Acquisition Guidebook Sep 2020

DoDD 5000.01 Department of Defense Directive 5000.01, The Defense Acquisition System, May 2003 incorporating Ch. 2

Aug 2018

DoDI 5000.2 Department of Defense Instruction 5000.2, Operation of the Defense Acquisition Framework

Jan 2020

DoDI 5000.87 Department of Defense Instruction 5000.87, Operation of the Software Acquisition Pathway

Oct 2020

DoD DE Strategy Guide

Department of Defense Digital Engineering Strategy Guide

Jun 2018

CNSSI 1253 Committee on National Security Systems (CNSS) Instruction No. 1253

Mar 2014

ICCR (ICD115) Intelligence Community Capabilities Requirements (ICCR) Process (ICD 115)

Dec 2012

ICD 503 Intelligence Community Information Technology Systems Security Risk Management

Sep 2008

ICD 801 Intelligence Community Directives Number 801 Aug 2009

IC PAG Intelligence Community Program Architecture Guide version 2

Feb 2013

JARM Joint Architecture Reference Model version 5.0 Mar 2016

ODNI ICS 801-

Intelligence Community Standard 801-01, Major Systems Acquisition

Jun 2013

ITRMP Information Technology Risk Management Process Apr 2021

3 (U) ENGINEERING ELEMENTS AND PROCESSES

(U) This section provides an overview of various components of systems engineering and related processes. Detailed descriptions and instructions for the implementation of each process within NGA is provided via attached enclosures and/or appendices, as appropriate.

3.1 (U) Enterprise Release Management (ERM)

(U) ERM orchestrates and integrates engineering activities and resources across multiple interdependent system delivery life cycles in order to meet project objectives across the NSG Enterprise.

(U) In order to achieve this, ERM facilitates and supports system development and integration efforts across all programs. ERM uses the current version of the Scaled Agile Framework® (SAFe®) for Lean Enterprises (as of this writing SAFe v. 5.1) as the basis to enable the NSG to conduct enterprise-level Agile development activities that deliver defined objectives. ERM closely integrates with Requirements, Architecture, Digital Engineering, Schedules, and other engineering activities to actively anticipate, de-conflict, monitor and manage cross-contract dependencies and schedules for enterprise level programs. These activities ensure mission alignment and synchronization across projects, programs, and segments to rapidly deliver capabilities that fulfill mission needs.

(U) The goals of ERM are to provide:

• Enterprise Agility

• An Enterprise-level visibility of project/program development activities

• A common look and feel of project/program artifacts

• Top-to-bottom traceability of development activities – from the Enterprise to contract development level

• Normalized Project and Program roadmaps

3.1.1 (U) Enterprise Agility

(U) NGA is moving away from traditional development and acquisitions processes in favor of agile. As such, ERM follows and recommends the implementation of SAFe which “integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictability, and with higher quality.” Figure 3.1.1-1 provides an introduction to the seven core competencies of the Lean-Agile Enterprise.

UNCLASSIFIED

UNCLASSIFIED

Figure 3.1.1-1 (U) Scaled Agile Framework® Overview

(U) ERM Enterprise Agile activities include:

• Promotes the harmonization and implementation of Enterprise-Level agile practices at scale such that different programs can interact with one another in a standardized and uniform manner

• Provides mentorship to teams that are new to working within Enterprise-Level agile constructs

• Provides guidance to programs as they develop their SEs and PEs to align with Enterprise Agile best practices while remaining in compliance with both the ERM Epic Framework and the Mission Needs Taxonomy.

(U) To support the needs of enterprise-level programs and thus create harmonization across these programs, ERM has adopted the “Large Solution” SAFe configuration (Figure 3.1.1-2) which provides the requisite positions, components, processes, and workflows necessary to allow programs to meet their objectives and mission needs.

The ERM team works with program partners to enhance their introduction to Large Solution SAFe; provides introductory training (Introduction to ERM, artifact generation, tool set-up and usage, etc.); and mentorship as needed as the program progresses through its lifecycle. The Large Solution SAFe Configuration also supports the top level Solution Epic. Epics can best be defined as a container for a solution development initiative large enough to require analysis, the defining of a Minimum Viable Product (MVP), and financial approval before implementation. The Large Solution configuration also establishes the organizational construct of a “Solution Train” that is used to build large and complex Solutions (often as an SoS) that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of both internal and external suppliers (e.g., programs, Acquisition Offices (AOs), Mission partners, etc.). For additional information about Solution Trains and their subordinate agile teams please refer to: https://www.scaledagileframework.com/solution-train/.

Figure 3.1.1-2 (U) Large Solution SAFe® Configuration

3.1.2 (U) Enterprise-Level Visibility

(U) Enterprise-level visibility is achieved by working closely with partners, conducting periodic briefings, chairing working group meetings, and providing the ERM space on NGA’s Enterprise instance of the Atlassian Confluence™ tool. ERM’s Confluence site provides visibility into ERM’s mission and the development activities of programs by providing a program specific space for each program partner to create and store program artifacts that support the generation of SEs and PEs. Additionally, the ERM Confluence site serves as a curated knowledge repository that includes access to documentation, templates, automation tools, useful “how-to’s,” and team contact information.

3.1.3 (U) Normalized Artifacts

(U) NGA programs are responsible for managing their requirements baseline at both the enterprise level and program levels. To do so, agile programs use SEs and PEs for this purpose, as depicted in the epic framework Figure 3.1.3-1. A repository of templates and best practices for creating normalized can be found in the ERM Confluence site.

(U) Solution Epics: An SE captures the customer facing capabilities to be delivered and is managed by the Epic owner. SEs are typically cross-cutting and capture development efforts needed to realize mission focused initiatives. The SE is an enterprise-level artifact used in agile development, and it captures mission needs in a development initiative large enough to require analysis; consists of multiple SE Minimum Viable Product functions (MVPf(s)), and includes success criteria. SE MVPf(s) are the minimal viable functions the user has requested that are required to deliver a minimal, viable solution. The format and content of SEs is the Lean Business Case (LBC), which is tailored from the SAFe LBC. The planning horizon for an SE is up to five years. It is important to note that SEs are CCB controlled.

(U) Program Epics: A PE is designed for a single development activity to accomplish SE MVPf(s). Like SEs, PEs also have MVPf(s), and multiple PE MVPf(s) may be required to deliver a SE MVPf. These PE MVPf(s) are specific tasks the program team must execute to satisfy their allocated portion of the SE MVPf(s). When requirements are not traced via an agile construct, PE MVPf(s) are traced back to the appropriate program requirements found in a DD, COR, or SRD. The planning horizon for a PE is up to two years. PEs are program controlled.

Figure 3.1.3-1 (U) Epic Framework

(U) Epic creation is a collaborative effort, meaning the Product Owner/Product Manager (POPM), Architects, Engineers and other stakeholders are in the same room at the same time developing the content.

(U) The Framework for both SEs and PEs is the same, and both are comprised of the following four artifacts:

1. End State Graphic

2. Lean Business Case

3. Roadmap

4. The Stakeholder Diagram

3.1.3.1 (U) End State Graphic

(U) The End State Graphic describes the end-state vision of the SE/PE. This is usually an Operational View (OV) -1, or an OV-2. The diagram is descriptive enough to convey the desired outcome of development efforts. It is recommended this artifact be created first.

3.1.3.2 (U) Lean Business Case

(U) The LBC defines and describes what needs to be done to reach the end-state. The LBC text is written in the voice of the customer. This creates common understanding and ownership amongst the stakeholders.

(U) The majority of the fields in the LBC template are self-explanatory; however, four sections warrant additional discussion.

• (U) Epic Description/Value Proposition: Once the End State graphic is created, the Epic Description/Value Proposition is developed, using the following format:

o [For] users of the proposed capability being developed;

o [Who] who performs what mission;

o [Our] the proposed solution name;

o [Is A] how we are going about providing it;

o [That] describes how the proposed solution provides value and is;

o [Unlike] unlike the current solution/capability; and o [Our Solution] describes how the proposed solution is better.

• (U) Minimum Viable Product functions: The MVPf(s) define what is necessary for the SE/PE to be complete. The statements are again in the voice of the customer (e.g., mission owner); describing what the user needs. The MVPf(s) are not solution, engineering, or architecture statements. For SE MVPf(s) only, the MVPf(s) are to be mapped to appropriate NGA Enterprise Requirements, as they are created based upon the NGA Enterprise Requirements developed from strategic documentation. Program Epic MVPf(s) are mapped from the program COR, RD, or DD requirements, if applicable.

• (U) Incremental/Implementation Strategy: This defines how the epic will be implemented, e.g., capabilities will be released every two weeks (sprints), and shippable increments (Releases) will occur every 8 to 12 weeks.

• (U) Sequencing and Dependencies and Key Partners: Sequencing ensures that tasks are scheduled such that tasks are not begun until one or more other conditions, events, or tasks have occurred, have begun, or have been completed.

These conditions, events, or tasks are Dependencies. Sequencing of events/tasks and dependencies are to be depicted on the Epic Roadmap.

3.1.3.3 (U) Roadmap

(U) The Roadmap depicts how to arrive at the end state over time. It is a high-level schedule of major milestones and events that show when major activities occur and when capabilities are developed that lead to the end-state. The roadmap also depicts dependencies that may impede development efforts. While the roadmap is dynamic and is refined as the effort progresses, If the SE has an RFC and the Roadmap changes, a change is needed to the RFC.

(U) Much of the information that is used to graphically depict the roadmap reflects information found in several fields within the LBC. Specifically, the following LBC fields will influence the roadmap graphic:

• Estimated Development Timeline

• Start Date

• Completion Date

• Incremental Implementation Strategy

• Sequencing and Dependencies + Key Partners

• Milestones or Checkpoints

3.1.3.4 (U) Stakeholder Relationship Diagram

(U) A Stakeholder Relationship diagram is a visual description of who will take the program to its end state. This diagram illustrates the “major players” that must work together to deliver this end state and how they are related to each other. Stakeholders, by definition, can be internal or external and are those people or programs that have an interest in or will be impacted by the capabilities provided within the solution. This diagram could be a Systems View (SV-1) or an OV-4.

(U) Much of the information that is used to graphically depict the Stakeholder Relationship Diagram will have been identified in several fields within the Roadmap.

Specifically, the following LBC fields will influence this graphic:

• Sponsors

• Users and Markets Affected

• Impact on Products, Programs and Services

• Sequencing and Dependencies + Key Partners

3.1.4 (U) Epic Creation

(U) The tool used in NGA to create SEs and PEs is Confluence. Confluence provides a collaborative environment that tracks changes (and who made these changes) to the SE or PE. The ERM Team provides space on its Confluence page for programs to develop their SEs and PEs. The approved SE/PE template is pre-loaded (by the ERM Team) into the project/program section to ensure consistent artifacts across the enterprise. The ERM Confluence site also provides information on how to create SEs and PEs. If the SE and/or PE is to be baselined via the Request for Change (RFC) process, ERM has a tool to export the complete SE or PE (End State Graphic, LBC, Roadmap, and Stakeholder diagram) into a Microsoft Word® or Adobe® PDF document type for inclusion in the RFC package.

3.1.5 (U) Enterprise to Contract Traceability

3.1.5.1 (U) Requirements and Mission Needs Taxonomy

(U) NGA’s Enterprise Jira database is used to achieve Enterprise-level to contract-level development traceability. The basic Requirements and Mission Needs taxonomies (Figure 3.1.5.1-1) were developed to show how requirements and mission needs are related at the Enterprise and Contract level. The Requirements and Mission Needs Taxonomy was developed to provide the structure for entering and linking SEs, SE LBCs, PEs, PE MVPf(s), and feature data into Enterprise Jira.

Figure 3.1.5.1-1 (U) Requirements and Mission Needs Taxonomy

3.1.5.2 (U) Expanded Mission Needs Taxonomy

(U) The basic Mission Needs Taxonomy does not define how to accommodate the addition of new requirements to the existing program baseline (e.g., when a Sensor Program Office allocates new requirements to another IPO or GPMO). To clarify this type of relationship in Jira, the basic Mission Needs taxonomy had to be expanded (Figure 3.1.5.2-1).

Figure 3.1.5.2-1 (U) Expanded Mission Needs Taxonomy

(U) It is through the NGA RFC process that a Sensor Program Office, or another program, is able to allocate requirements and provide funding to another program office to conduct new, or additional development activities. It is recommended these requirements be negotiated between the requesting organization and program and that these requirements are captured in a PE LBC and included in the RFC. Once the RFC is approved, the implementing organization has formally accepted the new requirements, and they are now in scope. This enables the implementing organization to conduct new/additional development activities.

(U) Although the requesting Sensor Program Office or program is funding development activities and has stakeholder influence, it does not have responsibility or control of development activities. Funding is captured by addition of an “is funded by” link; the linkage is between the requesting organization SE MVPf and the funded Parent Organization PE MVPf. In some cases, the receiving organization may already be developing a capability that can be leveraged by the Sensor Program Office or program at no cost. In these instances, the “satisfies dependency” link is used.

(U) The use of the PE LBC remains optional, and if used in the context of the Mission Needs taxonomy the recommended PE LBC to PE MVPf relationship is captured using the “relates to” Jira issue linkage.

3.1.6 (U) Normalized Capability Roadmaps

(U) The tools used to create these normalized capability roadmaps are Enterprise Jira and Tableau®. Tableau extracts the SE, PE, and Feature data that is in Enterprise Jira to create Solution and Program-level Capability roadmaps. These Capability roadmaps are normalized across programs and are visible to the enterprise.

3.1.7 (U) Benefits

(U) The benefit of ERM is that it provides awareness of upcoming planning events and releases early enough to influence schedules and resolve potential conflicts. In order to achieve this, ERM monitors: schedules, synchronization/cadences, cross-program dependencies, strategic initiatives, and other cross-contract activities.

3.2 (U) Digital Engineering (DE)

(U) NGA employs a Model Based Systems Engineering (MBSE) methodology that focuses on creating and exploiting discipline1-specific models as the primary means of information exchange, rather than a document-based information exchange.

(U) DE is a methodology that achieves a single comprehensive view of the system by integrating discipline-specific data sources, which are created using standard model elements (DoD DE Strategy Guide). In this context, the term “system” can be applied to technical (e.g., architecture, Information Technology (IT) infrastructure, development, test, security); financial (e.g., program & budget, cost-estimation); or process components (e.g., requirements, policy, configuration management, standards). DE enables integrated outcomes by creating the environment where authoritative system data from various sources can be consolidated using a common metadata format, which are analyzed with the aid of established relationships between the various data sources (Figure 3.2-1).

(U) NGA’s transition from legacy management process to a digital ecosystem that combines model-based techniques, digital practices, and an underlying computing infrastructure is being accelerated by employing DE, which is a variant of MBSE.

(U) The DE Ecosystem consists of the following:

• (U) Models which provide a digital representation of a specific system or operation and guide the creation and management of an Authoritative Source of Truth (ASoT);

1 “Discipline” in this context refers to specific categories of information (e.g., requirements, architecture, project management/development, security, finance) that the enterprise uses for development & sustainment resource allocation decisions.

• (U) ASoTs are the datasets created by employing Discipline-specific models, that capture the current information state and provenance of DE baseline components;

• (U) Consolidated Reference Repository (CRR), which is the data store that houses the unique data elements of all modeled information (i.e., ASoT) and establishes relationships between the discipline-specific ASoTs, and provides the data for integrated analysis and reporting;

• (U) Best Practices that collectively are a group of policies, standards, communications, and workforce development which supports the adoption and execution of DE across the lifecycle;

• (U) Technology Infrastructure that provides the secure networks, storage, cross-domain transfer, and tools that enable model creation and maintenance, data access, ASoT generation and use, relationship formation, and integrated analysis and reporting.(U) Working with stakeholders to create and maintain the DE ecosystem, improves transparency and traceability of requirements and budgets across the architecture from strategy to implementation, resulting in the more efficient and effective delivery of products and services.

Figure 3.2-1 (U) NGA’s Digital Engineering (DE) Ecosystem

(U) Additional details of NGA’s DE constructs and implementation is described in the

DE CONOPS.

3.3 (U) Architecture Engineering

(U) The primary objective of building and maintaining architectures is to provide an architecture ASoT for Digital Engineering.

3.3.1 (U) Levels of Architecture for NGA

(U) At NGA, the levels of architecture abstraction represent a continuum of architectural detail that enables tracking of Strategic Needs and Budget Program associations through assigned programs through SEs and PEs that define the deliveries of executable solutions over time.

3.3.1.1 (U) GEOINT Enterprise Architecture (GEA)

(U) The GEA encompasses existing and developmental, systems, services, and programs that support the mission of the Agency. The GEA is constructed with stakeholders, leveraging active data sets across the organization. GEA datasets are exploited through Architecture Frameworks to depict integrated views to describe the Agency Mission material and non-material capabilities and potential gaps. In migrating from a document-centric (e.g., Word, PowerPoint, and Excel) engineering content perspective to a DE data paradigm, with regard to architectural information, the enterprise is able to leverage models and data to analyze established relationships and export architecture viewpoints based on real time information. The GEA assists in guiding investments and acquisition activities to define the scope of development efforts, aid in integrating activities, and provide a common baseline for decision makers to guide efforts toward accomplishing mission success.

3.3.1.2 (U) Solution Architecture Supporting Community Acquisition Milestones

(U) Programs defined through Intelligence Community (IC) and Department of Defense (DoD) capabilities acquisition must conform their architecture description for Independent Cost Baseline Document (ICBD), the IC Program Architecture Guide (IC PAG) and/or similar DoD instructions. Programs may create architectural artifacts as needed to support other engineering activities such as requirements decomposition, CONOPS development, and risk mitigation

3.3.1.3 (U) Solution Architecture Supporting Solution Epics

(U) SEs decompose program solution architectures into relatively self-contained modular pieces for development planning. SEs define criteria that drive solution architecture models and associated requirements suitable for agile prioritization and even further decomposition. This decomposition of development work into SEs allows programs to coordinate, leverage, and de-conflict development work and dependencies across the program functional scopes.

3.3.1.4 (U) Program Architectures Supporting Agile Implementation

(U) PEs are the result of decomposition of solution criteria into self-contained modular pieces for program development planning. PEs define the criteria that drive program architecture models and associated requirements/features suitable for agile prioritization and allocation to development teams. Breaking development work into PEs also allows the programs to coordinate, leverage, and de-conflict development work across multiple development contracts or agile teams.

3.3.2 (U) Architecture Governance

(U) Architecture governance is used protect the integrity of accepted architecture at the Strategic, Enterprise, and System/Service levels; and to maintain its overall coherence in the face of change. NGA’s architecture governance approach is to modulate the acceptance of architectural content using decision gates at key points of entry into the repository. These decision gates represent a disaggregation of authority down to the lowest levels where proposed and planned design decisions are made. By sharing a common repository, standards, instructions, and tools, all architecture content is shared up and down the architecture layers between the GEA and Program Management Offices (PMO) developing solution architectures representing conceptual, proposed, planned, and operational designs.

3.3.3 (U) Architecture References

(U) The following artifacts are maintained to promote architecture development at NGA:

3.3.3.1 (U) GEA Website

(U) The GEA website presents GEA architecture information to all NSG users. The GEA website includes the following tabs:

• GEA Landing Page: Contains a simplified DE metamodel linking across GEA

Website

• GEA Navigator: Allows non-architects to investigate GEA relationships

• GEA Baseline: Contains all current GEA Baselined products

• GEA Change Log: Tracks historical changes to the GEA

• GEA Visualizations: Provides additional visualizations to investigate GEA relationships

• IC Joint Architecture Reference Model (JARM) / Technology Services Taxonomy

(TST) 5+: Provides access to IC JARM documentation

• Architecture Practitioner Page: Provides access to architect resources

• Architecture related Policy: Lists all applicable architecture policies and presentations

3.3.3.2 (U) IC Joint Architecture Reference Model (JARM)

(U) The IC JARM is an extension to the Federal Enterprise Architecture (FEA), tailored to the activities, functions, and services unique to the IC. The JARM consists of three interrelated taxonomies overlaid on a single organizing construct, the JARM 10-Layer Model (Figure 3.3.3.2-1).

(U) The model is typically discussed from the top (Layer 10) to the bottom (Layer 1) and each layer of the model represents a logical grouping of like entities, capabilities, functions, or services within an enterprise. The JARM supports architectural analysis and reporting, increased communication, reusability, and interoperability across IC Mission Elements. NGA captures desired updates and changes to the IC JARM Technical Service Taxonomy (TST) in a Microsoft Excel file called the IC JARM TST 5+.

Figure 3.3.3.2-1 (U) JARM 10-Layer Model

3.4 (U) Configuration Management (CM)

(U) CM is an essential element of systems engineering which provides the mechanisms and procedures for maintaining product consistency and establishes an appropriate level of configuration control for NGA’s evolving systems. CM ensures that: interfaces are defined, designs trace to requirements, documentation is accurate, and change is documented and controlled. The NGA Configuration Management Plan (NCMP) details NGA’s configuration management procedures.

3.4.1 (U) Configuration Baselines

(U) The NCMP categorizes the NGA technical baselines as Functional, Allocated, and Product. In general terms, these baselines are described as follows:

• Functional Baseline: defines functional, performance, interface, interoperability, and verification requirements. It is established with the approval of the top-level requirements documents (e.g., RD, DD, and COR). The NGA CM libraries are the repository for the functional baseline. Typically, the functional baseline is established during the pre-acquisition phase of a project and managed through completion of a project or disposal of a system.

• Allocated Baseline: defines design and implementation requirements. It is composed of the design documentation as well as the hardware and software items being developed. An allocated baseline is established during the design phase of a project, and managed through the end of development/integration.

• Product Baseline: describes the as-built system; and user, operations, and support requirements. It is composed of the hardware and software items of the operational systems. The Product Baseline is established as the project transitions to operations, and is managed through system disposal.

3.4.2 (U) The CM process includes five main components

• CM Planning – The identification of the processes and procedures used to manage the configuration of systems and the changes to those systems throughout the life cycle.

• Configuration Identification – Identifies and documents the functional and physical characteristics of configuration items and establishes appropriate baselines.

• Configuration Control – Evaluates, coordinates, and approves proposed changes to an established baseline.

• Configuration Status Accounting – Records and reports the status of configuration items and change requests (proposed or approved).

• Configuration Audits – Periodically review all controlled items to ensure that they evolve properly with recorded traceability and that they meet program needs.

3.4.3 (U) Configuration Control Authority

(U) The NGA CCB serves as the final approval authority for technical/functional baseline changes for IT. Configuration control of the development and operational baseline has been delegated to the programs and the NGA Chief Information Officer and IT Services (CIO-T) operations group. The Configuration Items (CIs) controlled by the CCB are hosted in the Baseline Management System (BMS).

(U) The NCMP describes NGA CM-specific information such as NGA Configuration Control Authorities (CCAs), the Engineering Review Board (ERB), IT governance hierarchies and relationships, change control and implementation procedures, and Enterprise Requirements Hierarchy. In addition, the Tier 2 CM Procedure is available and addresses detailed guidance for RFC; Discrepancy Reports and Problem Reports;

Change Implementation; Verification and Audits; Documentation Preparation and Maintenance; and Schedule Management.

3.5 (U) Readiness and Technical Reviews

(U) NGA supports planning for NSG milestone review and associated activities in accordance with the Tier 2 NGA Enterprise Readiness (ER) Process Document. The purpose of the NGA ER process is to facilitate efficient and effective Acquisition Readiness reviews that assess whether segments, systems, services, capabilities, and/or applications are ready to be moved through the identified milestones/reviews in the NGA Acquisition Lifecycle; including into or out of the operational environment. The NGA ER Process is designed to accommodate the need for flexibility, by tailoring to the specific needs of the acquisition effort. The process documentation includes readiness checklists to help facilitate planning for and execution of technical review activities. The readiness process also addresses programs that are utilizing agile development and provides a process for evaluating readiness to operate in the Cloud. Agile development checklists are available for Release Planning Events (RPEs) and Final RPEs (FRPEs) and located on the Integration Test and Image Quality Office (VOLT) website.

(U) Within the IC, the Office of the Director of National Intelligence (ODNI) holds the Milestone Decision Authority (MDA) for all MSA Milestone A and B events. If and when the ODNI delegates the MDA authority to NGA for Milestone A and B events, the Component Acquisition Executive (CAE) will serve as the MDA. The MDA for Milestone A and B events cannot be delegated below the CAE. The NGA CAE for all other non- MSA reviews may delegate the decision authority responsibility for Level-0 and Level-1 Readiness Reviews.

(U) NGA’s Assessments Division within the Architecture and Engineering Office works in coordination with the appropriate Office of Primary Responsibility (OPR) or Directorate and identifies a primary and alternate MDA for all milestone readiness events and reviews.

(U) The NGA ER process is flexible and can be tailored to the specific needs of the acquisition effort. The ER Process can support programs that employ either traditional or agile engineering processes. The NGA ER process supports acquisition efforts that require significant technical evaluation, such as an MSA. The process also supports other acquisition efforts of small scope, low risk, and proven technology or requiring quick response in support of crises, justifies tailoring the readiness process.

3.6 (U) Requirements Engineering

(U) The approach to engineering requirements followed by the NGA is documented fully in the CCB approved document, NGA Enterprise Requirements Process (NERP). The NERP identifies relationships with other engineering disciplines identified in the SEP and illustrates the dynamics with each in order to provide an actionable and defendable requirements baseline. Roles of the stakeholders are identified in context of requirements engineering in the NERP. NGA’s process for enterprise requirements follows the same major activity paths, whether an executing budgeted program office is working a traditional or agile path. The Standard Operating Procedures (SOP) associated with each layer of the NGA requirements process are provided in the

NERP.

(U) NERP Goals:

• Identify, document, and maintain requirement baselines

• Manage and control requirement baselines using approved configuration control methods

• Document horizontal and vertical requirement traceability

• Align requirements to architecture

(U) The NERP has three sub-processes (Figure 3.6-1) that address the varying levels (layers) of requirements at NGA. The sub-process NERP 01 governs activities occurring within the Strategic Layer, NERP 02 governs the activities within the Enterprise layer, and NERP 03 covers the Program layer

(U) It is possible to tailor individual layers within the NERP. For the purposes of this document, tailoring is defined as “the adaptation of a process for a particular purpose or individual customer” while fulfilling NERP goals.

(U) The NERP connects to and results from the greater NSG Enterprise Request Framework (NERF), managed by NGA’s Partner Engagement Integration Division. The NERF adjudicates a request from mission partners against baselined requirements to align with known scope for budgeted programs when possible via NERP. Where scope and/or requirements do not exist, the NERF activities flow up to NGA leadership for decision. The NERF adjudicates a request from mission partners against baselined requirements to align with known scope for budgeted programs when possible via

NERP.

Figure 3.6-1 (U) NERP Processes and Artifacts by Requirements Layer

(U) The NERP processes provide the following:

• Perform needs and requirement analysis to validate needs; establish baselines and allocate requirements; ensure baseline traceability; conduct analysis of alternatives and identify courses of action; and ensure baseline integration and normalization (Figure 3.6-1).

• Perform requirement analysis to validate needs, establish baselines, and allocate requirements that support national strategy and NGA strategic objectives and guidance.

• Ensure requirements management through CM controlled governance processes and procedures.

• Support program analysis to interpret strategic and enterprise requirements for implementation.

Figure 3.6-2 (U) NERP Processes

3.7 (U) Risk, Issue, and Opportunity Management

(U) Risk, Issue, and Opportunity (RIO) management is the identification, assessment, and prioritization of RIOs followed by the coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities. Risk management’s objective is to assure uncertainty does not deflect the endeavor from the project goals.

(U) NGA utilizes a tiered approach built on DoD and industry standards to manage RIOs, (Figure 3.7-1), as further detailed in the Information Technology Risk Management Process (ITRMP). The responsibilities for managing risks are shared throughout the agency from the highest levels of executive leadership to managers executing program and project activities. This layered approach empowers management at various levels to develop right-sized plans, processes, procedures, and tools with the goal of managing RIOs at the lowest possible level. Each level should include an escalation process to the next higher level.

(U) Tier 1…