Attachment J-XX - 2030 Census Systems Engineering Management Plan (SEMP) V1.1 (1).pdf

2030 Census Systems Engineering

Management Plan (SEMP)

July 18, 2024

Version 1.1 i

Approval Signatures

This 2030 Census Systems Engineering Management Plan (SEMP) V1.1 has been reviewed and approved for use.

Barbara LoPresti Chief, Decennial Information Technology Division

Date Signed

Jennifer Reichert Chief, Decennial Census Management Division

Date Signed ii

Document Logs

Sensitivity Assessment

Verification of Document Content

This document does not contain any:

• Title 5, Title 13, Title 26, or Title 42 protected information;

• Procurement information;

• Budgetary information; and/or,

• Personally identifiable information.

Document Author: Nicole Seamands (DITD) Date: June 6, 2024

Review/Approval

Name Area Represented Date

Daniel Doyle Deputy Chief, Decennial Census Management Division 07/11/2024

Ann Wittenauer Special Assistant, 2030 Census Planning 07/11/2024

Deidre Hicks Chief, Decennial Program Management Office 07/11/2024

Brian De Vos Assistant Division Chief, Architecture, Integration, Infrastructure, and Testing

07/11/2024

Nicole Seamands Assistant Division Chief, Systems Engineering 07/11/2024

Version History

Version Date Description

V1.0 10/11/2023 Baseline version sent for signatures.

V1.1 07/18/2024

This aligns the 2030 Census SEMP with the recently baselined 2030 Census Integration and Implementation Plan (IIP), including the Program Level Test Checkpoint (PLTC) as part of the 2030 Census Program Readiness Reviews and Milestones graphic.

iii

Contact Information

The following system team members can respond to inquiries about this document:

Name Role Organization Phone Email

Nicole M Seamands

ADC Decennial Systems

Engineering

Decennial Information Technology

Division

202-302-7677 nicole.m.seamands@census.gov

Kenneth W Walker

Infrastructure Engineering Lead

Decennial Information Technology

Division

301-763-5516 kenneth.w.walker@census.gov

James William Csoka

System of Systems

Architect for Decennial

Decennial Information Technology

Division

301-763-5648 james.william.csoka@census.gov

2030 Census Systems Engineering Management Plan V1.1 iv

Table of Contents

1 Introduction

1.1 INTENDED AUDIENCE

1.2 DOCUMENT MAINTENANCE

1.3 2030 CENSUS PROGRAM

1.4 SYSTEMS ENGINEERING MANAGEMENT PLAN OUTLINE

2 System Engineering Life Cycle

2.1 DECOMPOSITION AND DEFINITION

2.1.1 Key Activities

2.1.2 Key Processes Applied – Decomposition and Definition

2.2 DEVELOPMENT AND IMPLEMENTATION

2.2.1 Key Processes Applied – Development and Implementation

2.3 INTEGRATION

2.3.1 Key Activities

2.3.2 Key Processes Applied - Integration

3 Systems Engineering Management

3.1 INTEGRATED MASTER SCHEDULE

3.2 INTEGRATION AND IMPLEMENTATION PLAN

3.3 OPERATIONAL DELIVERY MANAGEMENT

3.4 SCALED AGILE FRAMEWORK

3.5 TECHNICAL INTEGRATION GOVERNANCE

3.6 RISK AND ISSUE MANAGEMENT

3.7 CHANGE MANAGEMENT

3.7.1 2030 Census Program Change Management

3.7.2 Document Management

4 Engineering Specialty Integration

4.1 SECURITY MANAGEMENT

4.2 AUDITS

Appendix A: Key Stakeholders

Appendix B: Environments and Tools

Appendix C: Referenced Documents

Appendix D: 2030 Census IT Governance Boards v

List of Figures

Figure 1: V-Model Life Cycle

Figure 2: Program Readiness Reviews and Milestones

Figure 3: 2030 Census Program Readiness Reviews and Milestones

Figure 4: V-Model – Activities within the Decomposition and Definition Stage

Figure 5: TOGAF-based Architecture Development Method

Figure 6: Decomposition and Definition Key Processes

Figure 7: Agile DevSecOps

Figure 8: Development and Implementation Key Processes

Figure 9: V-Model – Activities within the Integration Stage

Figure 10: Key Processes – Integration

Figure C-1: 2030 Census Document Relationships

List of Tables

Table 1: IT Governance Boards

Table A-1: Key Stakeholder Responsibilities

Table B-1: Environments

Table B-2: Tools

Table D-1: 2030 Census IT Governance Boards

1 Introduction

The 2030 Census Systems Engineering Management Plan (SEMP) outlines the technical and managerial processes that govern system engineering management activities. This plan provides an interdisciplinary approach encompassing the entire technical development effort to evolve and verify an integrated set of systems, people, processes, and solutions that satisfy customer needs throughout the 2030 Census Program’s life cycle.

A notable aspect of the 2030 Census Program is the intersection of numerous systems, each with their own set of internal and external users. These complex interactions underscore the importance of adhering to proper standards and guidelines, as outlined in this document. The

