Space Industry Cheat Sheet: Special Report — Accelerating Defense Innovation through Lesson Learned from Commercial Space

Posted on by Austin

How Information Technology Can Transform the Golden Dome Initiative

The Gold­en Dome mis­sile defense sys­tem rep­re­sents Amer­i­ca’s most ambi­tious defense pro­gram since Rea­gan’s Strate­gic Defense Ini­tia­tive. With a $175 bil­lion price tag and the promise to rev­o­lu­tion­ize home­land defense, it high­lights a crit­i­cal chal­lenge: how can the Depart­ment of Defense lever­age com­mer­cial inno­va­tion while man­ag­ing decades of tech­ni­cal debt? The answer lies in trans­form­ing our approach to infor­ma­tion technology.

Commercial Success Stories: The IT Revolution in Space

SpaceX’s Digital-First Philosophy

SpaceX did­n’t just build bet­ter rockets—they built bet­ter infor­ma­tion sys­tems. Their achieve­ments stem from a fun­da­men­tal IT phi­los­o­phy that tra­di­tion­al defense con­trac­tors have strug­gled to replicate.

Ver­ti­cal Inte­gra­tion Through Soft­ware: SpaceX devel­ops approx­i­mate­ly 80% of its soft­ware in-house, from flight con­trol sys­tems to man­u­fac­tur­ing automa­tion. This approach enables rapid iteration—Falcon 9’s flight soft­ware updates week­ly, some­thing unthink­able in tra­di­tion­al aero­space, where soft­ware changes typ­i­cal­ly require years of certification.

Real-Time Data Archi­tec­ture: Every Fal­con 9 gen­er­ates 30 ter­abytes of teleme­try data per flight. SpaceX’s IT infra­struc­ture process­es this in real-time, feed­ing machine learn­ing mod­els that pre­dict fail­ures before they occur. Their Star­link con­stel­la­tion man­ages over 4,000 satel­lites through autonomous sys­tems that would require thou­sands of oper­a­tors using tra­di­tion­al methods.

Dig­i­tal Twin Tech­nol­o­gy: Before Star­ship flies, it exists as a com­plete dig­i­tal mod­el. SpaceX sim­u­lates mil­lions of flight sce­nar­ios to test the inte­gra­tion of soft­ware and hard­ware vir­tu­al­ly. This approach reduced devel­op­ment time from decades to years.

Blue Origin’s Cloud-Native Infrastructure

Blue Ori­gin took a dif­fer­ent path, build­ing cloud-first from day one. Their IT achieve­ments include:

Dis­trib­uted Devel­op­ment: Using AWS, Blue Ori­gin cre­at­ed a devel­op­ment envi­ron­ment that enables engi­neers across the coun­try to col­lab­o­rate on the same dig­i­tal mod­els in real-time. Their New Glenn rock­et was designed entire­ly in the cloud, elim­i­nat­ing the need for phys­i­cal mock­ups until late in the devel­op­ment process.

API-Dri­ven Archi­tec­ture: Every Blue Ori­gin sys­tem expos­es APIs, allow­ing rapid inte­gra­tion of new capa­bil­i­ties. When NASA required mod­i­fi­ca­tions to the lunar lan­der, Blue Orig­in’s IT archi­tec­ture enabled design changes to be imple­ment­ed in weeks rather than months.

Traditional Defense IT Challenges: The Weight of History

Legacy System Burden

The Mis­sile Defense Agency oper­ates sys­tems with roots stretch­ing back to the 1960s—some com­po­nents trace their lin­eage to the orig­i­nal SAGE air defense sys­tem. These aren’t just old; they’re archae­o­log­i­cal lay­ers of tech­nol­o­gy that have been built upon each oth­er over decades.

