(U) Annex_E_Lifecycle_Guidance_v5.0.pdf

UNCLASSIFIED

ANNEX E:

LIFECYCLE GUIDANCE

Version 5.0

30 September 2016

Annex E – Lifecycle Guidance

Annex E Lifecycle Guidance_v5.0 ii

(U) TABLE OF CONTENTS

(U) Section Description Page

(U) TBD/TBR ............................................................................................................................................ iv

(U) Revision Summary .............................................................................................................................. iv

(U) Glossary of Abbreviations and Acronyms ............................................................................................v

1.0 (U) Executive Summary

2.0 (U) Introduction

2.1 (U) IT Transformational Overview

2.2 (U) CIO-T Operating Model

2.3 (U) Integrating Framework

2.4 (U) Operational Principles

3.0 (U) Key Transformational Lifecycle Changes

3.1 (U) Requirement Process Transformation

3.1.1 (U) Operational Principles

3.2 (U) DevOps

3.2.1 (U) Program Level

3.2.2 (U) Agency Level

3.2.3 (U) Community Level

3.3 (U) Exploration and Experimentation

3.3.1 (U) Operational Principles

Appendix A – (U) CIO-T Operating Model Lifecycle Phases

A-1 (U) Strategic Guidance & Integrated Strategic Planning

A-2 (U) Integrated Solution Planning

A-3 (U) Integrated Execution

A-4 (U) Integrated Support to Operations

A-5 (U) Capability Projects iii

(U) TABLE OF ILLUSTRATIONS

(U) Figure/Table Description Page

Figure 1: (U) NGA’s Transformation Initiatives

Figure 2: (U) CIO-T Operating Model Phases

Figure 3: (U) Scaled Agile Framework 4.0

Figure 4: (U) Scaled Agile Framework 4.0 – CIO-T Mapping

Figure 5: (U) Annual Strategic Process

Figure 6: (U) Acquisition Lifecycle

Figure 7: (U) Functional Decomposition and Infrastructure Sizing

Figure 8: (U) Interactive and Incremental Requirements Process

Figure 9: (U) Dev Ops at Three Levels

Figure 10: (U) DevOps at the Program Level

Figure 11: (U) DevOps at the Agency Level

Figure 12: (U) DevOps at the Community Level

Figure A.1: (U) Integrated Strategic Planning Phase

Figure A.2: (U) Integrated Execution Phase

Figure A.3: (U) Integrated Execution Phase

Figure A.4: (U) Integrated Support to Operations Phase

Figure A.5: (U) Capability Project Interaction iv

(U) TBD/TBR

UNCLASSIFIED

TBD/TBR Log

TBD TBR Description

(U) REVISION SUMMARY

Version Revision Date Revision Summary

1.0 12/31/2015 Initial Release

2.0 2/29/2016 Version2

3.0 4/30/2016 Version 3

4.0 6/30/2016 Version 4

4.1 8/4/2016 Updated classification/portion marking based on review to push down to SBU

5.0 9/30/2016 Update to Sect 3.3 Exploration and Experimentation v

(U) GLOSSARY OF ABBREVIATIONS AND ACRONYMS

UNCLASSIFIED

Acronym Description

A2SI Agency Agility Strategic Initiative

ACC Advanced Campaign Cell

AoA Analysis of Alternatives

ART Agile Release Train

ATDD Acceptance-Test Driven Development

BDD Behavior-Driven Development

C2S Commercial Cloud Services

CD Continuous Delivery

CIA Central Intelligence Agency

CIO-T Office of Chief Information Officer and IT Services Directorate

CONOPS Concept of Operations

CORE Consolidated Operations Research Explorer

CP Capability Project

CPM Capability Project Manager

DoD Department of Defense

GIAT Geospatial Intelligence Advancement Testbed

GS GEOINT Services

GSM GEOINT Solutions Marketplace

IAE Integrated Analytic Environment

IC Intelligence Community

IT Information Technology

JIE Joint Intelligence Environment

MIB Mission Integration Board

MSA Major System Acquisition

MUG Mission Users Group

NGA National Geospatial-Intelligence Agency

NSG National System for Geospatial Intelligence

O&S Operations and Support

PIB Portfolio Integration Board

PL Project Lead

PM Project / Program Manager

PMI Project Management Institute

POM Program Objective Memorandum

POR Program of Record

QA Quality Assurance

SAFe Scaled Agile Framework

SE&I Systems Engineering and Integration

SEP Systems Engineering Plan

VPC Virtual Private Cloud

WIP Work in Process

1.0 (U) EXECUTIVE SUMMARY

(U) This Annex describes the cloud-enabled transformational changes to the NGA Information

Technology (IT) lifecycle and provides guidance to both the organization and development engineers.

(U) This NGA Lifecycle Guidance is to document and assist in the evolution of the processes, prac-tices, culture and tools that define the governance, execution and sustainment of NGA’s IT operational baseline. This lifecycle guidance identifies the Scaled Agile Framework (SAFe®) 4.0 framework as the integration mechanism for NGA transformation and conformance and is discussed in Section 2.3.

(U) Lifecycle Guidance, Annex E of NGA Cloud Guidance, is for enterprise organizations and in-dustry partners as related to the governance and execution of the NGA IT lifecycle. This guidance is ex-pected to continue until the NGA Systems Engineering Plan (SEP) is released late 2016.

(U) A summary of this guidance is:

Follow the CIO-T Operating Model

Use DevOps

Utilize Dew Point for Exploration and Experimentation activities

2.0 (U) INTRODUCTION

(U) NGA seeks to become an open agile enterprise to be more responsive to its customer needs.

Openness initiatives include the migration to a horizontal service-based architecture and the institution-alization of new processes, such as GEOINT Solutions Marketplace (GSM). Agility initiatives include the adoption of the SAFe, cloud migration and the introduction of new contract constructs such as buy-ing development capacity through fixed-priced sprints.

(U) This Lifecycle Guidance v5.0 describes the enterprise-level approach to open and agile IT lifecycle management at NGA. It includes principles, processes, governance and policies that enable

NGA to transform into the supplier of choice for GEOINT services and solutions to the IC and DoD.

(U) The overall goal of this Guidance document is to promote, inform and steward the transfor-mation of the NGA enterprise through the embrace of new IT processes and practices to include an agile requirement process, an increased delivery cadence, DevOps framework and an emerging exploration and experimentation environment called Dew Point.

2.1 (U) IT Transformational Overview

(U) This lifecycle guidance is part of the Open/Agile enterprise transformation guidance set, enu-merated in Figure 1 below, includes planning guidance (cloud strategy, Tier 1 schedule, etc.) and design guidance (IaaS/PaaS/SaaS, new development stacks, etc.), and leverages and aligns to other NGA trans-formational initiatives such as the Agency Agility Strategic Initiative (A2SI), the GSM, FastTrak efforts, and the CIO-T Operating Model.

Figure 1: (U) NGA’s Transformation Initiatives

(U) NGA is currently pursuing four concurrent operational transformations: mission, cloud, agile, and governance. These transformations are discussed here to provide context and alignment to the lifecycle.

(U) Mission – Mission transformation relates to increasing NGA’s value proposition in light of the need to rapidly respond to the user community’s geospatial needs and apply the growing GEOINT com-mercial marketplace. GEOINT services have become ubiquitous in the government and commercial communities. Users have access to orders of magnitude more GEOINT data than ever and the commer-cial market place is moving towards providing more through small/micro-satellites. These small/micro-satellites provide readily deployable multi-spectral, persistent commercial-based GEOINT services. It is expected that given the financial scale of the commercial play, the GEOINT market will be driven to provide GEOINT analysis and faster response times. The scope of commercial ventures has a profound impact on NGA’s value proposition and concept of operations.

(U) Cloud – Cloud is both an integrating fabric and an IT fabric. As an integrating fabric, the cloud enables community-integrated missions as demonstrated by the IC Advanced Campaign Cell (ACC). It also enables the realization of processing and analytical concepts as those being pursued by the DNI

Mission Users Group (MUG) campaigns and the restructuring of NSA’s ongoing Major System Acqui-sition (MSA) efforts.

(U) Cloud intrinsically makes NGA more agile by providing an on demand, elastic IT capability and by mitigating the up-front IT investment barriers. This fiscal flexibility increases the set of industry players that can be leveraged and provides for a larger set of new ideas that can be piloted without much cost and/or risk through environments such as Dew Point. Dew Point is a cloud-based data science solu-tion whose architecture is configurable (e.g., scripts) such that a project can adopt or adapt it, then de-ploy it to support their own services and workloads within this architecture.

(U) Agile – The agile movement increases the flow of capability delivery where capabilities are de-livered faster and in a more continuous manner. The degree of enterprise agility can be categorized in three levels:

1. Agile software development: This level relates to the application of agile techniques (e.g., scrum, extreme programing, SAFe team level, etc.) to the software development process. NGA has adopted variants of the SAFe as its agile development approach and has piloted it in various pro-grams and efforts.

2. Agile Systems Engineering and Integration (SE&I): This level relates to the application of scala-ble agile techniques such as SAFe (i.e., program and portfolio levels) to integrate programs and efforts. NGA has demonstrated this level in the Integrated Analytic Environment (IAE) effort where various activities were integrated to deliver a set of capabilities in an agile way. NGA has pioneered some agile contract techniques to augment PORs and create new buying patterns al-lowing the purchase of services and capabilities in a more granular fashion.

3. Agile Enterprise: This level relates to the institutionalization of agile practices in the enterprise.

This may require new buy patterns, new contracts constructs, material and non-material practice changes, human capital alignments, etc. NGA is effecting this transformation through the

Agency Agility Strategic Initiative (A2SI).

(U) Governance – NGA is undergoing change in its governance structure. That NGA is driving the enterprise through the Portfolios is a-work-in-progress. The portfolios’ roadmaps and schedules focus on planning and needs. These areas are being worked in unison to formulate the coherent financial and pro-grammatic plan for the delivery of the desired capabilities

2.2 (U) CIO-T Operating Model

(U) Purpose: NGA’s CIO-T Operating Model provides a fast, flexible, synchronized process for

CIO-T to deliver solutions. The Model works end-to-end to integrate strategy, solution, execution, and operations support. It brings in the best solutions available. It helps CIO-T engage users throughout the process to be more responsive to their needs and ultimately deliver the capabilities needed to achieve their mission.

(U) Overview: The CIO-T Operating Model is a framework that defines how CIO-T will deliver ca-pabilities and outcomes in a repeatable, systematic way based on predictable planning horizons. The Op-erating Model aligns to the CIO-T Guiding Principles and focuses on collaboration at every level, continuous engagement with both users and the IT marketplace, and prioritized speed of delivery orga-nized around capability projects that span concept to disposal. Four situational issues drove the CIO-T transformation:

