L3Harris Technologies: Systems Engineering at Scale Across a Defense Electronics Empire

Melbourne, Florida is not the first city most people associate with defense electronics leadership. But the headquarters of L3Harris Technologies sits there quietly, overseeing a company that generated $21.3 billion in revenue in fiscal 2025 and employs more than 50,000 people across dozens of business units building some of the most technically complex hardware in the defense industrial base.

The portfolio defies easy summary: tactical radios used by ground forces in nearly every major NATO ally, airborne ISR platforms that fly persistent surveillance missions over contested environments, space payloads on classified government satellites, night vision and electro-optical systems, electronic warfare suites, maritime sensors. The breadth is genuinely unusual. Most defense primes have a center of gravity—a domain where their core engineering culture lives. L3Harris has several, and they don’t all think about systems engineering the same way.

That tension is the most interesting thing about the company from a systems engineering perspective. The 2019 merger that created L3Harris combined two large, successful, independently operated defense contractors. Harris Corporation was a focused communications and space electronics firm with a relatively tight engineering culture built around precision RF systems and government space programs. L3 Technologies was a conglomerate of acquired defense businesses—sensors, training systems, aviation products, communications—united more by financial strategy than engineering philosophy. Merging them created an organization with extraordinary breadth and a genuine integration problem that seven years later remains partially unresolved.

What the Merger Actually Created

To understand L3Harris’s systems engineering challenge, you need to understand what Harris and L3 actually were before the merger.

Harris Corporation, pre-merger, was known for rigorous systems engineering on programs that demanded it. Its tactical radio programs—the Falcon family and its successors—required deep software-hardware integration, precise RF performance, and the ability to deliver to exacting military specifications across millions of units. Its space electronics work, serving classified government customers as well as NASA, carried the process discipline that comes from building hardware you cannot touch after launch. Harris had a culture that took systems engineering seriously as a technical discipline, not just a compliance exercise.

L3 Technologies was a different animal. It had grown through aggressive acquisition—more than 70 companies over roughly two decades. That strategy produced enormous revenue but also enormous process diversity. Different L3 subsidiaries had their own toolchains, their own requirements management approaches, their own interpretations of CMMI and MIL-STD-882. Some were excellent engineering organizations. Others had been acquired primarily for contracts or capabilities, not process maturity. The company held them together through financial management and business unit autonomy rather than engineering standardization.

When these two companies merged to form L3Harris, the combined entity inherited both cultures simultaneously. The governance model that emerged—federated business units with significant autonomy, overseen by a corporate engineering function that sets standards but doesn’t mandate toolchains—reflects this inheritance. It was probably the only politically viable approach at the time. Whether it was the optimal long-term approach for systems engineering quality is a different question.

Federated Governance: The Pragmatic Choice and Its Costs

L3Harris’s current approach to systems engineering governance is best described as federated with a common floor. Corporate engineering sets baseline process requirements—CMMI Level 3 compliance on major programs, adherence to specific MIL-STD and AS9100 quality standards, participation in program management review structures. Business units are expected to meet that floor and given latitude to exceed it in ways appropriate to their domain.

The advantages of this model are real. A business unit building night vision devices for the Army has genuinely different engineering challenges than one building space payloads for the NRO. Forcing identical process frameworks onto both would create compliance theater at best and genuine process dysfunction at worst. Domain-specific engineering cultures have value. The teams doing airborne SIGINT integration bring different expertise than the teams doing encrypted tactical radio development, and their process adaptations reflect real knowledge about what works in those domains.

The costs are also real. When programs require integration across business units—which happens with increasing frequency as defense customers demand system-of-systems solutions—the seams show. Requirements pass between organizations that have different conventions for how requirements are structured, different tools for managing them, and different assumptions about what “verified” means. Interface control documents become the load-bearing artifact holding cross-unit programs together, which works but creates fragility. A change on one side of an interface has to be manually propagated, manually reviewed, and manually verified against downstream requirements in another organization’s system.

This is not unique to L3Harris—it’s a structural problem for any large federated prime. But L3Harris’s particular history, with its combination of a precision-engineering culture and a conglomerate-integration culture, makes the variance across units larger than it might be at a prime that grew more organically.

CMMI in Practice Across a Decentralized Structure

L3Harris publicly maintains CMMI Level 3 appraisals across its major programs, and this is genuinely required by many of its government customers. DoD contracts for significant development programs increasingly specify CMMI Level 3 or above as a contractual requirement, and the Space Force and intelligence community customers are particularly rigorous about this.

What CMMI Level 3 means in practice varies more than the certification might suggest. Level 3 requires defined, documented, and consistently applied processes—but “defined” and “consistently” are doing a lot of work in a company with dozens of semi-autonomous business units. The appraisal process evaluates process institutionalization within an organizational scope, and the scope of individual appraisals at a company like L3Harris covers specific business units or program groupings, not the enterprise as a whole.

The result is that CMMI compliance is real but localized. A business unit that builds tactical communications hardware and has been doing it for decades likely has genuinely mature, institutionalized processes that the CMMI Level 3 designation accurately reflects. A business unit that was acquired more recently, or that operates in a domain with more process variability, may meet the letter of CMMI Level 3 while having processes that are less deeply embedded in day-to-day engineering practice.

L3Harris’s corporate engineering function runs process improvement initiatives, conducts internal audits, and works to raise the floor across units. This is meaningful work, and the company has made measurable progress since the merger. But closing the gap between the best and worst performing units in a company this size and this federated is a multi-year effort that is still ongoing.

Digital Engineering Requirements: External Pressure Driving Internal Change