Pro­gram­ming Lan­guage Archae­ol­o­gy: Crit­i­cal MDA sys­tems still run FORTRAN code writ­ten dur­ing the Nixon admin­is­tra­tion. The Navy’s Aegis Com­bat Sys­tem con­tains mil­lions of lines of ADA code—a lan­guage the Pen­ta­gon man­dat­ed in the 1980s but which com­mer­cial indus­try large­ly aban­doned. Find­ing pro­gram­mers who can main­tain these sys­tems is like find­ing black­smiths; they exist, but they’re expen­sive and increas­ing­ly rare.

Doc­u­men­ta­tion Decay: Sys­tem doc­u­men­ta­tion is scat­tered across mul­ti­ple clas­si­fi­ca­tion lev­els and resides in dif­fer­ent net­works that can’t com­mu­ni­cate with each oth­er. A sin­gle sys­tem might have its require­ments on SIPR, tech­ni­cal spec­i­fi­ca­tions on JWICS, and oper­a­tional pro­ce­dures on unclas­si­fied net­works. Engi­neers spend more time hunt­ing for doc­u­men­ta­tion or try­ing to reverse-engi­neer lega­cy sys­tems than they do modernizing.

Hard­ware Depen­den­cies: Many lega­cy sys­tems depend on hard­ware that’s no longer man­u­fac­tured (or made in the Unit­ed States). The Air Force main­tains a “bone yard” of spare parts for sys­tems that com­pa­nies stopped sup­port­ing decades ago. When crit­i­cal com­po­nents fail, tech­ni­cians some­times can­ni­bal­ize muse­um pieces to repair oth­er equipment.

Policy Barriers to Evolution

Fed­er­al Acqui­si­tion Reg­u­la­tion (FAR) Con­straints: The FAR’s empha­sis on “low­est price tech­ni­cal­ly accept­able” often favors con­trac­tors who promise to main­tain exist­ing sys­tems rather than replace them. Mod­ern­iza­tion appears riski­er and more expen­sive com­pared to incre­men­tal patches.

FISMA Com­pli­ance Bur­den: The Fed­er­al Infor­ma­tion Secu­ri­ty Man­age­ment Act requires exten­sive doc­u­men­ta­tion and test­ing for any sys­tem change. Upgrad­ing a lega­cy sys­tem to mod­ern stan­dards can trig­ger FISMA reviews that take longer than the orig­i­nal devel­op­ment, cre­at­ing per­verse incen­tives to avoid modernization.

NIST Cyber­se­cu­ri­ty Frame­work: While nec­es­sary, the frame­work often con­flicts with lega­cy sys­tem archi­tec­tures. Imple­ment­ing mod­ern secu­ri­ty con­trols on 1980s-era sys­tems is like installing airbags in a Mod­el T—technically pos­si­ble but eco­nom­i­cal­ly questionable.

Stovepiped Data: The Tower of Babel Problem

Each ser­vice built its IT infra­struc­ture to solve its own prob­lems, cre­at­ing incom­pat­i­ble islands of capability:

Air Force: Built around air oper­a­tions cen­ters designed for cen­tral­ized com­mand and con­trol. Their sys­tems excel at man­ag­ing air­space but strug­gle with real-time data shar­ing out­side their domain.

Navy: Devel­oped ship-cen­tric sys­tems opti­mized for blue-water oper­a­tions. Aegis was designed when ships oper­at­ed inde­pen­dent­ly; net­work­ing mul­ti­ple plat­forms requires exten­sive workarounds.

Space Force: Inher­it­ed a mix of Air Force sys­tems and spe­cial­ized space oper­a­tions tools. They’re try­ing to cre­ate uni­fied space domain aware­ness while man­ag­ing dozens of incom­pat­i­ble ground systems.

MDA: Oper­ates as a joint agency but relies on ser­vice-spe­cif­ic net­works and pro­to­cols. Their sys­tems must trans­late between Air Force, Navy, and Army data for­mats in real-time.

Policy-Driven Fragmentation