SEMP is designed to ensure consistency across management and technical activities supporting the 2030 Census.

The SEMP covers various areas such as requirements management and traceability, engineering and architecture, system design and development, technical integration, and other components necessary during the 2030 Census Program’s life cycle. Functioning as a high-level guide, the

SEMP aims to direct an environment and conditions in which a defined set of goals or objectives can be achieved in a controlled manner by a team of people. It incorporates recent advancements in Software Development Life Cycle (SDLC) and engineering processes, enabling adaptable and efficient management, architecture, development, and system integration tailored to the needs of the 2030 Census Program.

1.1 Intended Audience

This document is intended for all those involved in the Architecture, Engineering, Program

Management, and Information Technology (IT) solution development for the 2030 Census, examples of which are listed below:

Decennial Systems Engineering (DSE) and Technology Integration (TI)

Decennial Census Management Division (DCMD)

Decennial Census purpose-built systems

Enterprise Initiatives Business Ecosystem (BE)

Office of the Chief Information Officer (OCIO)

Decennial Contracts Execution Office (DCEO) (contractor-delivered solutions)

Third-party contracted solutions

1.2 Document Maintenance

The DSE, TI, and Security teams in the Decennial Information Technology Division (DITD) are responsible for creating and maintaining the SEMP. This document is reviewed and updated periodically to verify its continued relevance and accuracy.

1.3 2030 Census Program

Mission and Vision: The 2030 Census mission is to conduct a census of population and housing and deliver the data to the President, the States, and the American people. The program’s vision is to conduct an efficient, effective, and quality census that counts the people of our nation, once, only once, and in the right place.

Decennial Census Background: While the Census Bureau administers many censuses and surveys of the U.S. population, commerce, and governments, including the future 2030 Census, the decennial census of population and housing, conducted once every 10 years, is the only one mandated by the United States Constitution. The decennial census is the country’s oldest, most comprehensive source of information about the population. The decennial census provides comprehensive statistical information for the United States and U.S. Territories, including demographic and housing characteristics.

The U.S. government uses the data generated by the census to apportion congressional seats, monitor compliance with civil rights and other legislation, and forecast the number of people eligible for government benefits.

Tribal, state, and local governments use census figures to distribute funds for education and other social programs; determine congressional, state legislative, and voting district boundaries; and predict disaster relief needs.

Island Area governments use decennial census data to access federal funding opportunities, to better understand the characteristics of a changing population, such as age and household composition, and to understand and address emerging needs, such as access to employment, health insurance, and internet access. In addition, decennial census data for the Island Areas of the Pacific and the U.S. Virgin Islands are the sole data source for federal agencies.

Business relies on the data for product development, marketing, demand forecasting, and determination of optimum location sites.

2030 Census Program Life Cycle: During the planning and preparations for the 2030 Census, the

Census Bureau will continue to strive to improve the accuracy of census coverage compared with previous censuses, reduce operational risk, and contain costs, while ensuring the robustness of the design to ensure a quality count. Planning for the 2030 Census began in 2019.

The 2030 Census Program is being conducted in four phases, beginning with Early Planning

(FY19-FY21), followed by Design Selection (FY22-FY24), Development and Integration (FY25-

FY29), and Peak Production and Close-Out (FY29-FY33).

1.4 Systems Engineering Management Plan Outline

The SEMP is organized into three main sections. The SEMP is not all-inclusive. Where applicable, it references documents that provide specific and detailed guidance (e.g., Integration and Implementation Plans (IIPs), System Design Documents).

Section 2 - System Engineering Life Cycle

The System Engineering Life Cycle section outlines a systematic approach to achieving the activities that occur during the various phases of the System Engineering life cycle. This section is organized based on a modified version of the Engineering V-Model, as it depicts a more iterative, agile approach than the traditional model implies. By adhering to this model, the

SEMP can better explain key concepts from conceptualization to deployment – including

Readiness Reviews (RRs), supporting processes, and artifacts. It also describes the differences in roles and responsibilities for all levels of activities (program and project) and their associated

RRs.

Section 3 - Systems Engineering Management

The System Engineering Management section identifies the management strategies and methodologies that guide successful systems engineering. It identifies how the Scaled Agile

Framework (SAFe) is used to manage the System Engineering life cycle and defines and details the role of operational delivery management. It also describes the governance, security, decision-making processes, schedules, and planning that collectively manage the System

Engineering life cycle.

Section 4 - Engineering and Specialty Integration

This section provides details regarding engineering specialties that are integrated with the

System Engineering life cycle. Specifically, this section discusses security protocols and internal and external audit assessments.

2 System Engineering Life Cycle

The 2030 Census Program uses the V-Model approach to navigate the System Engineering life cycle. This approach combines the principles of Agile methodology with the structured and systematic approach of the traditional V-Model. This model is well-suited for the 2030 Census

Program, as it provides a balanced framework for managing complexities, facilitating iterative development, and ensuring seamless integration across varying project elements. The model is designed to be flexible. It accommodates various development methodologies including Agile, Waterfall, and Incremental. These methodologies align to the Census Bureau’s Enterprise