1. Organizational Disconnection: Need to integrate and manage the flow from strategy to delivery.

Processes need to be universally followed.

2. Timeliness: Customers say that it takes too long to deliver capabilities. CIO-T was taking too much time to build and implement solutions.

3. Custom Builds: Rather than making use of others’ advances (reuse), CIO-T spent an undue amount of time and resources providing custom solutions.

4. Inaccurate POM Requests: Some requirements are pursued with insufficient research. Technolo-gies need to be properly vetted. POM requests can be off-target, directing resources to the wrong activities, and may not lead to sustainable solutions.

(U) Lifecycle Phases: The CIO-T Operating Model lifecycle is organized in phases from the time a capability is requested to the time a capability is deployed in the NSG, as depicted in Figure 2:

Integrated Strategic Planning (Orange quadrant)

Integrated Solution Planning (Green quadrant)

Integrated Execution (Blue quadrant)

Integrated IT Operations (Brown quadrant)

(U) All phases are broken down into activities. Activities are broken down into subordinate steps performed by a sin-gle function. Functions are aligned to CIO-T organizations.

There is a functional overlay that describes the steps per-formed within an activity.

(U) The CIO-T Operating Model is a framework to visu-alize and understand how work collaboratively happens. The

Model’s phases are defined as follows:

Strategic Guidance is the high-level strategic direc-tion received from Agency and Community leader-ship. It takes the form of future visions, strategic plans, Agency-level priorities, and Department of De-fense and Intelligence Community mandates.

Integrated Strategic Planning translates Guidance into projects through concepts of operations, business cases, and the understanding of market trends.

Integrated Solution Planning gives projects detail by defining capabilities, planning acquisition, and integration into the architecture.

Integrated Execution delivers solutions and capabilities by executing on project plans and man-aging the change to the enterprise.

Integrated Support to Operations provides ongoing maintenance, support, and retirement of solu-tions.

(U) Appendix A – CIO-T Operating Model Lifecycle Phases provides a more detailed definition to the lifecycle phases of the CIO-T Operating Model and a capability projects discussion.

(U) End-to-End Projects: provide mission capabilities to perform either a technology’s added-value or satisfy a timely mission user need.

FastTrak is a rapid deployment process intended to bring capabilities and applications quickly to users. FastTrak doesn’t circumvent the Operating Model, it is intended to support the rapid inser-tion of analyst tradecraft and new methods. Once acquired through FastTrak, capabilities can be scaled up and supported by the enterprise by using the Model.

Capability Projects and Operational Mission Threads continually bring consequential capabilities to our customers. They extend through all of the phases and provide continual feedback from us-ers. The capability projects drive end-to-end integration of the Operating Model.

(U) Core Elements: The CIO-T Operating Model is built around Users and the GEOINT Solutions

Marketplace (GSM). The Users are NGA’s customers and their mission needs. NGA's customers require a broad range of services, including the delivery of geo-referenced imagery and data, Foundation

GEOINT products and services, and intelligence analysis. Increasingly, many customers operate on dra-matically reduced timelines, driving a need for persistence - collection at the speed of the observable -from multiple sources. The GSM is a collaborative and transparent online ecosystem that bridges the gap between NGA and solution providers in industry and academia. The core elements effect on the Operat-ing Model are as follows:

Figure 2: (U) CIO-T Operating Model

Phases

Users are at the center of the Operating Model. Users provide feedback, give insight into evolv-ing needs, and prioritize capabilities. User engagement is critical to continuous improvement.

Users are what drive the Model, keeping CIO-T focused on the mission.

GEOINT Solutions Marketplace provides broad capability and solution options from industry, academia, and other government agencies. Here, best practices and innovations come together in a sandbox environment to share insights and influence new solutions.

(U) The Operating Model is an end-to-end process, not serial. It contains on-ramps and off ramps that will differ depending on the needs of each project. Projects don’t have to begin from scratch to run through the Model. For example, existing background documentation from prior projects can be reused.

(U) The Model guides the accurate and rapid delivery of capabilities. It synchronizes strategy and development to provide greater efficiency, better use of resources, and unifies our support to customers.

It helps CIO-T make POM requests that are on-target and meet specific, well-understood needs. It fo-cuses on the user and embraces innovation from the marketplace. It embodies the flexibility to manage changing priorities and resource constraints.

(U) In its entirety the Operating Model is intended to balance structure and agility, standards and re-sponsiveness, and scalability and speed. It gets us away from the tyranny of the urgent, and helps us in-vest in important resources in the future. It gets us back to the GEOINT basics, back to what we’re good at doing.

2.3 (U) Integrating Framework

(U) NGA has adopted the Scaled Agile Framework (SAFe). This framework as shown in Figure 3 will serve as the integrating fabric to align the Operating Model, DevOps and many process and cultural changes. The following sections map to the SAFe framework and show how the topics integrate via the

NGA-accepted SAFe 4.0 framework.

(U) SAFe V4.0: The SAFe 4.0 framework addresses mostly the material aspects of the enterprise and has four levels of abstraction mapped to NGA’s efforts as follows:

1. SAFe Portfolio level: The SAFe portfolio level corresponds with the NGA enterprise where re-quirements are baselined. Enterprise epics are built at this level.

