Leonardo DRS: Managing Defense Electronics at Scale

The Mid-Tier Prime Problem

Leonardo DRS sits in a structurally difficult position in the defense electronics market. It is large enough to hold prime contracts on complex DoD programs — naval power and propulsion, ground vehicle electronics, airborne surveillance systems — but not so large that it can absorb coordination overhead the way Lockheed Martin or Raytheon can. The company reported approximately $3.1 billion in revenue for fiscal year 2025, operating as a subsidiary of Italy’s Leonardo S.p.A. while running a largely independent U.S. defense operation. That combination — DoD prime obligations with mid-tier internal resources — defines the engineering challenge.

Understanding Leonardo DRS requires understanding that space. It is not a boutique defense electronics firm running one program at a time. It is not a tier-one prime with dedicated systems engineering centers for each domain. It is, operationally, both things at once: complex enough to need the discipline of a prime, constrained enough to feel the cost of that discipline.

Portfolio Breadth and What It Demands

Leonardo DRS organizes its business around three primary domains: naval systems, ground systems, and sensing and network systems (which covers most airborne and ISR applications).

On the naval side, the company’s integrated electric propulsion systems and power conversion equipment appear on Virginia-class submarines, DDG-51 destroyers, and CVN-class carriers. These are long-cycle programs — ten to thirty years from initial design through fleet sustainment — with requirements documentation that must survive multiple engineering generations, organizational changes, and platform upgrades. A requirement written during ship design in 2008 must still be traceable to a verification test run in 2031.

The ground systems portfolio centers on vetronics: vehicle electronics architectures for platforms including the Abrams, Bradley successor vehicles, and various wheeled systems. Ground programs differ from naval ones in critical ways. Upgrade cycles are shorter, often driven by urgent operational needs rather than planned block upgrades. Requirements volatility is higher. The government customer — typically Army DEVCOM — may issue engineering change proposals mid-program in response to field experience. Traceability has to survive that churn without becoming a manual reconciliation burden.

Sensing and network systems covers thermal imaging, signals intelligence payloads, and battlefield network hardware. Airborne programs bring their own discipline: DO-178C and DO-254 for software and hardware airworthiness, MIL-STD-461 for electromagnetic compatibility, and the layered verification requirements of airworthy military systems. The documentation burden is high. The tolerance for ambiguous requirements is low.

Running these three domains concurrently means Leonardo DRS manages programs with fundamentally different requirements lifecycles, different government customer organizations, different verification regimes, and different rates of change — all at the same time.

The Coordination Problem No Tool Solves by Default

The obvious question is: how do you maintain systems engineering coherence across a portfolio that diverse?

The honest answer is that most companies at this scale do not achieve it fully. What they achieve is local coherence — each program team manages its own requirements reasonably well — with intermittent portfolio-level visibility when leadership demands it. That visibility usually arrives as a manually assembled status report, not as a live system of record.

This is not a Leonardo DRS-specific failure. It is a structural characteristic of how the defense industry adopted requirements management tooling in the first place. IBM DOORS, which remains present in most legacy defense programs, was designed around the document metaphor: a database of requirements organized in hierarchical modules. It is excellent at capturing and linking requirements within a single program. It is not designed to give a director of systems engineering a cross-program view of derived requirements, open TBDs, and verification status simultaneously across naval, ground, and airborne work.

DOORS Next, Jama Connect, and Polarion each improved on different dimensions — better web interfaces, better review workflows, better integration with ALM tools — but they largely preserved the document-centric model. The query you need to answer (“show me all requirements across active programs that have no assigned verification method”) requires either a purpose-built data integration effort or someone running manual reports across program databases.

At Leonardo DRS’s scale, this matters practically. When a common subsystem — say, a power electronics module — appears in both a naval variant and a ground vehicle application, the requirements lineage for that subsystem should ideally inform both program teams. In practice, it often lives in separate tool instances, maintained by separate teams, with no automated connection between them.

Digital Engineering Mandates Arrive Before Readiness

The Department of Defense’s Digital Engineering Strategy, formalized in 2018 and progressively embedded in contract requirements since, asks defense contractors to deliver authoritative source of truth models, connected requirements, and digital artifacts in place of traditional document deliverables. The mandate is real. The timeline pressure is increasing.