Systems Development Life Cycle (eSDLC).

Figure 1: V-Model Life Cycle

The model consists of three key stages, as shown in Figure 1:

Decomposition and Definition: This stage is depicted on the left side of the V-Model. During this stage, high-level requirements and objectives are decomposed into smaller, more manageable components. These components serve as the basis for solution requirements.

Development and Implementation: This stage is represented by the base of the V-Model. At this stage, solution providers work on building and testing individual components. The V-Model offers flexibility and adaptability, acknowledging the dynamic nature of software development and recognizes that teams may adopt either Agile, Waterfall, or Incremental development practices based on project suitability.

Integration: The final stage, depicted on the right side of the V-Model, is Integration.

Throughout this stage, components developed during the previous stage are integrated and tested as a whole, ensuring they function cohesively and meet the overall 2030 Census Program requirements.

The V-Model encompasses a combination of 2030 Census program-owned and project-owned activities. Program-owned activities are concerned with defining high-level goals, outcomes, the

2030 Census Program vision, and inter-project coordination. Project-owned activities focus on specific deliverables and objectives of a single solution within the 2030 Census Program.

Throughout the execution of the life cycle, the 2030 Census Program conducts RRs and milestone ceremonies. RRs and milestones are structured events that assess the readiness of the 2030 Census Program to proceed to subsequent activities. Figure 2, below, outlines RRs and milestones associated with various activities conducted throughout the V-Model. The RRs and milestones are described in further detail throughout this document.

Figure 2: Program RRs and Milestones

The primary objectives of the RR milestones are to:

• Evaluate readiness to determine whether the 2030 Census Program is prepared and capable of achieving its objectives.

• Identify risks and issues that could prevent the 2030 Census Program from achieving its objectives.

• Provide recommendations for improving the 2030 Census Program's readiness and addressing identified risks and issues.

• Enforce compliance with regulations, policies, and standards.

Figure 3: 2030 Census Program RRs and Milestones

The sequence of RR milestones is illustrated in Figure 3 above.

At Stakeholder Requirements Review (SRR), the business presents stakeholder requirements to the 2030 Census Program. This process continues until all requirements are shared, baselined, and allocated to solution providers. As SRRs occur for each operation, and as the 2030 Census

Program continues to allocate stakeholder requirements, the Solution Architecture Team, in parallel, builds the System of Systems (SoS) high-level architecture designs. This work is on-going until all SRRs are complete, allowing the 2030 Census Program to proceed with the

Critical Design Review (CDR). The CDR is a singular event in which the SoS high-level architecture and supporting artifacts are reviewed and baselined. The solution providers then have all the necessary inputs to identify and refine solution requirements.

As solution providers continue defining solution requirements, iterative Initial Baseline Reviews

(IBRs) occur. Detailed requirements and associated artifacts can then be reviewed, indicating development and implementation can begin. Key milestones after IBR are the Program Test

Initialization Checkpoints (PTIC), Program Level Testing Checkpoint (PLTC), and Test Readiness

Reviews (TRR) that assess the 2030 Census Program’s readiness to start SoS integrated program-level testing.

Once all program-level testing is complete and the SoS has been validated, Production

Readiness Review (PRR) is conducted to allow operational teams to conduct final validation of operational aspects of the SoS. Successful operational readiness testing is the entry criteria for

Operational Readiness Review (ORR), indicating readiness to Conduct Operations (CO).

These milestones are mentioned throughout the SEMP, where applicable, as they relate to the

System Engineering life cycle.

2.1 Decomposition and Definition

The Decomposition and Definition stage of the V-Model, shown in Figure 4, sets the foundation for the 2030 Census Program’s success. By conducting thorough research on customer needs and objectives and breaking down requirements into well-defined measurable capabilities, the

2030 Census Program ensures a clear understanding of the scope and architectural needs of the

SoS.

This stage consists of five activities: Research, Stakeholder Requirements, SoS Architecture, Solution Requirements, and System Design. Responsibilities at this stage are divided between the 2030 Census Program and solution providers.

Figure 4: V-Model – Activities within the Decomposition and Definition Stage

2.1.1 Key Activities

2.1.1.1 Research

Research is a key step in decomposing and defining the 2030 Census technical solution. The

2030 Census Program takes a three-phased approach to engineering research: Understand, Conceive, and Evaluate.

Understand: This phase focuses on comprehending the 2030 Census Program’s context, the problems to be solved, and the needs of the stakeholders. In some cases, problems are clearly understood and/or previously identified by lessons learned. For these problems, the approach calls for minimal or moderate collaboration with subject matter experts (SMEs) to define requirements. In other cases, little is known about the problem itself or potential remediations.

The objective is to gather insights that serve as the foundation for subsequent decision-making and solution development.

Conceive: This step involves brainstorming and generating potential resolutions to the problems outlined. In this step, different ideas, concepts, and approaches are explored to envision how the 2030 Census Program can address identified needs and challenges.