2. SAFe Value Stream level: The SAFe Value Stream level maps to NGA portfolios constructs.

Where groups of efforts providing a given value to the enterprise are managed (Analytic, con-tent, etc.).

3. SAFE Program level: The SAFe Program level maps to NGA programs.

4. SAFe Team level: The SAFe Team level maps to the development effort supporting a program.

Figure 3: (U) Scaled Agile Framework 4.0

(U) CIO-T Mapping: The CIO-T model maps to the SAFe 4.0 framework as shown in Figure 4 be-low in the following lifecycle phases:

1. Integrated Strategic Planning: Integrated Strategic planning maps to the SAFe 4.0 portfolio level were strategic guidance is decomposed and aligned into value stream epics and capabilities.

2. Integrated Solution Planning: Integrated solution planning maps to the SAFe 4.0 value stream level where value stream epics and capabilities are decomposed into program epics and features and assigned to agile release trains.

3. Integrated Execution and Operations (DevOps): Integrated Execution and Operations maps to

SAFe 4.0 program and team levels where features are decomposed into user stories. The CIO-T model follows SAFe such that both integrated execution development and operations teams sup-port the DevOps structure.

Figure 4: (U) Scaled Agile Framework 4.0 – CIO-T Mapping

(U) DevOps Mapping: As mentioned previously, DevOps practices are implemented at multiple lev-els of a large enterprise such as NGA. In the SAFe model, program-level DevOps practices are imple-mented at the SAFe Program level by Agile Release Trains. Agency-level DevOps practices are implemented at the SAFe Portfolio and Value Stream levels.

(U) The NGA DevOps strategy recognizes that a successful enterprise DevOps implementation re-quires an approach that focuses on changes at three different levels:

1. (U) Program

– DevOps at the program level is concerned with implementing practices and tools to stream-line the continuous delivery (CD) pipeline for a single development program to increases the flow of mission capabilities to users.

(U) Outcome: Define the common NGA DevOps patterns and control points.

2. (U) Agency

– DevOps adoption at the Agency level addresses institutionalizing DevOps principles, culture, roles and responsibilities, and processes across the agency, but more specifically focuses on integration activities between programs, release trains and value streams.

(U) Outcome: Expand the DevOps process and principles to the enterprise level to ensure integration and realization of solution/function delivery in support of a value stream. Institute DevOps as a desired enterprise development pattern including refactoring of enterprise functions such as requirements, con-figuration management, etc.

3. (U) Intelligence Community

– DevOps at the community level relates to NGA’s implementation of DevOps practices and tools in the context of its role as both a producer and consumer of technology-enabled ser-vices within the cloud-enabled mission ecosystem of the Intelligence, Defense, and Civil government communities.

(U) Outcome: Leverage Community development resources (e.g., DevOps Factory, DI2E, GEOINT

Services, etc.) and rapidly develop interoperable and reusable services within the Community mission ecosystem.

(U) Enterprise related Lifecycle Processes

(U) NGA, as all large enterprises, has a lifecycle business process for various aspects of its business operations. These agency lifecycle processes (Strategic, Acquisition, POAM, etc.) must align to the IC and DoD enterprise lifecycle constructs. The NGA engineering lifecycle must align to two key enter-prise processes, which are the Annual Strategic Process and the Acquisition Lifecycle, as shown in Fig-ure 5 and 6 below. These processes are not the subject of this discussion, they are included for completeness and reflect the enterprise connection to the topics discussed herein.

Figure 5: (U) Annual Strategic Process

(U) The strategic process seeks to realize the NGA GEOINT 2022 CONOPS1 through the continued evolution of the NGA priorities, planning guidance and portfolio guidance. The CIO-T model aligns and enables the enterprise strategic process mostly through the evolution of the baselines managed at the

SAFe portfolio and program levels.

(U) The NGA acquisition process is being adjusted to increase its agility and ease of use. Examples include the purchase of Agile sprints through fixed price vehicles and increased use of broad instruments such as GSA mechanisms. In addition, a buy-versus-build mindset is being promulgated across the en-terprise with initiatives such as the GEOINT Marketplace and Pathfinder efforts. In addition, acquisition is facilitating instruments that support more agile-accommodating contract vehicles.

Figure 6: (U) Acquisition Lifecycle

(U) The acquisition lifecycle shown above in Figure 6 directly aligns to the CIO-T Operating Model, and supports increased agency agility and leverages industry technology.

2.4 (U) Operational Principles

(U) Implement the CIO-T Operations Model

(U) Implement SAFe 4.0 for Lean Software and Systems Engineering as the integrating frame-work that allows the organization to use the Operations Model and DevOps

(U) Operate within the overarching lifecycles of the IC and DoD

3.0 (U) KEY TRANSFORMATIONAL LIFECYCLE CHANGES

1 The NGA GEOINT 2022 CONOPS is the description of a broad application to the whole GEOINT mission, vice solving a specific mission need.

https://go.ic.gov/lYJkfwU

3.1 (U) Requirement Process Transformation

(U) One of the most affected areas of the engineering lifecycle is the requirement process. While there are expected changes at the enterprise and portfolio requirement process level this document will focus on the transformation happening at the program level.

Figure 7: (U) Functional Decomposition and Infrastructure Sizing