Gold­wa­ter-Nichols Unin­tend­ed Con­se­quences: The 1986 Act improved joint oper­a­tions but inad­ver­tent­ly rein­forced the devel­op­ment of ser­vice-spe­cif­ic IT sys­tems. Each ser­vice main­tained sep­a­rate “Title 10” respon­si­bil­i­ties, includ­ing its own IT systems.

Com­pe­ti­tion in Con­tract­ing Act (CICA): CICA’s require­ment for com­pet­i­tive bid­ding often pre­vents ser­vices from adopt­ing each oth­er’s suc­cess­ful solu­tions. If the Air Force devel­ops an effec­tive sys­tem, the Navy must still com­pete with it rather than sim­ply adopt­ing it.

COIN-Era Technical Debt

Between 2001 and 2021, the Depart­ment of Defense focused intense­ly on coun­terin­sur­gency oper­a­tions. This was­n’t just a strate­gic shift—it was an IT trans­for­ma­tion that cre­at­ed last­ing tech­ni­cal debt:

Tac­ti­cal Over Strate­gic: DoD invest­ed heav­i­ly in tac­ti­cal com­mu­ni­ca­tions and intel­li­gence sys­tems for small-unit oper­a­tions. Strate­gic sys­tems, such as mis­sile defense, received main­te­nance fund­ing but lit­tle invest­ment in modernization.

Com­mer­cial Off-the-Shelf (COTS) Addic­tion: COIN oper­a­tions demand­ed rapid deploy­ment of new capa­bil­i­ties. DoD became addict­ed to COTS solu­tions that worked imme­di­ate­ly but cre­at­ed long-term inte­gra­tion nightmares.

Net­work Pro­lif­er­a­tion: Each the­ater spawned its own networks—CENTRIXS for coali­tion oper­a­tions, SIPR for clas­si­fied com­mu­ni­ca­tions, and JWICS for top-secret data. These net­works could­n’t talk to each oth­er by design, but the iso­la­tion became permanent.

The Compounding Effect

These chal­lenges don’t exist in isolation—they rein­force each other:

  1. Lega­cy sys­tems resist inte­gra­tion, rein­forc­ing stovepipes
  2. Stovepipes pre­vent mod­ern­iza­tion pressure
  3. Tech­ni­cal debt accu­mu­lates with each patch and workaround
  4. Poli­cies writ­ten for old­er tech­nolo­gies become bar­ri­ers to new­er approaches

The result is an IT envi­ron­ment where change is expen­sive, risky, and slow—the oppo­site of what Gold­en Dome requires. This under­scores the urgent need for mod­ern­iza­tion in our defense systems.

Barrier Analysis: Why IT Modernization Stalls

The Middle Management Firewall

The most sig­nif­i­cant bar­ri­er isn’t technical—it’s human. Mid­dle man­agers who built careers on lega­cy sys­tems often resist change. They’re not obstruc­tion­ist by nature; they’re pro­tect­ing what works while remain­ing skep­ti­cal of unproven alternatives.

Pro­gram man­agers jug­gle hun­dreds of require­ments doc­u­ments but lack mod­ern project man­age­ment tools. They rely on Pow­er­Point and Excel because that’s what their review­ers expect. Intro­duc­ing agile devel­op­ment or DevSec­Ops requires chang­ing not just tools but entire work­flows.  (Author’s Note:  I am not ful­ly con­vinced that JIRA is the fix action tool for mod­ern DevSec­Ops either.)

Architectural Opacity

Gold­en Dome’s lack of OV‑1 (Oper­a­tional View) and OV‑2 doc­u­men­ta­tion cre­ates cas­cad­ing IT prob­lems. With­out clear archi­tec­ture dia­grams show­ing data flows and sys­tem inter­ac­tions, con­trac­tors build incom­pat­i­ble solu­tions. Each inter­cep­tor type might use dif­fer­ent data for­mats, com­mu­ni­ca­tion pro­to­cols, and secu­ri­ty frameworks.

