The Integrator Problem

There is a category of engineering organization that gets less attention than it deserves in discussions of systems engineering practice: the large-scale integrator. Not the company that designs a radar. Not the company that writes the flight software. The company that takes the radar, the flight software, the communications stack, the ground systems, and the human operators and makes them work together as a single operational military capability.

Leidos is that company — or rather, one of the largest examples of that company in existence. With annual revenues exceeding $15 billion and a workforce of roughly 47,000 people, Leidos sits at the center of some of the most complex defense and government IT programs in the world: the Navy’s NGEN-R (Next Generation Enterprise Network-Recompete), the Air Force’s AFLCMC logistics systems, intelligence community data infrastructure, and a range of classified integration programs that never appear in public contract announcements.

The engineering discipline required to operate at that scale, across that many domains, under government requirements authority, is worth examining carefully. It is not the same discipline as product engineering, and the tools and processes that work well for one frequently fail at the other.

What Leidos Actually Builds

The term “defense contractor” obscures more than it reveals. Leidos does not primarily build weapons systems. It builds the systems that connect, operate, sustain, and provide data to the people who use weapons systems. Its portfolio spans:

Enterprise IT for defense and government. NGEN-R, the Navy and Marine Corps enterprise network serving over 550,000 users, is among the most visible examples. This is not software development in the startup sense — it is large-scale systems integration of networking hardware, cybersecurity infrastructure, service desk operations, and endpoint management, delivered against government-defined SLAs and security requirements.

C4ISR integration. Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance programs require Leidos to integrate hardware from multiple prime contractors — radars, sensors, communications terminals — with software from different vendors and data architectures defined by joint military doctrine.

Health informatics and federal civil systems. Through its Civil and Health segments, Leidos integrates systems for agencies including HHS, DHS, and the FAA — programs that share the same multi-stakeholder, government-authority requirements structure as defense programs, even if the technical content differs.

The common thread is integration responsibility under government requirements authority. Leidos rarely owns the requirement at the top level. It receives it, decomposes it, allocates it across its own teams and subcontractors, and then demonstrates that the integrated system satisfies it. That is a fundamentally different engineering posture than a company that authors its own product specification.

Engineering Organization at Scale

Leidos structures its engineering organization along both segment lines (Defense & Intelligence, Civil, Health) and program lines, with a corporate engineering function that establishes standards, tools, and workforce development across segments.

The Chief Engineering Officer role at Leidos carries genuine authority over engineering process, not just advisory influence — a distinction that matters in an organization where program managers often have stronger budget authority than functional chiefs. The corporate engineering function maintains the Leidos Engineering Process, a defined set of practices aligned to INCOSE Systems Engineering Handbook and compatible with DoD Digital Engineering Strategy requirements. Programs are expected to implement this process, with tailoring approved for program-specific constraints.

In practice, what this means on large programs is a Systems Engineering and Integration (SE&I) team that operates somewhat separately from the development execution teams. The SE&I team owns the system architecture, manages the interface control documents (ICDs), runs the requirements database, chairs the interface control working groups (ICWGs), and is responsible for demonstrating integrated system performance against government-specified acceptance criteria.

This structure reflects a mature understanding of what integration programs actually require. The engineers doing subsystem development need different information, at different levels of abstraction, than the engineers managing interface compliance. Conflating those roles produces programs where interface problems are found late — in integration testing — rather than early, in design reviews.

MBSE Adoption: The Government-Mandate Reality

Leidos has made genuine investments in Model-Based Systems Engineering. It maintains SysML modeling capability across its major programs, has developed internal training programs, and participates in industry working groups on digital engineering standards. Its public statements on MBSE are consistent with genuine organizational commitment, not marketing.

The more honest picture, however, is that MBSE adoption across Leidos programs is uneven in ways that reflect a structural reality of defense contracting: digital engineering requirements are program-specific, and programs are defined by government customers who have their own levels of digital engineering maturity.

When the Office of the Secretary of Defense issued its Digital Engineering Strategy in 2018 and subsequent DoD Instruction 5000.97 established digital engineering as a requirement for major defense acquisition programs, it created compliance obligations but not uniform implementation. Different program offices interpret “authoritative source of truth” differently. Some government customers mandate a specific modeling tool or framework. Others specify outcomes — traceability, model-based reviews — without prescribing the implementation. Others are still operating programs originally contracted under document-centric requirements, with no contractual basis for requiring a model-based approach.

Leidos, like every large defense integrator, therefore maintains parallel competency: document-centric requirements management using tools like IBM DOORS or DOORS Next for programs where that is the government baseline, and SysML-based MBSE for programs where the government customer has mandated or requested it. This is not organizational inconsistency. It is the correct response to a heterogeneous customer base with heterogeneous contractual requirements.

What makes this challenging is that the workforce skills for document-centric and model-centric approaches are different, and a program engineer who moves between program types faces significant context-switching cost. Leidos addresses this through its internal engineering competency framework, but the challenge is real and industry-wide.

Requirements Flow-Down in a Multi-Contractor Program

The most demanding systems engineering challenge Leidos faces is not technology — it is governance. Specifically: how to manage requirements flow-down across a program structure where the government owns the top-level requirements, Leidos owns the system-level requirements and integration responsibilities, and multiple subcontractors own subsystem requirements, often with their own internal processes that Leidos cannot directly control.