(U) In general, the program requirement process is focused on two objectives: 1) functional decom-position and 2) infrastructure sizing. Both of these areas are being transformed, as shown above in Fig-ure 7 from Waterfall to Agile, a significant departure in construct.

(U) Functional decomposition seeks to decompose the high level program requirements into specific testable requirements. In the waterfall legacy lifecycle this is usually accomplished all at once through hierarchical decomposition analysis that usually lasts 3 to 6 months for most programs. Once this is ac-complished and reviewed, the requirement baseline is established for the program. As shown below in

Figure 8, the agile process is based on the SAFe framework that uses an interactive and incremental re-quirements process. For most efforts NGA is moving from a waterfall to agile lifecycles; and, as such from design, develop, test, operate to an incremental design/develop/test/operate.

Figure 8: (U) Interactive and Incremental Requirements Process

(U) Infrastructure sizing is the process focused on sizing both the software and hardware resources so they can be purchased and setup in the selected data center. Historically, at NGA this process takes about 9 to 12 months and involves multiple organizations with infrastructure design, build, and opera-tions functions. The cloud pay-for-use model has changed this process. While the programs are required to do an initial cloud resource estimation, programs can instantiate development resources in the cloud from day one. In addition, the use of the cloud elastic computing can reduce the cost incurred. Through the use of elastic computing, the need for more capacity can be achieved on demand and the only pay-for-use factor greatly reduces the actual operating costs.

3.1.1 (U) Operational Principles

(U) Transform the requirements process from waterfall to agile and from system to cloud

(U) Focus requirements on two objectives: 1) functional decomposition and 2) infrastructure siz-ing

3.2 (U) DevOps

(U) DevOps is an evolution of agile development, where small batches of code are developed, inte-grated, tested, and deployed in frequent, short cycles utilizing software development best practices, and cultural and organizational barriers between applications developers and IT operations personnel are re-duced to increase the pace and efficiency of deploying software updates to users. This is in contrast to traditional development approaches which revolved around large batches of requirements that resulted in sequential, large batch handoffs between requirements definition, software design, software test and ver-ification and deployment to operations, ultimately leading to significant delays, high rates of defects, and high program risk. The lower complexity of small changes minimizes the risk to operations and in so balances the scales between the ever changing needs of the development environment with the per-petual stability needed in an operational environment.

(U) DevOps is a significant paradigm shift which impacts culture, processes, people, and tools at multiple levels of the enterprise. Guidance version 3 is primarily focused on program and team level practices and tools. Developers are the primary users of Continuous Delivery tools and practices. Gov-ernment Product Managers, Product Owners, and Release Managers will be responsible and accountable for ensuring that prescribed DevOps guidance is followed. Users will receive the benefits of rapid capa-bility deliveries by working closely with development teams, test teams, security engineering teams, and

IT operations teams.

(U) Annex E provides the guidance for how NGA will adopt and execute a DevOps methodology to accelerate the "time to market" of ideas into operational software capabilities in support of national secu-rity. Adoption of DevOps at NGA will increase its business agility. In executing DevOps, NGA will re-alize a transformation of software development and IT operations. Embracing this construct will yield savings in time and funds for development, efficiencies for personnel performing in the agile construct, and customer satisfaction with earlier deployment of higher quality software and services.

(U) DevOps adoption is about more than just adopting new technical tools. In order to realize the im-provements in IT Operations performance and GEOINT mission performance that NGA seeks, pro-grams must adopt the DevOps culture, embrace lean and agile management practices, and implement

Continuous Integration (CI), Test Automation, and Continuous Delivery (CD) tools and practices in their development environments.

(U) This Annex outlines an agile and decentralized approach to governance at the lowest level that enables development, security engineering, and IT operations teams to collaborate together efficiently and minimize delays and barriers to deploying working software frequently. It also outlines NGA’s guidance for provisioning, adopting, and/or maintaining the CI/CD/Test Automation tools that enable

DevOps, and provides a measurement framework for assessing the maturity of programs implementing

DevOps practices to assist them in their continuous improvement efforts and to identify and resolve en-terprise impediments that inhibit program agility and value delivery.

(U) Adoption of the DevOps construct has essentially begun with NGA’s use of the SAFe methodol-ogy. DevOps adoption within NGA is the 3-level construct (i.e., Program, Agency, and Community) noted in Section 2.3. Implementation will occur as NGA moves to the cloud and will continue to mature into normal engineering and business processes by the time NGA completes the move to the cloud in

December 2017.

(U) Figure 9 below shows the relationships of the 3 levels from capability development at the pro-gram level, through the Agency Portfolio level, to the Community level where NGA is both a member and a contributor of integrated capabilities. This figure is described in detail in the following section.

Figure 9: (U) Dev Ops at Three Levels

(U) Why Adopt DevOps?

(U) NGA can accelerate the time required to deliver new capabilities or update existing capabilities by embracing DevOps practices. Whether developing new, original software code or integrating COTS or GOTS software applications or services, adoption of DevOps practices and tools can help NGA soft-ware adoption and delivery activities to increase their efficiency, delivery pace, quality, and fit for pur-pose, while reducing delays, defects, and program risk. As an integral part of the overall CIO-T transformation, DevOps adoption requires commitment from across the NGA enterprise to changes that span people, process, and technologies. Core tenets of the DevOps paradigm include the following:

Culture: People and process, organizational alignment and responsibilities

Automation: Technology and tools to accelerate key tasks and reduce errors