For a company like Leonardo DRS, the pressure arrives unevenly. New program starts — especially those under Air Force and Navy programs that have moved furthest toward digital engineering expectations — may require a Model-Based Systems Engineering approach from contract award. Legacy programs, still running on DOORS databases and Word documents, receive no such mandate and often have no budget line to fund tooling modernization. The result is a bifurcated engineering organization: one group doing MBSE with SysML models and digital thread artifacts, another maintaining the same Word-to-DOORS workflow they used in 2009.

That bifurcation is not sustainable indefinitely. As engineers rotate across programs, institutional knowledge of how each program’s requirements are managed becomes a retention and onboarding challenge. A mid-career systems engineer comfortable with digital engineering workflows may find legacy program tooling genuinely frustrating. A senior engineer who built a program’s DOORS structure over fifteen years may be the only person who understands why certain module hierarchies exist. When that person retires, the program loses something that no export can fully capture.

DoD’s push toward digital engineering is essentially asking defense contractors to solve this problem on program budgets that were not sized to include tooling transitions. That is a real tension, and mid-tier primes feel it more acutely than their larger competitors, who can absorb transition costs across a larger revenue base.

What a Modern Tooling Architecture Looks Like

The companies navigating this transition most effectively are not simply replacing one requirements database with another. They are rethinking requirements management as a graph problem rather than a document problem.

In a document-centric model, a requirement is a row in a module, with parent-child relationships and maybe a few typed links to test cases. In a graph model, a requirement is a node with typed relationships to stakeholder needs, design decisions, verification activities, risk items, and other requirements across any number of programs. Queries become structural: you can ask what design decisions are justified by a single stakeholder need, or which verification tests cover requirements that trace back to a specific MIL-SPEC clause.

This distinction matters at Leonardo DRS’s scale because the interesting engineering questions are almost always relational. They are not “what does requirement R-0047 say?” They are “if we change the thermal spec on this power module, which other program requirements are affected?” Legacy tools answer the first question adequately. They struggle with the second.

Tools like Flow Engineering are built around this graph-native model, with AI-assisted traceability designed specifically for the kind of multi-program, cross-domain requirements environments that defense electronics companies actually operate in. The value proposition is not a better place to store requirements — it is a connected environment where derivation, coverage, and change impact are queryable rather than manually reconstructed. For a company managing concurrent programs across naval, ground, and airborne domains, that kind of cross-program visibility is the capability that document-centric tools cannot provide without significant custom integration work.

The practical challenge is transition. Programs mid-execution cannot easily migrate requirements databases without risk to schedule and without significant engineering time investment. The realistic path for most mid-tier primes is a hybrid period: legacy programs continue in DOORS or equivalent, new program starts adopt modern tooling, and the portfolio gradually shifts over a five-to-ten year horizon as programs close and open. That is a long time to maintain bifurcated tooling competency, but it is more honest than assuming a clean cutover is achievable.

An Honest Assessment

Leonardo DRS has built genuine engineering depth in domains — naval electric propulsion, vetronics integration, airborne thermal sensing — where the technical barriers are high and the customer relationships are long. That is the foundation of a durable defense electronics business.

The systems engineering infrastructure challenge it faces is not unique. It is representative of what the mid-tier defense electronics sector looks like in 2026: real technical complexity, accumulated legacy tooling debt, digital engineering mandates arriving from government customers, and organizational bandwidth that is finite.

What distinguishes companies that navigate this well from those that do not is usually not the tool selection decision itself. It is whether leadership treats requirements management as a program-level administrative function or as a strategic systems engineering capability. Companies that treat it as the latter invest in cross-program visibility, in tooling that supports change impact analysis rather than just document storage, and in engineers who understand requirements architecture rather than just requirements entry.

For a company with Leonardo DRS’s portfolio breadth, the cost of not making that investment shows up in engineering rework, in verification gaps discovered late, and in the manual coordination overhead that accumulates when programs share components but not information. Those costs are real, even when they are hard to attribute directly to tooling choices. The question is not whether to modernize — DoD’s digital engineering trajectory makes that answer clear. The question is how to do it without destabilizing the programs that are running today.