Compute efficiency does not just affect the balance sheet. Kevin Roney, a leader in data science for government projects, points out that your efficiency determines what you build.
Many organizations treat compute efficiency as a finance problem. Kevin Roney, who recently retired after more than forty years in data science, operations research, modeling and simulation, and most recently as an AI/ML project manager at RTX, argues it is really a decision about what you build.
Efficiency is no longer a nice-to-have
For many years, if you wanted to get more out of your data and AI workloads, you simply upped your budget and spent more on compute and tokens. Roney sees that era ending, especially for the type of organization he spent his career serving.
Right now, especially in the federal government space, teams can no longer throw money at innovation. They need to discover efficiency along the way. As AI-powered tools grow more prevalent, the focus has shifted to the cost of tokens. Roney sees the token bill as a familiar challenge in new packaging.
Before token costs became the topic of discussion, the computational cost explosion associated with machine learning algorithms was the obstacle. The more you wanted to do using machine learning, the more computational time and power it required. And that created a cloud problem, because it consumed significantly more dollars for compute.
The cost line-item changes, but the underlying issue does not. The compute engine doing the work drives up costs.
That is why Roney sees this as a strategy problem rather than an accounting one. When compute spend climbs faster than the value the data returns, the whole data program draws the attention of the CFO. Roadmap items get deferred because the pipeline behind them is too expensive to run continuously. The team that owns batch ETL, streaming, and ML inference spends its time defending a budget instead of developing a product. And the engine underneath never gets examined, because examining it looks like a migration.
Roney focuses on the federal and defense verticals, but the principles are identical for a lean data team at a commercial company. At some point, adding more and more compute stops being a viable strategy.
The traditional model was not designed for today's requirements
Roney views the demands created by machine learning as the source of the issue.
In the machine learning world, data is everything. You use massive data to train the neural networks, develop patterns by which they recognize meaningful information, and then predict outcomes.
Historically, Roney notes, Apache Spark has been one of the primary engines doing that work, and Spark is built on Java. Java's flexibility is real, but so is the trade-off it requires.
Java was designed to be cross-platform capable, at the expense of efficiency.
That trade-off came at a reasonable cost in the past. But the data volume explosion has driven up costs. Machine learning in production means terabytes moving through that engine. Roney sums this up as "a lot of computing activity that's going on."
His example is deliberately ordinary: ride-sharing systems using machine learning to predict which car is closest to a rider. Real-time, Internet-of-things scale, constantly comparing incoming information against outcomes, and in his words, "real-time datasets that cost money to run all that."
Roney concludes that if there is an inefficient engine under the hood processing the data, organizations can find ways to create efficiency and save money.
"Until recently, nobody was really attacking that problem."
Use less fuel to get farther down the road
Roney's simple engine metaphor can be quite useful for anyone trying to explain compute efficiency to a CFO.
Efficiency in the compute layer does not present itself as one benefit; it is a choice between performance and savings.
[
Roney lays it out:
"I can be 80% more efficient, which means reducing cost by using 80% less compute to do what we've been doing. Or I can get 80% more capability, processing 80% more data and information at the same cost."
Roney's engine metaphor can help teams explain more efficient innovation to the finance department.
"For the same amount of fuel, I can go 80% further."
You can add more features to your solution and still spend within your budget.
That is a roadmap statement rather than a savings statement. If the engine driving innovation is more efficient, the budgetary constraint on project scopes is loosened, and work that was previously considered too costly once again becomes possible. In agentic AI specifically, Roney notes, that headroom can mean adding "more agents into the process to create more features" the product needs.
Roney is careful about how much of this is proven in the field. When asked for a finished before-and-after story, he declined to give one because the solutions are still in the early stages: "We're still at the nascent phases of these discoveries of what we can possibly do."
Roney is confident about the opportunity; there just is not a case study he has lived yet.
🚀 Wondering which of those two dimensions your own pipelines would give you? A Test Flight benchmarks Falcon side by side in your environment, on your workloads, before anything changes.
What efficiency unlocks down the road
Roney views efficiency initiatives as roadmap decisions regardless of industry.
Beginning with verticals he knows best, battle management and command and control, Roney says there is value to be found by identifying and prioritizing far more initiatives than a team can possibly act on. This creates an optimization challenge "which is another good utilization of machine learning." In manufacturing and shipbuilding, it is sequencing parts into an assembly line so the schedule holds, and adapting dynamically when it does not, "so that I keep that cycle moving consistently." In maintenance, organizations can shift focus from calendar to machine condition. Rather than waiting for a machine to fail, you can proactively respond when you see certain characteristics from the sensors. Organizations no longer have to defer maintenance based on the calendar; they can act when indicators tell them it's time to do so.
Opportunities like these all have the same dependency. They only exist if processing the data is affordable enough to run continuously.
This is where Haevek's Falcon Compute Platform comes in.
Haevek Falcon gets you further down the road
Haevek's Falcon Compute Platform is a ground-up, Kubernetes-native rebuild of Apache Spark, aimed exactly at the layer Roney describes. Run the same batch, streaming, and AI/ML workloads on a fraction of the compute, without re-platforming the lakehouse around it.
Roney's summary of Haevek's approach is one the CFO can embrace.
"They're not suggesting they're replacing things like Databricks or Cloudera or anything like that. They're saying, hey, we've taken parts of their engines and we've made them super-efficient."
Roney describes Haevek's process as "a relatively straightforward pull out, push in, kind of plug-and-play condition." The warehouse, the governance, the downstream tools, and the team stay where they are. Only the compute moves.
Efficiency lowers what the work costs. Falcon is licensed on tiers based on processor use — a fixed annual cost rather than a usage meter — so the savings show up as a number finance can plan against instead of one that arrives at the end of the quarter.
That is also why Roney thinks the decision belongs on the roadmap rather than only in FinOps review. A more efficient engine is not a line-item that's been cut. It is capacity to do more, go further. That is what funds the next capability.
The part Roney insisted on: check the numbers
Efficiency claims invite skepticism, and Roney's engineering group brought plenty.
Roney's engineering group wanted to examine Haevek's claims. They wanted to know "is this really true?" He continued:
"And so one of the things that Haevek generously did with us, gave us the demonstration licenses, allowed us and worked with our engineering team, and basically over about 60 days we ran a series of internal experiments to come back and essentially prove everything that they were claiming was actually true."
Two things stand out in Roney's Haevek story.
First: the proof happened in their environment, on their workloads, run by their engineers. That is the only kind of benchmark a skeptical engineering group tends to accept.
Second: the team volunteered afterward, unprompted, about Haevek's approach to the work itself. Haevek didn't just hand over software licenses; they worked closely with the engineering group to ensure implementation happened correctly and that the team was able to achieve what it wanted to achieve.
Roney also points to a downstream signal that efficiency reads as innovation in the market, not just as savings. On one bid, the end customer had never heard of Haevek, "but they recognized what they were doing as innovative and were crediting us with that kind of innovation to go out and look at that."
This is why Roney views Haevek's solution as forward-looking rather than transactional.
It's not just what Haevek offers today, but also the innovations they will have in the future. The Haevek team is always looking at new problems and innovating off those problems.
The takeaway
If the compute layer under your pipelines was designed for portability rather than efficiency, you are paying for that design choice every quarter, and you are paying for it twice: once on the invoice, and once with the capabilities you decided you could not afford.
Find out your own potential
Falcon is the compute layer built for this. We offer the 2-4 week Falcon Test Flight to pilot Falcon in your environment with your data. No data moved, no lock-in, training included.