This opac­i­ty par­tic­u­lar­ly impacts IT plan­ning. How can you design net­works, data­bas­es, and pro­cess­ing sys­tems with­out know­ing what con­nects to what? Com­mer­cial com­pa­nies start with archi­tec­ture; Gold­en Dome appears to be design­ing it retroactively.

Security Theater vs. Security Engineering

Clas­si­fi­ca­tion require­ments cre­ate IT night­mares. Sys­tems that should share data can’t because they oper­ate at dif­fer­ent clas­si­fi­ca­tion lev­els. The irony is that com­mer­cial satel­lites often col­lect bet­ter imagery than clas­si­fied sys­tems, but inte­grat­ing that data requires months of secu­ri­ty reviews.

Adaptation Strategies: Bridging the Gap

Immediate IT Wins

Con­tainer­iza­tion: Deploy appli­ca­tions in con­tain­ers that work across dif­fer­ent envi­ron­ments. If SpaceX soft­ware can run on a rock­et, it can run in a DoD data center.

API Man­dates: Require all Gold­en Dome con­trac­tors to expose APIs. No more pro­pri­etary inter­faces that lock in ven­dors and pre­vent integration.

Cloud-First Devel­op­ment: New sys­tems should be born in the cloud, even if they even­tu­al­ly run on-premis­es. This neces­si­tates mod­ern archi­tec­ture deci­sions, with the under­stand­ing that data cen­ters must be host­ed on U.S.-controlled instal­la­tions. Host­ing on U.S.-controlled instal­la­tions means that, regard­less of the JWCC solu­tion, it will allow the Depart­ment of War to place cloud capa­bil­i­ties in over­seas locations.

Cultural Transformation

Dig­i­tal Natives in Lead­er­ship: Pro­mote offi­cers and civil­ians who under­stand mod­ern IT. The Space Force is already doing this—their youngest ser­vice mem­bers have grown up with the tech­nol­o­gy and eas­i­ly grasp the concepts.

Com­mer­cial Rota­tions: Assign defense IT per­son­nel to work at SpaceX, Blue Ori­gin, or lead­ing IT solu­tion providers for six months. They’ll return with new per­spec­tives and contacts.

Fail Fast Per­mis­sions: Cre­ate sand­box­es where teams can exper­i­ment with­out fear of career dam­age. SpaceX blows up rock­ets to learn; DoD should blow up bad IT ideas ear­ly and cheap­ly, hence the need for Dig­i­tal Twin envi­ron­ments to experiment.

Architectural Transparency

Open Stan­dards: Man­date the use of open stan­dards for all Gold­en Dome com­mu­ni­ca­tions. If com­mer­cial com­pa­nies can build com­pat­i­ble sys­tems, com­pe­ti­tion increas­es, and costs decrease.

Dig­i­tal Thread Require­ments: Every Gold­en Dome com­po­nent must con­tribute to a dig­i­tal thread—a com­plete data pic­ture from sen­sor to shoot­er. Dig­i­tal Thread requires stan­dard­ized data for­mats and real-time shar­ing, increas­ing effi­cien­cy in oth­er aspects of the kill chain.

Policy Recommendations: Making IT Innovation Possible

Acquisition Reform

Mod­u­lar Con­tract­ing: Break mas­sive pro­grams into small­er IT chunks. Instead of hav­ing one con­trac­tor build every­thing, let spe­cial­ists com­pete for spe­cif­ic pieces. SpaceX did­n’t build Star­link’s user ter­mi­nals; they part­nered with experts to devel­op them.

Per­for­mance-Based Pay­ments: Pay for IT out­comes, not effort. If a sys­tem suc­cess­ful­ly shares data with part­ners, the con­trac­tor receives pay­ment. If inte­gra­tion fails, they fix it at their own expense.

Regulatory Relief

Commercial Data Rights: Balancing Innovation and Investment Protection

