Success-Plan Services
Rob Proctor
Golden Dome will not succeed or fail based on any single interceptor, radar, or algorithm. It will succeed or fail based on whether its architecture can evolve continuously, without conflicting with legacy systems or overburdening development teams.
That makes Golden Dome a digital engineering problem first.
Why Traditional Integration Will Not Scale
Many of the constituent capabilities that Golden Dome depends on already exist. Proven systems such as Aegis, IBCS, THAAD, and SPY-6, along with emerging counter-UxS capabilities demonstrate that the United States knows how to build world-class defensive systems.
The challenge is not capability creation. The challenge is sustained integration at scale.
Traditional approaches rely on tightly coupled integrations, static interface control documents, and milestone-driven synchronization. Those approaches struggle when systems evolve slowly. Golden Dome will evolve continuously.
New sensors will appear. AI-enabled components will adapt faster than platforms. Systems fielded years apart will be expected to work together as one coherent defense solution. Architectures designed for point-to-point integration or consensus-first data models will become brittle long before Golden Dome reaches operational maturity.
Therefore, Golden Dome requires an engineering approach that assumes change, not stability.
Digital Engineering Must Be Executable
Figure 1: DoD Data Framework from DoD AD1112684
Digital engineering is sometimes reduced to tooling or documentation. Models are created, reviewed, and archived. Diagrams look clean, but their relationship to operational reality is often indirect.
That is not sufficient for Golden Dome.
For a system of this scale, digital engineering must be executable. Models must connect to data. Architectures must be exercised against real and representative behaviors. Feedback from operations, test, and simulation must flow back into the engineering environment continuously. For example: when a new sensor or decision service is introduced, teams should be able to test behavior, timing constraints, and failure modes in simulation before fielding. Executable engineering turns change into something you can evaluate, not just document.
A digital architecture that cannot execute is just documentation. This is where model-based systems engineering becomes foundational, not perfunctory.
MBSE as the Contract Between Organizations
Golden Dome will span contractors, services, and decades. No single organization will own the entire system, but everyone must agree on how it behaves.
Model-Based System Engineering (MBSE) provides that shared contract.
When used properly, MBSE establishes common semantics, traceability, and intent across organizational boundaries. Mission objectives can be traced to system behaviors, interfaces, and data exchanges. Changes can be reasoned about before they are fielded.
Emerging standards such as SysML v2 matter here because they enable models to be machine-consumable, not just human-readable. This opens the door to automation, reuse, and integration with simulation and runtime systems.
MBSE becomes truly powerful when it stops being a deliverable and starts being a living interface between engineering and execution1.
Digital Twins Are Not Just Visualizations
Figure 2: Layered digital engineering architecture connecting DoD data frameworks to composable digital twin technologies and operational systems.
The term “digital twin” is used widely in defense, often to describe high-fidelity visual models or immersive environments. Those representations are valuable, but they are not sufficient for Golden Dome. A twin only earns the name if it stays synchronized with real data for a defined purpose.
Golden Dome needs digital twins that represent mission behavior, system interactions, and data flows. It needs twins that operate at multiple levels of fidelity and scope, depending on the question being asked. Some twins will support design. Others will support testing, training, sustainment, or operational analysis.
As defined in DoDI 5000.97, a digital twin must be an authoritative, data-synchronized counterpart of a real system, built for a clearly defined purpose.
A digital twin that cannot ingest operational data is not a twin. It is a mockup.
The Missing Link Is a Data-Centric Architecture
Digital engineering, MBSE, and digital twins all fail without a consistent way to feed models, simulations and twins with data at scale.
Golden Dome will have many producers and many consumers of data. Systems will be added, removed, and upgraded over time. Data must outlive individual platforms and remain usable across domains and missions.
This is why data-centric architectures matter.
Rather than hard-wiring systems together, a data-centric approach decouples producers from consumers. Interfaces are defined by shared data models and governed semantics, not bespoke integrations. Systems can evolve independently while remaining interoperable.
The data model is the interface.
Standards such as Data Distribution Service (DDS®) – which RTI Connext® is built on – provide the execution fabric that allows this model to operate in real time, at scale, and across security boundaries. They enable late binding, quality-of-service control, and resilient data sharing that aligns with the realities of multi-domain defense systems.
From Digital Thread to Digital Feedback Loop
Golden Dome cannot rely on a one-way digital thread from requirements to deployment. It needs a closed feedback loop.
Models must inform simulation. Simulation must inform deployment. Deployment must generate data. That data must refine the models.
Figure 3: Continuous digital engineering feedback loop connecting models, simulation, deployment, and operational data, which will be essential for Golden Dome.
This loop enables earlier discovery of integration issues, faster insertion of new capabilities, and reduced lifecycle risk. It also enables digital twins to mature alongside the systems they represent, rather than diverging from reality over time.
Patrick Buckley, PhD’s and my recent work validating a digital twin taxonomy across real defense programs demonstrates that this approach is achievable today3. By managing fidelity, scope, and maturity explicitly, digital twins become composable assets rather than isolated artifacts.
The Real Measure of Success
Golden Dome will never be finished. Its success depends on whether it can evolve faster than the threats it is designed to counter.
That requires more than advanced sensors or interceptors. It requires an engineering backbone that connects intent to execution, models to data, and data back to decisions.
Digital engineering, MBSE, digital twins, and data-centric architectures together form that backbone. When combined with proven standards and disciplined execution, they enable Golden Dome to adapt, scale, and endure.
That is the real measure of success.
1For further details, explore RTI integrations with MBSE tools and technologies:
About the author:
Rob Proctor is a Staff Field Application Engineer for Real-Time Innovations. He has over 28 years of experience in A&D Embedded Software as a Software Engineer and Field Applications Engineer. Prior to his time as a Field Application Engineer, he developed and implemented real time embedded software at major Aerospace and Defense Corporations. His roles have included developing software and system designs, mission-management and display processing systems. Rob received his BS from Embry-Riddle Aeronautical University in Aerospace Studies and his MS from the University of South Florida in Engineering Management.