Lean: Utilizing lean, flow-based management practices, including decentralizing decision-mak-ing and visualizing and managing Work In Progress (WIP)

Measurement: Situational awareness and process insight through metrics

Sharing: Establishing feedback loops and enabling collaboration and reuse

(U) The shift in to DevOps is not without cost and some level of risk in the transition. It requires a culture change from NGA’s approach to engineering. Waterfall development has given way to agile.

Culture change is more than engineering, development, test, and deployment changes occurring within

CIO-T; it includes all programs, all portfolios, and extends into the IC for integration of all programs in support of national defense. Key improvements that will be realized include:

New mission capabilities arrive more quickly at less cost with far fewer defects due to the con-tinuous testing, integration and delivery

Increased efficiency of fielding new capabilities and reduce waste

Increase mission utility and mission user satisfaction through fast user feedback

Multi-INT mission capability integration in the IC ITE ecosystem

UNCLASSIFIED

“Getting to a DevOps agile development probably is the primary driver” for transforming the NGA Information Technology Services Directorate.

Doug McGovern, D/CIO-T, Signal Magazine, April 1, 2016

(U) Implementation Strategy

(U) It is NGA’s goal to fully embrace DevOps by October 2016 and to contribute fully to the imple-mentation and evolution of DevOps in the intelligence community. NGA’s implementation approach is an enterprise-wide roll-out and requires a broader implementation strategy that includes the 3 levels

(Program, Agency, and Community) previously discussed. The implementation will be initiated by learning with a few programs already applying DevOps principles and practices. Then, expanding im-plementation of DevOps principles and behaviors to existing programs as appropriate; and, to all new acquisition program starts in the future. Measures of progress will be identified early and continuously captured as NGA matures DevOps implementation. These measures will demonstrate where improve-ments and efficiencies are being realized, as well as drive out refinement to the DevOps implementation.

The following sections will introduce and discuss each of the Program, Agency and Community levels.

A “crawl, walk, run” approach will be identified for each level, along with supporting tasks/actions that are required to support NGA’s approach.

3.2.1 (U) Program Level

(U) Definition

(U) DevOps at the program level as shown in Figure 10 is concerned with implementing practices and tools to streamline the continuous delivery (CD) pipeline for a single development program. NGA programs will utilize a CD pipeline that rapidly and continuously promotes new software code through four stages. Program implementation requires support from key enterprise functions, such as require-ments management, configuration management, IT security, architecture, quality assurance/IV&V, and others. In the DevOps paradigm, some of this support may be provided via dedicated personnel or cross-functional teams assigned directly to the ART, while some will be provided by standing enterprise func-tional teams and working groups operating in an integrating role. An ART will normally have a single

CD pipeline, but in certain cases, such as in the case of a program with teams supporting multiple prod-ucts with different or independent technical architectures, an ART may have multiple CD pipelines.

Figure 10: (U) DevOps at the Program Level

(U) For the purpose of this discussion, the term “program” is used here in a broad, general sense, as defined by the Project Management Institute (PMI)2. The intent is to refer to a cohesive, standing organi-zation of software development and sustainment teams, without regard for the contractual or financial arrangements for procuring these teams.

(U) It is further stipulated for the purpose of this discussion that the default organizational model for a software program is the SAFe Agile Release Train (ART). Implementing DevOps requires first achieving a measure of proficiency and maturity in implementing team-level agile practices such as

Scrum, XP, or Kanban, and at a larger scale, requires application of multi-team agile patterns for scaling these practices such as the SAFe ART. Programs that are not implementing a SAFe ART model or a similar organizational pattern for scaling multi-team agile development are unlikely to realize the bene-fits of implementing DevOps practices.

(U) Intent

(U) The intent is to achieve three key goals:

1. Normalize a core set of common DevOps processes, tools, and behaviors across NGA programs

2. Institutionalize execution of key enterprise functions in support of programs implementing

DevOps practices

3. Specify and manage the minimum set of control points necessary to ensure streamlined govern-ance, enable rapid, decentralized decision-making, and realize the benefits of DevOps tools and practices

(U) Tasks

(U) The implementation strategy for DevOps at the program level is focused on two major activities:

1) collaborative engagement with a subset of NGA software development activities currently imple-menting DevOps practices to elicit lessons learned, effective practices, and pilot proposed guidance, and

2) providing guidance to enable upcoming new-start programs to operate from day one using NGA’s normalized program DevOps tools and approach.

1. Establish default program CI/CD technical architecture (aka “DevOps toolchain”):

a. Establish a list of trusted/vetted tools and identify procurement guidance for CI/CD/Test Au-tomation infrastructure tools3

i. Maximize economies of scale for procurement of CI/CD/Test Automation software tool licenses, including opportunities to leverage Community managed infrastructure

b. Develop guidance for tool configuration

c. Approach for continuous monitoring – application performance/state of health, security per-formance, and business analytics

2. Develop and implement a program-level measurement framework for programs implementing

DevOps tools and practices:

a. Survey pilot/pathfinder programs to identify measures and metrics currently being collected and reported

2 “A program is a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually.” PMI PMBoK, fifth edition, 2013 3 DevOps tools listing is maintained in the NGA Cloud Information Portal ‘s Cloud Services Catalog.