The single largest driver of systems engineering process change at L3Harris over the past three years has not been internal strategy—it has been customer requirements.

The Department of Defense’s Digital Engineering Strategy, published in 2018, has progressively materialized into actual contract requirements. Major programs now carry contractual language requiring authoritative digital models, model-based systems engineering artifacts, and demonstrated traceability from requirements through verification in formats that go beyond document delivery. The Air Force’s digital acquisition initiatives and the Space Force’s explicit preference for digital engineering approaches have accelerated this, particularly for L3Harris’s space and airborne programs.

For a company with deeply embedded document-centric workflows—and L3Harris has many of them, inherited from both Harris and L3 legacy cultures—these requirements create genuine urgency. Delivering a SysML model alongside a System Requirements Document is not simply an additive task. It requires that the model be authoritative, meaning it must be the source of truth for requirements and design decisions, not a post-hoc representation of decisions already made in Word documents. Building that capability requires changing how systems engineers work, what tools they use, and what constitutes acceptable engineering output.

L3Harris has invested in model-based systems engineering capability across multiple business units, with varying depth. Some programs, particularly newer space payload developments and precision weapons programs where the government customer is explicitly requiring it, have made meaningful progress toward genuine MBSE practice. Others are still in the early stages of treating MBSE as more than a compliance artifact.

The toolchain picture is predictably diverse. IBM DOORS and DOORS Next appear across multiple business units, reflecting the installed base that both Harris and L3 brought to the merger. Cameo and other SysML modeling environments are in use on programs where MBSE is genuinely required. The integration between requirements management and modeling tools—the connection that makes traceability real rather than claimed—is an area where L3Harris, like most large primes, continues to work through implementation challenges.

The Night Vision and Space Payload Cases

Two L3Harris domains illustrate the range of systems engineering practice within the company.

Night vision and electro-optical systems—products like the AN/PSQ-20 Enhanced Night Vision Goggle—are mature hardware programs with well-defined specifications, established manufacturing processes, and long production histories. Systems engineering on these programs is primarily about configuration management, manufacturing yield, and managing incremental product improvements without disrupting production stability. The engineering challenge is real, but it is more a quality engineering and configuration management problem than a complex systems integration problem. CMMI-compliant processes work well here because the processes are genuinely repetitive and well-understood.

Space payloads are a fundamentally different engineering challenge. Classified intelligence community payloads require exceptional reliability, cannot be serviced after launch, and carry requirements that are both highly complex and frequently evolving through the development cycle. The government customer is sophisticated and directly engaged in design decisions in ways that are less common on production hardware programs. Systems engineering on these programs requires genuine model-based traceability, rigorous interface management, and formal verification approaches that matter operationally, not just contractually. This is where L3Harris’s heritage from Harris Corporation’s space electronics work is most directly relevant, and where the engineering culture is most aligned with the demands of the work.

The challenge for the combined company is that the engineering culture and process maturity appropriate to space payloads cannot simply be transplanted to the entire enterprise. Nor should it be. But the variation creates real risk when programs or personnel move across domains.

The Integration Problem That Remains

Seven years after the merger, the most honest assessment of L3Harris’s systems engineering integration is that the structural work is largely complete and the cultural work is substantially incomplete.

Organization charts have been reconciled. Business unit boundaries are established. Corporate governance structures exist. The common floor of CMMI and quality standards has been defined and is being enforced. These are real accomplishments for a merger of this complexity.

What is harder to change is the engineering common sense that engineers bring to their work—the assumptions about how requirements should be structured, what level of design detail belongs in a system specification versus a subsystem specification, how interface control documents should be written, what peer review is for, when a requirement is actually verified. These assumptions were formed over careers spent in specific engineering cultures, and they don’t change through policy documents or process training.

The practical consequence is that cross-unit programs—which are strategically important to L3Harris as it pursues integrated solutions rather than individual products—require careful management of the seams where different engineering cultures meet. The best programs do this explicitly, assigning experienced systems engineers to the integration interfaces and using interface control documents as the common language. The programs that struggle tend to be the ones that underestimate the process variance between units and assume that shared corporate process standards mean shared engineering practice.

An Honest Assessment

L3Harris is a genuinely capable defense electronics company doing consequential engineering work across a remarkably broad portfolio. Its systems engineering function is stronger in some domains than others, more mature on some programs than others, and more consistent within business units than across them.

The federated governance model is a reasonable response to the company’s history and scale, not a failure of ambition. Managing systems engineering uniformly across a company that makes night vision goggles, space intelligence payloads, and tactical radios would require either lowest-common-denominator process or enormous overhead. The federated approach accepts process variance as the cost of domain relevance.

The digital engineering transition is the most consequential near-term systems engineering challenge. Government customers are increasingly distinguishing between contractors who have genuinely adopted model-based approaches and those who are producing MBSE artifacts as a compliance exercise. L3Harris’s ability to deliver genuine digital engineering capability—authoritative models, connected traceability, machine-readable verification evidence—will matter for program competitiveness on the programs that matter most.

The merger integration story is not over. The engineering culture convergence that the organizational integration assumed would follow has been slower and more difficult than the structural work. That is normal for mergers of this complexity and ambition. It is also an honest reason why L3Harris’s systems engineering quality, measured rigorously across programs and business units, is more variable than its scale and technical reputation might suggest.

For customers evaluating L3Harris on a specific program, the right question is not about the enterprise—it is about which business unit is leading the work, what that unit’s CMMI appraisal scope covers, and how the program handles the interface with other L3Harris units or external partners. The answers to those questions tell you more about the systems engineering risk than any enterprise-level characterization can.