The Decision Layer: ATLAS Space Operation’s Brad Bode

“Great software has a strong separation of concerns, and our industry has been ignoring that.”
– Brad Bode, Co-Founder and CTO, ATLAS Space Operations

The Decision Layer explores how senior technology leaders approach the responsibilities that come with executive‑level oversight and how they frame the decisions that move a space organization forward. With this first installment, we’re opening a dialogue that brings these innovation‑shaping perspectives into focus.

In this installment, we speak with Brad Bode, ATLAS Space Operations’ chief technology officer and co-founder – and the mind behind much of the company’s ground system innovation.

With more than two decades of aerospace software development experience, Bode has built mission-critical systems for satellite command and control, mission planning and data management, securing multiple patents in the process. He is the architect behind Freedom, ATLAS’s ground software-as-a-service platform that has supported hundreds of thousands of satellite passes and significant global data flows.

Bode has also driven key integrations that expanded ATLAS’s federated ground network – now spanning more than 50 antennas across 34 sites in 20 countries. He holds a Master of Science in Computer Science from Northern Illinois University.

Q. You’ve spent more than 20 years building software for space missions. What has changed most in the way you think about technology strategy since you first started working in the industry?

A. You have to split my 26 years in half. The first half was big aerospace: exquisite, high-functioning systems that often overrun on cost, built under process and procedure that stifle innovation. The second half has been startup life, where innovation moves so fast you can get ahead of what the market wants. That shift taught me something about the government as a customer: Give them what they want! It will often frustrate you, because you can see a better solution; however, there is so much happening behind the scenes that the bold, elegant answer just isn’t possible.

From a product perspective, though, not much has changed. We always planned to capture the data pipeline first, then layer on services that make the quality of service more robust, secure and feature-rich. We are extending that now with Gateway, our software that goes deeper into the customer’s environment. It delivers data to the last mile no matter where that is, and it chooses the best algorithm to transport the data.

Q. You’ve worked across C2, mission planning, data management and ground infrastructure. Where do you think those pieces of the space technology stack are converging, and where do they need to remain separate?

A. They should converge at the interface and stay separate underneath it. Ground and mission software should meet at one clean API and data pipe, so a C2 or mission planning system can request passes and receive data without knowing how the antennas, modems or backhaul work. Behind that interface they should remain separate products, with separate code and separate expertise. Ground systems software is a utility vertical. It controls and monitors ground hardware; runs 24/7 network operations; handles licensing, backhaul, security and unified scheduling; and delivers data the last mile. Mission software (C2, mission planning, payload analysis) is about the satellite itself: its health, its commanding, its flight dynamics.

Historically we lumped it all together as “ground systems,” and that overly broad scope is the root of the problem. Think of it as an electrical grid and a smart home app. The grid doesn’t care which app you plug into it, and the app shouldn’t have to know how the grid works. When a C2 provider also has to become an expert in ground station integration, you get the same costly, duplicate integration over and over across the industry. Great software has a strong separation of concerns, and our industry has been ignoring that. Let the ground own every layer that delivers the data: the physics, the pipes and the software on top that makes delivery reliable. Let the mission side handle the logic and the scheduling. That software is what helps the ground deliver on its promise and a high quality of service, like our Insights anomaly detection and root-cause classifier, which tells an operator in real time whether a bad pass was a ground issue or a spacecraft issue. We can build that because we know ground. It’s what we do and it’s the quality promise we make to our customers.

Q. ATLAS has gone from building a ground network to operating a federated network that can incorporate infrastructure from other providers. How has that experience changed your thinking about what a space company actually needs to own?

A. I wouldn’t say it changed my thinking. A federated network was the vision from day one, and it was always the right business model. We actually didn’t want to own any hardware. Then we won a NOAA contract for an antenna in Ghana, and that gave us the chance to prove our technology. At this stage it’s well established that there is plenty of room for many ground infrastructure providers leveraging shared hardware. It is important to remember that owning equipment is not the goal. The goal is the data, and hardware is simply what is required to obtain it. We are seeing a growing number of companies that want end-to-end solutions: build, launch and operate, then deliver the data so they can make the business model profitable. That is exactly what a federated model is built for.