https://intelshare.intelink.ic.gov/sites/nga-cloud/Cloud%20Wiki/Cloud%20Services%20Catalog.aspx https://intelshare.intelink.ic.gov/sites/nga-cloud/Cloud%20Wiki/Cloud%20Services%20Catalog.aspx

b. Develop and iteratively refine a program-level maturity model focused on program and team practices, and collaborate with DevOps pathfinder programs to conduct regular self-assess-ments concurrent with program Inspect & Adapt rhythms

c. Develop and track IT performance measures (e.g., lead time, deployment time, deployment frequency, deployment success, test automation, defect density, time to correct defects, MTTR, system stability, etc.)

d. Develop and track mission/business value delivery metrics (user net promoter scores, mission performance metrics)

3. Develop program-level guidance:

a. Define and manage a set of program-level control points to enable streamlined governance and decentralized decision making

b. Define the template for support to ARTs by key enterprise functions: configuration manage-ment, IT security, QA/IV&V, requirements management, architecture, etc.

c. Define key government and industry roles and responsibilities in program execution under a

DevOps paradigm

d. Systematically identify, prioritize, track, and resolve enterprise impediments to program-level continuous delivery

e. Recommend contractual language for program DevOps

4. Organizational development activities. While the most significant organizational development activities are at the agency level, a few tasks are required to drive the program-level changes in practices, tools, and culture.

a. Define and implement a strategy to evolve program culture.

i. Leader development. Shifting to a DevOps culture requires a systematic approach to training NGA senior and mid-level leaders responsible for program execution in lean flow-based management practices

ii. Workforce training. Government and contractor personnel responsible for implementing

DevOps tools and practices require training in these practices

(U) Roadmap

(U) Crawl: In the “crawl” stage, program level DevOps implementation is focused on successfully implementing CI/CD practices on two or more Agile Release Trains operating independently, measuring key practices and outcomes, identifying effective practices and desired control points, and implementing

DevOps “First Way” practices associated with managing flow. In the “crawl” stage pilot/pathfinder pro-grams will demonstrate the following behaviors and outcomes:

Programs track and report measures against a common measurement framework, addressing met-rics related to process maturity, process execution, software quality, system performance, user satisfaction, and mission performance. Programs conduct periodic self-assessments against an

NGA DevOps maturity model

The technical architecture for the program CI/CD pipelines (“DevOps toolchain”) are docu-mented

Programs have implemented basic Test-Driven Development practices

Programs have implemented a production-equivalent staging environment and are deploying working code to staging at least once every iteration/sprint

Programs produce potentially shippable software every iteration/sprint

Programs visualize and manage work In Progress (WIP) at the ART level using the SAFe pro-gram level Kanban system

Programs implement ART-level Inspect & Adapt rhythms, share key DevOps lessons learned, implement process improvement tasks in their program backlogs, and resolve or elevate impedi-ments related to DevOps to the DevOps Roundtable

Programs hold regular engagements with business/mission owners to solicit actionable feedback on feature priorities, program roadmap, and demonstrations of working software products

(U) Walk: In the “walk” stage, NGA will shift focus toward normalizing the DevOps approach across programs, synchronizing development and delivery across two or more ARTs within a value stream, progressing the maturity of program DevOps practices to at least maturity level 3, and imple-menting DevOps “Second Way” practices to optimize feedback. In the “walk” stage pilot/pathfinder programs will demonstrate the “crawl” level behaviors plus the following additional behaviors and out-comes:

A standard technical architecture for program CI/CD pipelines (“DevOps toolchain”) is defined and available to all NGA programs

Programs have demonstrated growth in overall maturity to an average of Level 3 across all meas-ured activities in the NGA DevOps maturity model through a systematic application of the meas-urement framework and consistent process improvement through the ART-level Inspect & adapt rhythms

Programs have implemented Acceptance-Test Driven Development (ATDD) or Behavior-Driven

Development (BDD) practices

Programs produce potentially shippable software every iteration/sprint and are able to deploy to an NGA production environment on demand

Program cadences are aligned and synchronized with other ARTs in the same value stream. Pro-grams participate in solution demonstrations from a value-stream-level production-equivalent staging environment

Program backlogs, roadmaps, and release plans are aligned and synchronized with the value stream-level solution backlog, roadmap, and release plan

Programs are implementing NGA DevOps lifecycle guidance with governance according to a limited set of well-defined control points

All NGA new-start programs are implementing DevOps tools and practices according to NGA

DevOps lifecycle guidance

(U) Run: In the “run” stage, NGA will focus on increasing the number of programs implementing

DevOps tools and practices, advancing the maturity of program DevOps practices to levels 4 or 5, and implementing DevOps “Third Way” practices to drive experimentation and innovation to improve

GEOINT mission outcomes and advance the tradecraft. In the “run” stage programs implementing

DevOps practices will demonstrate the “walk” level behaviors plus the following additional behaviors and outcomes:

Programs habitually execute their Inspect & Adapt and continuous process improvement rhythms and have demonstrated growth in overall maturity to an average of Level 4 or 5 across all measured activities in the NGA DevOps maturity model

Programs have fully automated the creation of development, test, and staging environments

Programs have fully automated the deployment process

Programs are implementing hypothesis-test driven development with frequent user feedback, in-cluding automated, real-time business intelligence

NGA continues to adapt and evolve DevOps lifecycle guidance based on lessons learned, feed-back from programs and value streams, and emerging industry practices and innovations

3.2.1.1 (U) Operational Principles

