In this episode of CTV, we go deep into one of the more interesting business models and transition stories out there. Apogee Research is a small engineering firm that developed one the Defense Department’s latest solution to the age-old challenge of interoperability. Over seven years, Apogee not only engineered a technical solution, but helped build a constituency for the tool chain inside the ecosystem, and equipped warfighters with the know-how to use it.
In this episode I spoke with David Gerson, the firm’s Vice President, about how they engineered from transition, how building for defense is different, and what the future may hold. Check it out and let me know what you think! And if you like it, please don’t forget to share and subscribe!
⏲️Timestamps ⏲️
2:43 – Introduction to Apogee Research
6:36 – The Apogee model
13:00 – What it means to build for transition
17:00 - Helping program managers craft great programs
20:28 – How Apogee partners
26:07 – Why interoperability is hard for DoD
29:20 – The genesis of DARPA’S SoSITE Initiative
33:59 – How DARPA works
37:50 – Why global standards fail
46:36 – The STITCHES customer discovery process
50:00 – Running the Gauntlet: Building buy-in among user communities
54:20 – Finding a transition partner
57:30 – Contracting for transition
1:04:49 – The future of defense technology
Case Study: “Change from Within” - building for Transition inside DoD
Overview
Apogee Research is a small engineering organization co-founded by Evan Fortunato, an entrepreneur and nuclear engineer who changed his career focus after 9/11. After stints at BAE and as a DARPA Program Manager in the Information Innovation Office (I2O), he founded Apogee as a services firm that could gather some of the brightest technical minds and deploy them in service of deep technical challenges.
He was joined in 2017 by David Gerson, an aerospace engineer who interned at NASA and DARPA, and then went on to serve as a product lead for the Falcon Vehicle program at SpaceX. David joined Apogee originally as a research engineer, and worked his way up to become the firm’s Vice President, where he oversees program execution and business development across the company’s portfolio of projects.
Company Snapshot
Head count: 51 (~37 engineers, 73%)
Federal Contracts: >40 since founding
Thanks to our friends at Procure.FYI for these numbers!
The Apogee Approach
Apogee is different from many of the commercial or product-led companies you typically hear about in the defense tech space. Their guiding light is an internal assessment of impact, and their approach embraces “change from the inside,” or working with the system.
While some preach system overhaul, David, Evan and team believe in learning the rules of the game, and playing within them. They work within the processes and bureaucracies that make up the defense ecosystem, rather than pressuring them to change from the outside. Part of that is why they’ve embraced the ethos, “small is beautiful.” The culture of the company is to remain a small, gritty, hands-on team rather than scale to become a large services provider or focus on margin. That is a marked difference that allows them to define success differently.
Next, Apogee is exclusively a services firm. They sell engineering labor, not products or licenses or intellectual property (they give it an MIT license).
Finally, Apogee is solely federally-focused. They are not a dual-use firm, and don’t have aspirations of commercializing their technology. They are purists, and they are solely focused on the federal market.
In addition to tackling interoperability (which we’ll get into in a minute), Apogee has a strong point of view on the need for heterogeneous digital infrastructure (e.g., the belief that Defense Department dependence on any one system or cloud environment would be problematic), and is beginning to wade into the discussion on Authorizations To Operate - a key process that will need innovations to allow accelerated integrations and deployments of new capability..
To illuminate one particular transition effort, let’s dive deep into perhaps the most notable effort that Apogee has been a part of: STITCHES.
The STITCHES Case
STITCHES, or “System of Systems Technology Integration ToolChain for Heterogeneous Electronic Systems” came out of DARPA, and has become an Air Force Program of Record run out of the Air Force Acquisition / Special Programs organization called AQL. STITCHES is not a normal capability, not built by a normal team, and did not follow a normal transition pathway – which is why we’re excited to break it all down in this case.
DARPA’s initiative to improve connectivity in the military started as an initiative called “System of Systems Integration Technology and Experimentation,” or SoSITE.
The heart of the problem was interoperability: different U.S. government systems had different standards or communications protocols, making it extremely difficult for them to communicate with one another. When you add in all the different service branches, networks, classification levels, and then layer in international organizations and allies (NATO, 5Eyes, AUKUS, etc.) information sharing becomes nearly untenable. The result was a constellation of manual processes that took too much time, introduced too much risk, and hindered mission success.
Historically, a problem like this one would be met with a call for a “universal standard;” an attempt to change the way each existing system (and all future systems) operates, so that they might all speak the same language. These efforts are almost always frustrated by the insurmountable challenge of mobilizing dozens if not hundreds (or more) of companies and program offices to re-engineer existing systems. They are ill-fated and almost always doomed to fail (hence the below cartoon).
The DARPA / Apogee approach took a different path.
From David:
STITCHES (System of Systems Technology Integration ToolChain for Heterogeneous Electronic Systems) is a toolchain for efficiently integrating existing and new systems together without requiring them to have a common design (or even a common API). The key innovation under STITCHES is the Field and Transform Graph (FTG). It recognizes that there isn't a universal language to describe all interfaces and that a common API isn't required to have systems interoperate. Instead of forcing everyone into a common interface standard (or database schema), it recognizes that you can relate interfaces to each other (we use a sub-Turing complete domain specific language to do this) and that allows us to automatically generate interoperability between systems by leveraging the translations between different interfaces. While you can think of this as a chain (you can talk with Alice, who can talk with Bob, who can talk with me), we leverage the specification (without the systems) and then, using modern compilation techniques, replace the chain with a single optimized transform between the source and the destination (building this optimized code is what STITCHES does).
The impact has been enormous – systems that were designed at different times with different standards and completely context-agnostic are now able to communicate. And the solution was as much a technical challenge as a policy one.
Despite the technical aptitude at many DARPA programs, however, the vast majority do not succeed, and most will never transition beyond the experimental period.
This one was unique.
That had a LOT to do with one man: DARPA program manager Jimmy “Reverend” Jones.
“Rev” Jones recognized immediately that while his team was good, the question of buy-in would need to be addressed early and often.
As soon as the concept began to take shape, Rev began a series of exercises meant to break it. The goal was to reach a breaking point- the point of failure - to determine the limitations of the approach. In our discussion, David describes these exercises, called “gauntlets” as brutal, designed to push the Apogee team, and eventually the government teams, to the breaking point. They were almost Musk-like; each gauntlet featured a progressively harder technical challenge, delivered with less lead-time, and a smaller window of execution. And in this case too, the exercises worked. Rev pushed the team farther than even they thought possible, while creating a culture of buy-in and evangelism among nearly all those who partook.
Map of Rev Jones’ “Gauntlets” During the STITCHES Development Process
By the end of these exercises, STITCHES was delivering major wins. It allowed, for example, a community of operators to take an ISR source, convert it to a different format used by tactical radios, send it to a different destination site (e.g., Marine Corps TOC), flip it to a standard used for remote fires, and then feed it to a remote fires control system for action.
Previously this sort of integration effort might have taken years to achieve, but STITCHES made it possible in just a few months or less (depending on access).
Despite its successes, finding a long-term home for STITCHES still proved challenging. The Defense Department, David says, “is built around buying capabilities. And STITCHES is not a weapons capability, it’s a tool chain to generate capabilities.”
As a result, this transition took nearly 7 years from the DAPRA kickoff. As a result, DARPA created a “bridge” program where it held STITCHES longer than normal, while the team searched for a long-term home. Ultimately, the role of people again loomed large. Rev Jones has a dual-hat appointment to Air Force AQL, the Air Force’s acquisition shop, and the 350th Spectrum Warfare Wing out of Eglin Air Force Base. Due to synergies with the 350th mission of mission data files (software for electronic warfare techniques for different platforms), that is where STITCHES came to stay.
Looking Forward
One thing that David stressed multiple times during our conversation was the need to consider the “long tail of sustainment” when looking at programmatic transition. Just because a technology is deployed doesn’t mean it’s done.
STITCHES today is maintained and continuously developed in two ways: first, there is an ongoing development contract devoted to the tool chain itself - Apogee continues to perform on that today. Second, different program offices that want to use STITCHES can run their own process / issue their own contracts to use the STITCHES toolchain to develop their applications. Or, they can send money to the primary contract (managed by Rev Jones) and have the work performed as a task order.
Case Takeaways
As David reflected on the design principles that enabled transition, he highlighted a few that remain broadly applicable beyond the STITCHES experience.
1. Recognize you’re building on an installed base: STITCHES, like most capabilities built for defense, was not built on a clean slate. The centrality of integration with existing capabilities is part of makes pure commercial approaches so tough. This capability, like most others, needs to consider existing technology, as well as Defense Department workflows and organizations.
2. Consider the “Long Tail of Sustainment”: True capabilities are not lobbed over the wall. The STITCHES “gauntlets” were designed to smooth the way for sustainment from the beginning, by building a constituency for using and maintaining it. The Apogee approach to open source development may be unique, but every capability requires some plan for sustainment.
3. The adversary gets a move: Defense capabilities would be wise to account for competent adversaries from the beginning. STITCHES was built for contested environments. Companies looking to compete in the defense market need to recognize how the operating environment differs from the commercial world, and build to it.
4. Partner, partner, partner! STITCHES went above and beyond to build partnerships early across the breadth of defense players (PMs, security, contracting officers, big companies, small companies, software maintenance squadrons, etc.)... and still took a good while to transition. People are key, and momentum compounds.
5. Test/experiment early and often: To that end, the STITCHES team tried to find the break lines early and often.
6. Long-term thinking: The team recognized this was not a short-term game or a near-term win. They took a long view at what was needed to develop, transition, and sustain from day 1.
I’ve added a few of my thoughts as well:
7. Begin with the Intent: David’s approach to difficult conversations and government personnel is refreshing. In particular, he spoke about the value of contracting officers and security personnel.
On Contracting Officers. “Some folks treat contracting officers as either barriers or folks you only talk to when there’s a problem. But we found that if you take the time to explain to them what is the mission, what it is you’re trying to do,” and why you need to move quickly, they want to find a way to help. At the end of the day, they are in the government because they care about the mission too. They should not be treated as an afterthought. So many companies treat them as the mere implementers of a leader’s will. But engaged correctly, they become an incredible accelerant to impact.
On security officials: “ATOs come from a good place. The idea comes from caring about cybersecurity. If a system gets compromised, I don’t want to just plug it into other systems willy nilly. They care about the mission. They’re trying to protect things. And when you take the time to understand their problem and craft the solution in way they can get behind, then you can make ATOs much much faster.”
8. Defense Needs more Generator Capabilities: David spoke about the role of tools that connect different capabilities together - thus creating new ones. To adapt, you cannot continue to solve the same problems over and over again every time they appear. Instead, you have to build tools that automate processes. This is an under-emphasized area of defense that would benefit from increased attention right now.
9. If you love it, set it free: “The STITCHES ecosystem is very much beyond Apogee at this point,” David remarked. STITCHES has an MIT open source license within the defense community, so that anyone with a Controlled Access Card (CAC) can download all of the source code, documentation, and integrations. The Air Force is hosting the Bravo Hackathon series, which will bring together hundreds of developers in a single place at the Secret / Collateral level to develop solutions using STITCHES for the broader community. While this approach may not work for all companies (especially product vs services providers), it is thought-provoking to consider how companies might play a role in making their solutions a platform for the mission, rather than another piece of closed architecture?
Love it? Hate it? Want to change it? Please reach out and share your thoughts: noah@frontdoordefense.com
Ep. 2: Apogee Research is Changing the System from Within