Evaluate: During this phase, the 2030 Census Program critically assesses the potential solutions generated in the “Conceive” step. This assessment involves feasibility, practicality, alignment with 2030 Census Program objectives, and the ability to meet customer needs. The 2030

Census Program uses data-driven methods which include a set of defined, weighted criteria applied to each candidate solution, allowing for accurate comparison. DITD assesses five foundational parameters including total cost of ownership, maturity, subsequent applicability to the Census Bureau enterprise, scalability, and security. These results, assessments, and recommendations then progress through the appropriate IT governance implementation. The goal is to narrow down the list of potential solutions that are most promising and aligned with

2030 Census Program goals.

2.1.1.2 Stakeholder Requirements

The 2030 Census Program manages four levels of requirements: Mission, Activity, Stakeholder, and Solution. Solution requirements are described in section 2.1.1.4 Solution Requirements.

Mission requirements are externally facing requirements that establish why the 2030 Census

Program is required. Activity requirements define the actions necessary to achieve the outcomes of one or more mission requirements. Both are considered high-level requirements that lay out the 2030 Census Program’s overall mission and operational outcomes that drive the development of stakeholder requirements.

Stakeholder requirements are mid-level requirements which represent the needs of the 2030

Census Program’s internal stakeholders to achieve Mission and Activity requirements.

Stakeholder requirements place the stakeholders and users at the center of focus and describe what the 2030 Census Program must produce or provide. Business stakeholders are responsible for defining and baselining stakeholder requirements. Once developed, stakeholder requirements are analyzed to determine if the solution provider(s) should be an IT system, an operational solution, or both. For additional details on stakeholder requirements, refer to the

2030 Census Requirements Management Plan (RMP) listed in Appendix C.

Solution requirements are developed for both IT and operational solutions. They are the most detailed program requirements providing solution providers with manageable and logical information needed to develop solutions.

SRR is the first milestone within the V-Model. The objective of SRR is for the business to deliver stakeholder requirements and supporting documents such as a Business Process Model (BPM) to DSE and TI. SRRs are iterative events which allow the SoS architecture to begin formulating designs while new stakeholder requirements are received, and baseline and allocation activities are continuously conducted. The Solution Architecture Team allocates the Stakeholder-level IT requirements to solution providers throughout SRR and delivers final allocated stakeholder requirements to prepare the 2030 Census Program to enter the next milestone: CDR. By conducting SRRs, the program ensures all solution provider objectives and expectations are clear. This clarity reduces any ambiguity and minimizes the risk of misinterpretation, leading to a more consistent, successful, and aligned SoS design. It is key to note that allocation activities and design of the SoS architecture may occur in parallel.

2.1.1.3 SoS Architecture

The 2030 Census Program designs and implements the SoS architecture to enable business needs and objectives and to align with the 2030 Census IT Strategy and Roadmap. The architecture is documented in the 2030 Census SoS Solution Architecture document. The process of developing the architecture is based on "The Open Group Architectural Framework"

(TOGAF), a cyclical Architecture Development Methodology (ADM).

Figure 5: TOGAF-based Architecture Development Method

During the Preliminary phase shown in Figure 5, the Solution Architecture Team reviews various artifacts and documents to understand the 2030 Census Program's vision, goals, and objectives. This review includes identifying frameworks, methods, and processes that are used to develop the architecture, defining the organizational model for the architecture, establishing the detailed process and resources for Architecture Governance, and selecting and implementing tools that support the architecture. Activities in each of the steps usually overlap, and multiple iterations of the steps may be implemented as additional elements of the architecture evolve through testing, change requests, or lessons learned.

Step A - The Architecture Vision, provides a high-level description of key approaches to be used within the architecture and defines the Architecture Principles captured in the 2030 Census

Architecture Vision document.

Step B - The Business Architecture, describes how the solution needs to operate to achieve the business goals and respond to the strategic drivers set out in the Architecture Vision in a way that addresses stakeholder concerns. The Program Architecture is documented in both BPMs and Integrated Operations Diagrams (IODs). Stakeholder requirements, BPMs, and IODs are baselined at SRR.

Step C - The Information and Application Architectures, describes the data repositories and high-level data structures to be used as well as the partitioning of the highest level SoS into systems. As part of this step, stakeholder requirements are allocated to the systems.

Communication diagrams, referred to as Workflow Diagrams (WFDs), are also created during this step. The purpose of a WFD is to provide a clear and comprehensive overview of how systems communicate with each other during an operation. It outlines all participating systems, interfaces, processes, interactions, and users involved. Because WFDs include lower-level interfaces, draft WFDs may be created as the application architecture is being developed. The

WFDs (and the interface catalog) are not baselined until after solution providers have begun development and started to define the interfaces. WFDs and the interface catalog are baselined at IBR.

Step D - The Infrastructure Architecture, describes, at a high level, the physical architecture used in the SoS, which is predominantly physical locations of facilities, high-level network diagrams, and selections for cloud/on-prem locations at a high level, also known as the “what goes where diagram,” for each system. It is after this step that solution providers are identified or notified. After IT solution providers review and accept the requirements, they begin the process of working with stakeholders to further decompose/clarify the requirements, operations, and business processes that have been allocated to them.