The cur­rent data rights frame­work forces an arti­fi­cial choice: either the gov­ern­ment gets unlim­it­ed rights and con­trac­tors lose com­mer­cial incen­tives, or con­trac­tors retain rights, and the gov­ern­ment can’t effec­tive­ly inte­grate sys­tems. Gold­en Dome needs a third option.

The Inno­va­tion Dilem­ma: Com­mer­cial space com­pa­nies invest bil­lions in R&D because they can com­mer­cial­ize their inno­va­tions, gen­er­at­ing sig­nif­i­cant returns. Tra­di­tion­al defense con­trac­tors accept lim­it­ed com­mer­cial rights because they’re com­pen­sat­ed through cost-plus con­tracts. The Gold­en Dome requires rapid com­mer­cial inno­va­tion, with defense inte­gra­tion requirements.

Pro­posed Dual-Rights Frame­work:

  1. Com­mer­cial Rights Retained: Con­trac­tors keep full intel­lec­tu­al prop­er­ty rights for com­mer­cial ver­sions of their tech­nol­o­gy. SpaceX can sell Star­link glob­al­ly while pro­vid­ing Starshield to the DoD.
  2. Gov­ern­ment Rights Guar­an­teed: The DoD is grant­ed unlim­it­ed rights to use, mod­i­fy, and inte­grate defense-spe­cif­ic ver­sions of the soft­ware. This includes access to source code, mod­i­fi­ca­tion rights, and the abil­i­ty to have oth­er con­trac­tors main­tain systems.
  3. Tech­nol­o­gy Trans­fer Incen­tives: Cre­ate tax incen­tives for com­pa­nies that devel­op dual-use tech­nolo­gies. If a com­pa­ny’s com­mer­cial invest­ment ben­e­fits defense appli­ca­tions, it should receive R&D tax cred­its pro­por­tion­al to the defense benefit.

Spe­cif­ic Imple­men­ta­tion Mech­a­nisms:

  1. Mod­u­lar IP Archi­tec­ture: Require con­trac­tors to sep­a­rate core com­mer­cial tech­nol­o­gy from defense-spe­cif­ic mod­i­fi­ca­tions. The com­mer­cial core remains pro­pri­etary; defense mod­i­fi­ca­tions become gov­ern­ment property.
  2. Rev­enue Shar­ing Mod­els: For tech­nolo­gies devel­oped with gov­ern­ment fund­ing, estab­lish rev­enue-shar­ing agree­ments in which con­trac­tors pay roy­al­ties on com­mer­cial sales back to the DoD for rein­vest­ment in future programs.
  3. Open Stan­dards Com­pli­ance: Man­date that all defense-spe­cif­ic mod­i­fi­ca­tions use open stan­dards for inter­faces and data for­mats. Open Stan­dard Com­pli­ance also pre­vents ven­dor lock-in while pre­serv­ing com­mer­cial IP.

Legal Frame­work Changes: This requires amend­ments to the Defense Fed­er­al Acqui­si­tion Reg­u­la­tion Sup­ple­ment (DFARS) and poten­tial­ly new leg­is­la­tion. The frame­work should be test­ed on the Gold­en Dome before being imple­ment­ed more broadly.

Organizational Changes

Joint IT Task Force: Breaking Down Institutional Barriers

The cur­rent acqui­si­tion sys­tem treats IT as a sup­port func­tion rather than a core capa­bil­i­ty. Gold­en Dome requires IT-cen­tric think­ing from the start, not as an afterthought.

Pro­posed Struc­ture: Estab­lish the Gold­en Dome Inte­gra­tion Task Force (GDITF) as a joint orga­ni­za­tion with unprece­dent­ed authority:

Mem­ber­ship and Author­i­ty:

  1. Ser­vice Rep­re­sen­ta­tives: O‑6 lev­el offi­cers from Air Force, Navy, Space Force, and MDA with direct bud­get author­i­ty for their ser­vice’s Gold­en Dome contributions
  2. Com­mer­cial Part­ners: Senior tech­ni­cal exec­u­tives from major con­trac­tors with deci­sion-mak­ing author­i­ty, not just liai­son officers
  3. Tech­ni­cal Author­i­ty: Pow­er to man­date tech­ni­cal stan­dards, reject incom­pat­i­ble solu­tions, and real­lo­cate fund­ing between services

Oper­a­tional Frame­work:

  1. Week­ly Inte­gra­tion Reviews: Manda­to­ry tech­ni­cal reviews where all par­tic­i­pants demon­strate sys­tem inter­op­er­abil­i­ty, not just a brief on progress
  2. Stan­dards Enforce­ment: Author­i­ty to reject any sys­tem that does­n’t meet inte­gra­tion stan­dards, regard­less of ser­vice pref­er­ences or con­trac­tor relationships
  3. Bud­get Real­lo­ca­tion: Abil­i­ty to move fund­ing from non-com­pli­ant pro­grams to suc­cess­ful inte­gra­tion efforts

Deci­sion-Mak­ing Process:

  1. Con­sen­sus Build­ing: Tech­ni­cal deci­sions require agree­ment from both gov­ern­ment and com­mer­cial representatives
  2. Esca­la­tion Author­i­ty: Dis­putes that can’t be resolved at the task force lev­el go direct­ly to the Sec­re­tary of Defense, bypass­ing tra­di­tion­al ser­vice channels
  3. Rapid Pro­to­typ­ing Bud­get: $500 mil­lion annu­al bud­get for rapid inte­gra­tion exper­i­ments and proof-of-con­cept demonstrations

Suc­cess Met­rics:

  1. Inte­gra­tion Speed: Time from con­cept to work­ing pro­to­type across ser­vice boundaries
  2. Cost Effi­cien­cy: Reduc­tion in dupli­cat­ed efforts and incom­pat­i­ble systems
  3. Tech­ni­cal Per­for­mance: Demon­strat­ed inter­op­er­abil­i­ty in real­is­tic test scenarios

CTO Empowerment: Technical Leadership with Real Authority

Tra­di­tion­al pro­gram man­age­ment focus­es on sched­ule and bud­get com­pli­ance. The Gold­en Dome needs tech­ni­cal lead­er­ship that can make archi­tec­tur­al deci­sions with imme­di­ate imple­men­ta­tion authority.

Pro­posed Gold­en Dome CTO Struc­ture:

Report­ing Rela­tion­ship: The CTO reports direct­ly to Gen. Michael Guetlein (Gold­en Dome pro­gram direc­tor) with a direct line to the Sec­re­tary of Defense for tech­ni­cal dis­putes. This bypass­es tra­di­tion­al acqui­si­tion hier­ar­chies that slow tech­ni­cal decisions.

Bud­get Author­i­ty: The CTO con­trols a $2 bil­lion annu­al bud­get specif­i­cal­ly for:

  1. Inte­gra­tion Tech­nolo­gies: Soft­ware, net­works, and data sys­tems that con­nect Gold­en Dome components
  2. Rapid Pro­to­typ­ing: Quick-turn devel­op­ment of crit­i­cal capabilities
  3. Com­mer­cial Part­ner­ships: Direct con­tracts with inno­v­a­tive com­pa­nies for spe­cif­ic tech­ni­cal solutions

Tech­ni­cal Author­i­ty: The CTO has veto pow­er over any tech­ni­cal deci­sion that affects sys­tem inte­gra­tion, including:

  1. Inter­face Stan­dards: All Gold­en Dome sys­tems must use CTO-approved interfaces
  2. Data For­mats: Stan­dard­ized data for­mats across all sen­sors, proces­sors, and weapons systems
  3. Secu­ri­ty Archi­tec­tures: Uni­fied approach to cyber­se­cu­ri­ty and infor­ma­tion assurance