Consider a representative program structure: a C4ISR integration program where Leidos is the prime systems integrator. The government customer — a program office staffed by military officers and civilian engineers — maintains the Capability Requirements Document (CRD) and the system-level performance specification. Leidos decomposes that specification into a System Requirements Document (SRD) that it owns and maintains. From the SRD, Leidos derives interface requirements in ICDs and allocates subsystem performance requirements to subcontractors via Contract Data Requirements Lists (CDRLs) and subcontract statements of work.

Each subcontractor then manages its own internal requirements against what Leidos has allocated. Leidos cannot see inside their requirements databases. What it can see is what they report in program reviews, what they deliver in design products, and what their hardware or software does in integration testing.

This creates a traceability problem of significant practical consequence. If a government requirement changes — and in long-duration defense programs, requirements change frequently, driven by evolving threat assessments, budget adjustments, or operational experience — Leidos must:

  1. Identify all derived and allocated requirements that trace to the changed government requirement
  2. Notify affected subcontractors with sufficient specificity to allow them to assess impact
  3. Manage the resulting change requests, which may generate cost and schedule impacts requiring government approval
  4. Update the integrated system model or requirements database to reflect the new state
  5. Verify, in testing, that the change has been correctly implemented across all affected subsystems

Doing this reliably across a program with dozens of subcontractors, hundreds of ICDs, and thousands of traceable requirements is the core systems engineering discipline that separates programs that deliver from programs that fail.

Interface Management as the Central Discipline

In a product development company, the most important requirements are the ones that define what the product does. In a systems integration company, the most important requirements are the ones that define how the pieces connect. Interface requirements — electrical, mechanical, data, protocol, timing — are where integration programs succeed or fail.

Leidos has learned this the hard way across decades of programs. The organizational response is a strong Interface Control Document (ICD) discipline, with ICDs treated as controlled configuration items under formal change management. Interface Control Working Groups (ICWGs) — standing meetings between Leidos and its subcontractors, often with government customer participation — are the governance mechanism for managing interface changes.

The underlying technical problem with ICD management at scale is that ICDs are, historically, documents. Documents do not enforce internal consistency. An ICD for a data interface can specify a message format in one section that is inconsistent with the timing requirements in another section, and no document management system will catch that inconsistency. It requires either careful human review or model-based approaches that can check internal consistency automatically.

This is one of the clearest use cases for MBSE in integration programs: not because models are philosophically superior to documents, but because at the scale and complexity of a multi-contractor C4ISR program, the consistency-checking capability of a model-based approach reduces integration risk in ways that document-based approaches cannot match. Leidos’s digital engineering investments reflect this understanding, even if full implementation is constrained by program-by-program contractual reality.

The Verification and Validation Challenge

Requirements management does not end at decomposition and allocation. It ends at verification — demonstrating that the integrated system satisfies the government’s requirements. For a large integration program, this means maintaining a verification traceability matrix (VTM) that maps every requirement to a verification method (analysis, inspection, demonstration, or test) and a verification event.

At program scale, this matrix can contain tens of thousands of entries. Managing it manually, in a spreadsheet or document, is an error-prone process that defense auditors have consistently identified as a program risk indicator. Leidos, like other large integrators, uses requirements management tools to maintain this traceability — but the quality of the traceability depends on the discipline of the engineers maintaining it, not just the capability of the tool.

The verification challenge is compounded on multi-contractor programs because some verification events require the integrated system — you cannot verify an interface requirement against a single subsystem. This means that verification events must be sequenced, test environments must be established that represent the full integrated system, and subcontractors must participate in integrated testing in ways that their subcontracts must explicitly require and fund.

Programs that underplan integrated testing — that assume subsystem verification implies system verification — consistently discover interface problems late, in government acceptance testing, where the cost of correction is highest.

What Leidos Represents for the Industry

Leidos is not exceptional in the challenges it faces. Every large defense integrator — Northrop Grumman, L3Harris, Booz Allen in its technical segments, SAIC — faces the same structural tensions: government requirements authority, multi-contractor programs, document-centric legacy, and genuine pressure to move toward digital engineering without contractual mandate to do so uniformly.

What Leidos represents is a mature, large-scale response to those tensions: a corporate engineering process that provides structure without rigidity, genuine MBSE investment where contractually supported, and the interface management discipline that decades of integration programs have made unavoidable.

The honest assessment is that even at Leidos’s scale and maturity, requirements management on large integration programs remains harder than it should be. The tools available to defense integrators have not kept pace with the complexity of modern programs. Document-based requirements management at the scale of an enterprise network or a C4ISR integration program is genuinely inadequate — not because the documents are poorly written, but because documents cannot maintain consistency, cannot automatically propagate changes, and cannot provide the graph-based traceability that integration programs require.

The DoD’s digital engineering mandate is partly a recognition of this gap. The implementation of that mandate, across a contractor base as large and heterogeneous as the defense industrial base, will take years and will be uneven. Leidos is ahead of many of its peers in that transition, and behind where the technology could take it if contractual and organizational constraints permitted faster movement.

That is the honest picture of systems engineering at the defense integration scale: significant capability, genuine discipline, and structural constraints that the best engineering processes can manage but cannot eliminate.