Step E - Opportunities, Solutions, and Transition Planning, is the creation of the 2030 Census

Architecture Transition Plan that describes the architectures for the 2026 Census Test, 2028

Dress Rehearsal, and the 2030 Census. The transition plan helps drive a development and integration approach in which the solutions are built incrementally as they progress to the final solution. The incremental development approach drives the creation of the detailed IIP.

Step F - Integration and Implementation Planning, which guides the development and integration of the individual systems.

Steps G - Implementation Governance, and H, Architecture Change Management, then provide governance, management, and control of these architecture artifacts.

The SoS architecture provides the high-level vision of the entire SoS. It illustrates how different subsystems or components interact and contribute to the overall 2030 Census Program’s goals.

The CDR is the milestone in which SoS Architecture artifacts, such as the Application

Architecture Diagram, are communicated and baselined. The solution providers can then begin solution requirement elicitation, acquisition planning, if necessary, and development.

2.1.1.4 Solution Requirements

The requirements analysis phase of the eSDLC includes gathering, analyzing, and documenting solution requirements. Solution requirements are the lowest level of requirements that provide manageable and logical details required to develop units of functionality and, ultimately, a solution.

Solution requirements can either be fulfilled by an IT solution, an operational solution, or both.

Solution providers, in collaboration with SMEs, are responsible for identifying and documenting their respective solution requirements using the SoS architecture and stakeholder requirements as inputs.

The development of solution requirements embodies an iterative and incremental approach.

Through detailed planning, solution providers, in collaboration with SMEs, engage in the process of refining and shaping requirements in response to changing customer needs as well as the identification and allocation of new stakeholder requirements. This iterative practice demonstrates how solution providers break down complex requirements into manageable units of work (or user stories), fostering incremental development. As this iterative practice progresses, new insights are seamlessly integrated, ensuring that the solutions remain aligned with 2030 Census Program objectives.

For additional details on solution requirements, including rules that must be adhered to when documenting solution requirements and the level of traceability expected from solutions requirements, refer to the 2030 Census RMP listed in Appendix C.

2.1.1.5 System Design

System design refers to the process of creating an architectural plan for a solution that meets specified solution requirements. Typically, system design involves breaking a solution down into modules and defining relationships and interfaces between them. The identification of modules supports solution providers by further decomposing them into components that define the internal structure of each model, including any data structure, algorithms, and interfaces within each component.

System design is a critical step that bridges the gap between requirements and implementation.

It ensures that the system’s architecture is well-structured, components are well-defined, and the solution’s design aligns with intended and required functionality. The output of system design serves as the basis for the next stage in the engineering life cycle: Development and

Implementation (see section 2.2).

2.1.2 Key Processes Applied – Decomposition and Definition

Decomposition and Definition activities include two key processes as shown in Figure 6. The use of standardized processes contributes to the success of the 2030 Census Program by providing a consistent and predictable framework that ensures activities are executed in a reliable manner across the program. As mentioned previously, this stage sets the foundation for the

2030 Census Program’s success and requires that robust, structured procedures be in place.

Figure 6: Decomposition and Definition Key Processes

2.1.2.1 Requirements Management

Requirements Management is a fundamental and critical aspect of System Engineering that serves several purposes, including setting clear expectations, defining scope, establishing alignment with stakeholder needs, and providing comprehensible reporting and traceability.

The Requirements Management Team (RMT) oversees Requirements Management and is responsible for facilitating the collection, analysis, and on-going maintenance of requirements and maintaining the RMP. The RMP outlines the requirements management process from elicitation to validation and verification and provides a framework for how requirements are collected, analyzed, documented, and maintained throughout the 2030 Census Program life cycle.

2.1.2.2 IT Solution Design Processes

The eSDLC defines the project-level engineering processes, along with the necessary artifacts and reviews, for all 2030 Census solutions. In addition to following the eSDLC process, all solution providers supporting the 2030 Census must have solution designs reviewed by the

DITD Engineering Working Group (EWG). The EWG reviews all aspects of a solution’s architecture to ensure the design:

• Meets Architectural standards, especially in relation to cloud smart architecture.

• Satisfies security and infrastructure requirements.

• Maximizes cost efficiency.

• Aligns with 2030 Census business needs.

Additionally, the 2030 Census SoS Solutions Architecture document outlines design principles that should be applied, when possible, at the project level.

2.2 Development and Implementation

Development and Implementation activities begin following the IBR milestone. The goal of IBR is to ensure system artifacts, such as solution requirements (features and user stories or equivalent), architecture artifacts, technical specifications, and engineering plans are accepted by participating systems and leadership before beginning development and testing.

Development and Implementation refers to the process of actualizing the system design into a functional solution, which may encompass building the components, integrating them, and ensuring that the system is developed as intended.

Figure 7: Agile DevSecOps