Staffing Mod­el: The CTO office should include:

  1. Tech­ni­cal Direc­tors: Senior engi­neers from each ser­vice, plus com­mer­cial indus­try rotations
  2. Inte­gra­tion Teams: Mixed gov­ern­ment-con­trac­tor teams focused on spe­cif­ic tech­ni­cal challenges
  3. Inno­va­tion Labs: Ded­i­cat­ed facil­i­ties for rapid pro­to­typ­ing and test­ing new concepts

Per­for­mance Met­rics: The CTO’s suc­cess should be mea­sured by:

  1. Sys­tem Inte­gra­tion Speed: Time to achieve inter­op­er­abil­i­ty between new components
  2. Tech­ni­cal Risk Reduc­tion: Ear­ly iden­ti­fi­ca­tion and mit­i­ga­tion of inte­gra­tion challenges
  3. Inno­va­tion Adop­tion: Rate of com­mer­cial tech­nol­o­gy inte­gra­tion into defense systems

Imple­men­ta­tion Time­line: The CTO posi­tion should be estab­lished with­in 90 days, with full staffing and bud­get author­i­ty to be imple­ment­ed with­in six months. The des­ig­na­tion of the Gold­en Dome of Amer­i­ca’s CTO requires imme­di­ate action to avoid fur­ther delays in Gold­en Dome development.

Legal and Pol­i­cy Frame­work: This struc­ture requires new DoD direc­tives estab­lish­ing the CTO’s author­i­ty and poten­tial­ly leg­is­la­tion to ensure bud­get con­trol across ser­vice bound­aries. The posi­tion should be mod­eled on suc­cess­ful com­mer­cial CTOs who have both tech­ni­cal exper­tise and busi­ness authority.

These expand­ed rec­om­men­da­tions address the fun­da­men­tal chal­lenge fac­ing Gold­en Dome: how to achieve com­mer­cial-speed inno­va­tion with­in defense acqui­si­tion con­straints. Suc­cess requires not just new poli­cies but new orga­ni­za­tion­al struc­tures that pri­or­i­tize tech­ni­cal inte­gra­tion over tra­di­tion­al bureau­crat­ic processes.

The Path Forward

Gold­en Dome can suc­ceed where Strate­gic Defense Ini­tia­tive failed, but only if we learn from the com­mer­cial space sec­tor. The tech­nol­o­gy exists—SpaceX tracks thou­sands of objects simul­ta­ne­ous­ly, Blue Ori­gin sim­u­lates entire mis­sions dig­i­tal­ly, and both iter­ate faster than tra­di­tion­al defense con­trac­tors thought possible.

The real chal­lenge is insti­tu­tion­al. We must con­vince mid­dle man­agers that change strength­ens rather than threat­ens their posi­tions. We need acqui­si­tion offi­cials who under­stand APIs as well as cost-plus con­tracts. Most crit­i­cal­ly, we need IT archi­tec­tures that assume inte­gra­tion from the start, not as an afterthought.

The com­mer­cial space indus­try proved that infor­ma­tion tech­nol­o­gy can trans­form hard­ware indus­tries. Gold­en Dome’s suc­cess depends not on build­ing bet­ter inter­cep­tors, but on build­ing bet­ter sys­tems to con­trol them. The ques­tion isn’t whether DoD can adapt com­mer­cial IT innovations—it’s whether we can do it fast enough to matter.

Time is not on our side. While we debate require­ments, adver­saries deploy capa­bil­i­ties. While we pro­tect lega­cy sys­tems, threats evolve beyond their capa­bil­i­ties. Gold­en Dome rep­re­sents our chance to leap ahead, but only if we’re will­ing to leave out­dat­ed IT approach­es behind.

The blue­print exists in Hawthorne and Kent, where SpaceX and Blue Ori­gin build the future. The only ques­tion is whether the Pen­ta­gon is ready to fol­low it.