Q. You’ve argued that ground software has been approached incorrectly at an architectural level. What do you think that says about the way the space industry tends to make technology and procurement decisions more broadly?

A. Look at the network stack. Nobody building a web application worries about the physical layer or how packets get routed. Each layer does one job and exposes a clean interface to the layer above. Ground belongs in the lower layers, the physics and the pipes. C2 and mission software are the application layer. The space industry never made that separation, so often applications keep reintegrating the layers underneath it. Government procurement drives much of this, largely because large primes are incentivized to deliver custom solutions, while reusable, commercial products cost less. The government also asks for commercial solutions and then applies government-specific requirements, such as hardware collocated at the site, zero security flexibility and adherence to legacy interfaces.

There is a human side as well. Taking big technology swings isn’t advantageous if you are looking to further your career in the military. Shifting the government technology stack is already hard and risky, and they want a win in the short time they are in the role. The result is a focus on small, technologically, but procedure heavy, wins over long-term solutions. The job of a GSaaS company is to own the whole stack for data delivery, including easy-to-use interfaces to space data and real-time fault location. It’s the ground’s job to tell the satellite operations team whether their pass was successful and, if not, whether the fault is on the ground or the spacecraft, so they can triage instantly. That way operators don’t need to understand every aspect of ground (baseband, LNA, HPA and so on). If the pass worked, they can begin looking in their hardware stack.

Q. With cloud infrastructure, optical communications, Space Relay and increasingly software-defined systems changing the ground segment, which technology shifts do you think will fundamentally change the architecture of space operations rather than simply add another capability?

A. Cloud infrastructure has already made its mark on the architecture of space operations. Shared infrastructure has driven down per-minute pricing and the overall capex of satellite operations. Operators no longer need to buy their own modems, antennas and so on. Space Relay and crosslinking, whether optical or high-data-rate RF, will likely have the biggest impact. Billions of dollars in capex have been spent building the largest geographic footprint possible, and quality relay will concentrate that further and commoditize it. More data will come down, and there will be many gateways, but they will be less geographically dispersed. That is a huge architectural change, and a change in mindset for satellite operators.

It also isn’t easy:

• Capex will need to be spent on relay terminals (optical or RF).
• Entire new satellites will need to be built to take advantage of it.
• Entire companies have tried and failed to build a commercial solution for high-rate relay.

The risk is high, but so is the reward. Security will also have an outsized impact. AI is opening up new methods of attack, and the company with the fewest attack vectors will be best positioned. For instance, we don’t allow companies to put hardware at our sites. That’s one more firewall and a rack full of exploitable hardware we don’t have to defend.

Q. As CIO and CTO, you’re looking at technology from both the product and enterprise sides. How do you balance investing in what can create an advantage for ATLAS with investing in infrastructure that you think the broader space ecosystem needs?

A. For us it isn’t a tradeoff. When you build products, you need one common focus, and ours is giving customers the highest quality service. That’s why we build smart pipes to space, not plain infrastructure-as-a-service. Three things flow downstream from that focus. The first is reducing the time to integrate and making it easier to scale, which is what Freedom Pass Server, Gateway, Edge, and Copilot software are for. The second is real-time triage of root cause, through anomaly detection and classification in our Insights feature. The third is assured security and assured data delivery. So we invest in one thing: the highest quality service, wherever it leads. Sometimes that’s new features. Sometimes it’s a new antenna location, new bands or an entirely new offering like mobile systems.

Q. What’s a lesson from building and scaling ATLAS that has changed the way you approach technology decisions today?

A. As a startup founder you learn to operate in scarcity. Then you hit the transition where you can hire and spend capital to grow, and you have to change your frame of reference. Technology that once seemed inaccessible is suddenly within reach, and that opens up much larger possibilities. At this stage I can think bigger, move faster, and deliver in a way I couldn’t in a constrained environment.