Solution providers can employ different software development processes tailored towards their requirements, integration, and data sensitivity; however, they must comply with 2030 Census standards and guidelines as provided by the DITD. The eSDLC serves as an organized process model for developing and implementing a system or solution.

The 2030 Census Program recommends optimization and modernization of 2030 Census solutions as appropriate, driven by cloud-native pillars such as microservices, containerization, automation, Infrastructure as Code (IaC), and Development Security Operations (DevSecOps) principles. The 2030 Census Program envisions these technologies as the foundation for software development efforts. By leveraging modern methodologies, solutions achieve scalability, continuous improvement, resilience, and efficiencies in deployments. Furthermore, working under a DevSecOps (see Figure 7) approach verifies that security is integrated at every stage of the development life cycle. Teams can then obtain immediate feedback on adherence to coding standards, code quality, and security requirements.

2.2.1 Key Processes Applied – Development and Implementation

Infrastructure Management, Interface Management, Software Configuration Management, and

Information Management are all key processes applied for effective development and implementation (see Figure 8). The use of standardized processes and best practices contribute to the success of the 2030 Census Program by fostering cooperation, streamlining processes, and safeguarding the integrity of system data and infrastructures.

Figure 8: Development and Implementation Key Processes

2.2.1.1 Infrastructure Management

The methodology for designing, implementing, and managing the infrastructure for the 2030

Census is described in the 2030 Census SoS Infrastructure and Integration Plan (SIIP). The SIIP provides details on the architecture and integration mechanisms for Infrastructure as a Service

(IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), as well as other cloud provider managed service components that are used to support the 2030 Census. It outlines an infrastructure architecture that is scalable and capable of handling innovation to meet the demands of the 2030 Census. It details how various infrastructure components are integrated to provide a cohesive infrastructure solution. Lastly, the SIIP outlines how change is managed to verify impacts are understood and evaluated for risk.

2.2.1.2 Software Configuration Management

The Software and Infrastructure Configuration Management Plan (CMP) manages the life cycle of software and infrastructure changes. The 2030 Census Program strongly encourages solution providers to adopt Continuous Integration/Continuous Delivery (CI/CD) practices and use a suite of DevSecOps tools and governance processes. These practices improve the quality of the deliverables, minimize risk, and facilitate an agile and timely response to changes in operational configurations or specifications during production operations.

Configuration and change management are tightly integrated in the 2030 Census Program. They provide a clear escalation path for technical changes that may impact the program (as described in Section 3.7: Change Management).

2.2.1.3 Interface Management

The Interface Management Group (IMG) serves as a technical arm of the 2030 Census Program.

The IMG assesses and facilitates the technical maturity of system interfaces. The applicable standard templates and procedures associated with the IMG process are defined in the 2030

Census Interface Document Governance Process, listed in Appendix C.

The 2030 Census Interface Catalog (listed in Appendix C) documents all data flows between

Census Bureau systems to be used in support of the 2030 Census and includes intersystem data flows. There are two types of interfaces: Enterprise-identified interfaces and 2030 Census-identified interfaces. An Enterprise-identified interface is any 2030 Census applicable interface where the producer or consumer is an Enterprise system (e.g., Enterprise Data Lake (EDL) or

Data Ingest and Collection for the Enterprise (DICE)). The Enterprise Interface Catalog is an authoritative document for all referenced interfaces related to the Enterprise. 2030 Census-identified interfaces are all interfaces outside of the enterprise scope, but still applicable to the

2030 Census Program.

The 2030 Census Solution Architecture Team interacts with IT solution providers as needed to resolve any synchronization issues. If there are any changes that add, modify, or remove interfaces in the 2030 Census Interface Catalog, the 2030 Census Solution Architect or Solution

Provider initiates a 2030 Census change request. The 2030 Census Interface Catalog is available for review by stakeholders in the 2030 Census Configuration Management (CM) repository.

2.2.1.4 Information Management

Information Management is a set of processes, policies, and design patterns that confirm information is properly stored, maintained, secured, and accessible only to those with a business need. In the context of the 2030 Census, these processes are designed to facilitate the use of advanced data science methods and techniques, transactional processing, statistical analysis, and the application of artificial intelligence and machine learning (AI/ML). All 2030

Census solutions must adhere to the Information Management policies, with an emphasis on the Interface and Security policies, described in the Enterprise SEMP.

2030 Census solutions which require use of Personally Identifiable Information (PII), Title 5, Title 13, or Title 26 data work with an assigned Decennial Information Security Engineer, or the

Information System Security Officer (ISSO) from the Office of Information Security (OIS) to obtain the necessary security authorizations (defined by OIS) for intended testing and production activities. Additionally, the Information Security Engineer, or ISSO, approves an

Authorization to Operate (ATO) for all systems before their release to production. For additional information on security management, see Section 4.1.

In addition to adhering to enterprise security policies related to information management, the

2030 Census embraces the Census Bureau's digital transformation effort, including leveraging advanced data science methods and techniques to unlock insights and enhance efficiency. Key areas of focus are:

• BE initiatives: Using the full potential of Census Bureau resources and data analytics efforts to improve the quality and efficiency of the 2030 Census.