Implement the continuous delivery (CD) pipeline for two or more SAFe Agile Release Trains

(ART)

Specify and manage a minimum set of control points

Implement a program-level measurement framework

3.2.2 (U) Agency Level

(U) The Agency level addresses DevOps principles, roles and responsibilities, and process across the agency, but more specifically focuses on integration activities between programs, release trains and value streams. The Agency level, as shown in Figure 11 below, will include an enterprise source code repository that supports the integration of code across programs and release trains as necessary to sup-port end-to-end testing and ensure readiness for delivery to operations.

Figure 11: (U) DevOps at the Agency Level

(U) Intent

(U) The intent is to expand the DevOps process and principles to the enterprise level to ensure inte-gration and realization of solution/function delivery in support of a value stream.

(U) Tasks

(U) Implementation of the Agency level for DevOps includes a shift from a program/system focus to an ART focus and implementation. This shift will push alignment and integration at the Agency level.

Below are a list of key tasks to start the implementation approach. Tasks 1 and 2 are provided to include the broader agency level context and are assumed to be in place or will be implemented by agile pro-cesses at the agency level. For the purposes of this DevOps at the Agency level implementation, it is as-sumed that a value stream (e.g., ASC) has been defined and is aligned to the Analysis portfolio.

1. Value Stream Definition – A value stream (or investment system/solution) is the series of steps that an Enterprise uses to provide a continuous flow of value to the customer (i.e., from the con-cept idea through solution delivery). A value stream will be identified and funded by one or more

NGA portfolios.

2. Value Stream Management – The Agency level will include the establishment of Solution Man-ager(s) that will provide the overall leadership and ensure coordination and integration of activi-ties supporting the Value Stream. Additionally, the Solution Manager will work with other

Solution Managers to ensure coordination across value streams as needed.

3. DevOps at the Agency Level – The foundational construct of DevOps at the agency level is real-ized by the establishment and implementation of the Agile Release Train. Specifically, an ART that supports the ASC value stream. DevOps is in integral part of the ART and therefore, in order to move forward with DevOps implementation is critical that an ART is stood up and working as an integrated activity. The ART is an integrated activity with teams from the Program level working with System Architects, Business Owners, System Engineers, Security and Test and the

Product Manager to understand and implement the value stream vision and related Features.

DevOps at the Agency level will support enterprise level integration, testing, security, and re-lease approval/readiness.

(U) The ART is the organizational construct that will realize a value stream. A value stream may be supported by one or many ARTs, depending on the overall size of the effort.

a. Determine approach to train alignment

b. Identify the roles/responsibilities for ART management and execution

c. Identify the monitoring and measuring characteristics of an ART. How will we know if we are successfully delivering value (i.e., solution/functionality to the end user/customer)?

d. Identify and define the shared staging environment. What will it look like and how it will op-erate at the Agency level?

e. Identify the control points where code posted to lower level (program level) repository(ies) are pushed up to the Agency level repository

f. What are the control points at the Agency level?

g. Determine how will visualize and manage WIP at the agency level

h. What tools are needed to support the Agency level DevOps?

i. Identify key leaders in TI/TA/TO/Others that need DevOps/Agile/SAFe training

4. Monitoring/Measuring

a. Measuring performance of the value stream. What will we measure?

b. How will we monitor progress and determine “definition of done” and success?

5. Industry/Government Partnership

a. What are the roles/responsibilities and interactions between the Government and Industry?

b. How will the Government communicate to Industry? What information will the Government communicate to Industry?

c. What support/functions does the Government need Industry to provide?

(U) Roadmap

(U) Crawl: Establishing value stream understanding and communication with NGA portfolios. Re-solving impediments to Programs that are “crawling”. Preparing agency level processes and roles/re-sponsibilities to support “walk” at the Program level. Educating/training key TI/TA/TO/other leaders in

DevOps/Agile, SAFe.

(U) Walk: A minimum of one value stream has been established. Conducting solution demonstra-tions from a shared staging environment. Work in Process (WIP) is managed at the value stream level.

Value Stream roles are established. Government and Contractor personnel are fully trained/qualified.

(U) Run: All NGA portfolios implementing at least one value stream. Robust business intelligence is collected and analyzed and informing refinement and modifications (continuous learning). Real-time performance monitoring is in place.

3.2.2.1 (U) Operational Principles

• (U) Implement an Agile Release Train (ART) construct at the Agency level.

3.2.3 (U) Community Level

(U) DevOps at the community level relates to the DevOps activities and interactions NGA has with the Intelligence, Defense and Civil government communities as shown in Figure 12 below. In these in-teractions NGA has four roles: provider and user of mission capabilities and provider and user of

DevOps capabilities.

Figure 12: (U) DevOps at the Community Level

(U) Intent

(U) The IC ITE and Joint Intelligence Environment (JIE) environments have elevated the mission context from an agency to a community level. These environments support the development and execu-tion of community wide integrated missions such as DNI MUG missions and MSA redesign. In this con-text agencies provide and use each other’s services and functions instead of just providing intelligence products.

(U) It is expected that the current agency level DevOps environments such as DevOps factory, Con-solidated Operation Research Explorer (CORE) and GEOINT Services (GS) will be integrated and/or leveraged with each other to provide a DevOps platform (Gray band in picture above) for emerging community integrated missions and doing in common what is commonly done it. This community level

DevOps capability will evolve…