====== 2.1 Operational Need ====== [[dido:02-crusible:02-operational-purpose-and-mission:start|Go to 2. Operational Need and Mission]] Software-intensive systems require substantial supporting capabilities before mission-specific functionality can be constructed, assessed, deployed, operated, and maintained in controlled environments. Individual projects commonly create their own approaches for: * Constructing and hardening software and [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]] * Selecting and composing [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]] * Building and maintaining [[dido:99_annexes:annex-b-terms-and-definitions:m:machine_image|Machine Images]] * Defining infrastructure through [[dido:99_annexes:annex-b-terms-and-definitions:i:iac|Infrastructure as Code (IaC)]] * Capturing and preserving [[dido:99_annexes:annex-b-terms-and-definitions:b:build_dependency|Build Dependencies]] * Performing [[dido:99_annexes:annex-b-terms-and-definitions:c:compliance_assessment|Compliance Assessments]] * Producing and preserving [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] * Transferring required artifacts into [[dido:99_annexes:annex-b-terms-and-definitions:d:disconnected_environment|Disconnected Environments]] and [[dido:99_annexes:annex-b-terms-and-definitions:a:air-gapped_environment|Air-Gapped Environments]] * Deploying, validating, reproducing, and maintaining the resulting environments These capabilities are necessary, but they do not usually provide the mission-specific functionality that distinguishes one product from another. When each project creates and maintains them independently, organizations repeatedly fund similar engineering work. Independent implementations also tend to use different tools, formats, interfaces, naming conventions, deployment methods, assessment procedures, and Evidence structures. This fragmentation: * Increases development and maintenance costs * Limits reuse across products and programs * Makes personnel movement between projects more difficult * Requires organizations to sustain a larger number of technologies and operational practices * Complicates comparison of assessment results and operational records * Makes environments harder to reproduce * Weakens [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] across lifecycle stages * Increases the effort required to transfer capabilities across security and connectivity boundaries The burden increases in secure, regulated, disconnected, and air-gapped operations. Projects must identify required dependencies, preserve them, transfer them across controlled boundaries, reconstruct the intended environment, verify the result, and retain sufficient [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] and Evidence to support assessment and authorization activities. Changes to operating systems, infrastructure providers, security criteria, compliance benchmarks, dependencies, and automation tools create an additional maintenance burden. A correction or improvement made by one project does not automatically benefit other projects when each project maintains an independent implementation. The operational need is therefore for a reusable and centrally maintained foundation that allows multiple projects to apply common lifecycle concepts, controls, interfaces, and automation while retaining the configuration and extensions required for their individual missions. This need derives from the approved Mission Objectives and Operational Requirements in [[dido:02-crusible:99-annexes:annex-c-requirements:start|Annex C: Requirements]]. This page describes the operational problem and does not establish additional requirements. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.