• Strategic leverage of administrative data and advanced record linkage approaches:

Expanding the use of previously independent data sets by implementing strategic approaches to link and use administrative data.

• Incorporation of cloud-based analytics platforms: Enabling scalable and cost-effective storage, processing, and analysis of extensive 2030 Census data, which support real-time analytics and decision-making.

• Predictive analytics and modeling: Using large sets of historical and administrative data to predict activities and drive more efficient approaches in 2030 Census operations.

• Applying advanced data science methods and techniques including AI/ML in 2030

Census Program planning, execution and management, security, software development, test, and other stages of the SDLC.

• Attention to cost effective storage and retention approaches including online storage needs for databases and active repositories as well as long-term storage needs for backups and archival.

• Given the data-centric nature of the SoS Architecture, sensitive data is centrally located.

While this centralization helps control the dispersion of data, it also provides adversaries a single “target.” As such, significant attention needs to be given to protecting this central repository and avoiding breaches, rather than simply detecting them.

• Impact of updates to administrative data and Frames data: Using administrative data and Frames data as primary sources prompts a need for data management that does not disrupt users of that data. This data requires strategies for data release, quality measurements, and accuracy indicators.

• Usability by 2030 Census: To implement the 2030 Census architecture vision, the use of multiple administrative data sets throughout the decade becomes critical. As such, determining the applicability and quality of those data sets is paramount.

• Extension to Data Management: Traditional software control and management processes must now also apply to data, ensuring consistency and accuracy.

The Information Management efforts for the 2030 Census Program also focus on planning for the integration of applications with EDL, establishing data pipelines, implementing

Extract/Transform/Load (ETL) processes, standards-based data storage, and data re-use.

The overarching goal is to leverage modern technologies and data-driven approaches to enhance decision-making and drive overall efficiency and productivity. Preparing for these advanced data-centric challenges requires enhancements to processes and policies to drive governance, standardization, privacy protection, security, communication, and other activities.

2.3 Integration

The Integration stage of the V-Model aims to bring together the individual components or sub-systems developed during the Development and Implementation stage to validate that the integrated solutions work harmoniously as a complete SoS, with data flows behaving as expected from solution A through solution Z. The Integration stage is essential for verifying that the integrated SoS meets specified requirements, interfaces between components are functioning correctly, and any potential issues or inconsistencies are identified and addressed prior to conducting operations in Production.

This stage consists of five activities: Project Test, SoS Integration Test, Stakeholder Verification, Operations Test, and Operations and Maintenance (O&M). Stakeholder responsibilities at this stage are divided between the solution providers and the 2030 Census Program. Solution providers own their respective project test activities, and the 2030 Census Program manages the subsequent integration efforts.

Figure 9: V-Model – Activities within the Integration Stage

2.3.1 Key Activities

2.3.1.1 Project Test

Project testing is the responsibility of the solution providers, and may occur in parallel with

Development and Implementation, as solution providers progress iteratively in delivering components of functionality and testing. During the early phases of development, project testing is conducted to demonstrate the feasibility of conceptual approaches, evaluate design risk, identify alternatives, compare and analyze trade-offs, and assess the solution’s satisfaction of requirements. The project-level test scope is comprised of various test efforts including Unit

Test, Component Test, Pairwise Test, Application Programming Interface (API)/Component Base

Performance Test, and User Acceptance Test. For additional details on each of these test efforts, refer to the Test and Evaluation Management Plan (TEMP), listed in Appendix C.

With the adoption of IaC and a CI/CD pipeline, most project testing can be achieved through automation. Automation provides continuous validation of updates as changes are developed and merged. Continuous validation avoids the need for environment lockdown in cases where developers are working in parallel and reduces the risk of code changes that break existing functionality.

During project test activities, solution providers are also expected to collaborate with infrastructure teams and program-level test (PLT) teams to prepare for upcoming 2030 Census

Program test efforts. This milestone is referred to as the PTIC. The PTIC is conducted to certify that teams are prepared to perform kickoff activities required by the PLT efforts, including communication of expected deliverables, provisioning of higher environments, and implementing CI/CD pipelines in said environments. At a minimum, criteria to “exit” PTIC includes a ready-for-use Integrated Test Environment (ITE) and access to the ITE granted to members of the 2030 Census PLT team. For additional details on PTIC, refer to the 2030 Census

IIP and the 2030 Census TEMP listed in Appendix C.

Project testing is an ongoing activity that continues throughout the SDLC. CI/CD forms a foundation for modern software development in that it enables project testing to persist concurrently with program testing, seamlessly intertwining both activities through a well-orchestrated pipeline.

2.3.1.2 SoS Integration Test

The primary objectives of SoS Integration test activities are to confirm a solution’s functionality, performance, reliability, and validate that the SoS meets specified requirements. Following a successful PTIC and the verification of a preliminary set of solution capabilities during project test, the 2030 Census PLT team conducts the TRR. The objective of TRR is to confirm appropriate 2030 Census Program test objectives, schedules, and scripts have been documented, environments are ready, and solution providers are prepared to participate in integrated program-level testing. This milestone initiates program-level SoS Integration Testing

(SIT).

SIT is the process of combining various systems into one overall SoS. A multitude of test efforts are conducted during SIT. These efforts include but are not limited to: End-To-End Integration

(EEI) testing, device and browser testing, exception testing, and Performance and Scalability

(P&S) testing in an environment(s) mirroring the target infrastructure of Production. SIT focuses on executing tests across system boundaries. Such testing validates the physical and logical interfaces between systems, hardware products, software products, and external interfaces.

For more information on program test scopes, such as ownership, support area(s), and timeline, refer to the TEMP and the P and S Test Plan, listed in Appendix C.

Throughout 2030 Census Program test activities, solution providers are expected to support the

PLT teams by providing an initial overview of the system, maintaining technical specifications, troubleshooting, and remediating defects.

CI/CD practices are carried forward from project test to program test; however, practical differences may exist, including, but not limited to:

• Deployment frequency: Projects tend to deploy changes more frequently to lower environments, where new releases may occur as often as 1-2 times per day. In contrast, at the program level, solution providers exercise a more structured, cautious approach with releases, as they focus on coordinating and managing the integration of multiple solutions to minimize conflicts and dependencies.

• Testing scope: Project-based CI/CD primarily focuses on testing the functionality and behavior of a specific product. Tests are designed to validate success criteria of individual solution requirements. On the other hand, program tests require broader testing to confirm the compatibility and integration of changes. Therefore, 2030 Census

Program-focused CI/CD includes a more extensive automation test suite where integration and end-to-end (E2E) tests play a more significant role.

If a third-party solution provider is performing program-level and P&S testing independently, the 2030 Census PLT team reviews the test plan, test scenarios, and appropriate test execution results to ensure the third-party test plan and execution results meet the program objectives.

2.3.1.3 Stakeholder Verification

Business stakeholders conduct tests to verify if the solution properly implements business processes and meets their defined requirements. Stakeholder verification can be grouped into five key focus areas:

• User Integration Acceptance Testing - Focuses on integrated, comprehensive, role-based test scenarios that interact with a solution’s user interface from an E2E approach.

• User Reports Acceptance Testing - Focuses on validating the logic and rendering of system-generated reports to confirm report data is aggregated consistently and correctly.

• Output Testing - Focuses on verifying and validating the outputs, results, or deliverables of a system or process to ensure they meet expectations. This evaluation assesses the preparedness of the SoS to perform near real-time processing and post-collection processing activities.

• Path Testing - Focuses on testing various paths or sequences of code within a software application. Testing each point is critical to ensure no path iterates infinitely or terminates abnormally. The goal is to determine the number of unique, independent paths and uncover potential errors or logical flaws in the code by exercising different combinations.

• Data Validation - Data Validation testing is the process of examining the quality, accuracy, and consistency of data. Data validation tests are conducted at the original data source, throughout processing and transformations (where applicable), and after storage. This testing ensures that merged data from various sources, stored in separate repositories, are compatible and protect data from corruption.

For additional details on test efforts performed by stakeholders, refer to the TEMP, listed in

Appendix C. The PRR is conducted once all functionalities of an operation have completed and passed program-level testing with no critical or major defects.

2.3.1.4 Operational Readiness Test

Operational Readiness Testing (ORT) provides stakeholders the opportunity to oversee user role-based testing that unites operational procedures and system functionality. The ORT begins after successful completion of the PRR.

ORT evaluates the SoS’s readiness for production by running a series of activities that assess the

2030 Census Program’s ability to function in a “real world” integrated environment and respond to a multitude of operational scenarios. Test scenarios designed for Operational

Testing focus on system operations, system reliability and maintainability, process validation, and end-user training and accessibility. By conducting ORT, the program mitigates the risk of critical issues or failures occurring in a live production environment by allocating a final phase for early detection and resolution of issues.

Closeout of ORT activities kickstarts the final milestone, ORR, prior to conducting operations in

Production. ORR is a final check that the needed resources (i.e., people, solutions, processes, and facilities) have been acquired, developed, and fully tested. ORR prompts solution teams to deploy code to the Production environment and complete smoke testing ahead of CO, the final milestone in which the 2030 Census Program transitions to O&M. For further details on ORT, refer to the TEMP, available in Appendix C.

2.3.1.5 Operations and Maintenance

For SoS architecture, O&M activities are crucial components that focus on verifying the ongoing functionality, performance, and support of the interconnected systems and operational procedures. The limited period of live production operations for the 2030 Census, coupled with its scale, places a demand on solution providers that often exceeds standard support models.

Operational activities for the 2030 Census Program include the following:

• Production Checkout: Testing that provides solution providers, Operation Delivery (OD) teams, and infrastructure teams the ability to ascertain that system configurations, authentication/connection mechanisms, and internal backend procedures are provisioned accurately and enabled prior to the full launch of production operations.

• Soft Launch: An early run-through of the production operation to ensure all functional and operational components, as well…