SysGit in Conversation [VIDEO]

The pull request is familiar to anyone who builds software. With SysGit, it’s being used to design vehicles and weapon systems for America’s defense.

In a new interview, SysGit CEO Steve Massey breaks down how SysGit adapts this and other software development capabilities to create agile hardware engineering. Massey recently sat down with Margaret Roth, Principal at Squadra Ventures, to discuss the secret knowledge that informed the development of SysGit, what it means for engineers to treat hardware as code, and how to accelerate time-to-capability in the U.S. Defense Industrial Base.

Below is a transcript of the interview:

Margaret Roth, Squadra Ventures: Steve, I think it's been a really exciting last couple weeks for you, and really a whole last couple, the last whole year, really. There's been so much work that's been going on towards launching SysGit, which has officially happened now. So tell us a little bit about how you're talking to people about it today. Give us the overview of what SysGit is. 

Steve Massey, SysGit: It's a way to solve problems we think we have to unlock with truly agile engineering. We've been building a company in this space since late 2019. We had a lot of experience before that working in really innovative places and actually doing agile engineering. And we uncovered what I think is some really interesting secret knowledge. That's what every startup really hopes to get to. The two pieces of that — one, they have to do with the background that myself and the rest of the team have, at places such as SpaceX and Slingshot Aerospace.

And then two, the process of taking a previous platform, Verve, and deploying it into some really interesting weapons systems in the defense industrial base, and learning exactly what the limitations are of taking a classic like cloud application and just just placing it inside of this environment.

We really went back to the drawing board, that last week of January, first week of February of 2024. And it’s  an emotional time for any startup to say, Hey, I think we want to do something a little different, and then making all of the changes and getting everyone on board with doing that. 

MR: Yeah, not just something different. Like, wow, we have really done a ton of customer discovery. We've had a product out in the market and we're on the right track. I think that was a realization that, we're on the right track, we're hitting the right need, but we need to think bigger about what that scope actually is and how the solution is actually positioned to service the people who actually need the product the most. So, I think that really is a big part of what brought you to really focusing on the DOD and the defense industrial base as a whole. Can you tell us a little bit about some of the unique components? I know we’ve talked a lot about zero trust architecture. We talked about the ability for people to inherit their security posture and still use SysGit. Can you tell us a little bit about the value of being built on Git and other open standards?

SM: Yeah, definitely. I think it's interesting to think about that in opposition to a classic cloud approach where you're building these microservices, you'll have a database, you'll develop a really interesting data structure.

Intellectually that's a fun exercise. But you end up building a proprietary set of  basically proprietary ontology that doesn't map to what really the rest of the world is doing. And you suddenly have these islands of proprietary data sets. It was difficult to convince the customers we wanted to sell into, Hey, just deploy all this stuff.

We're on GovCloud. That's good enough, right? It's absolutely not. And so we developed an architecture that acknowledged that. One thing all of these companies have, and all of these programs have, is a Git provider. It might be GitLab, it might be GitHub, it might be Bitbucket, but they have, their software engineering team has been operating in the Agile space for decades. 

Two, the innovation behind the Systems Modeling Language version two that we've been seeing, that's been just developed by the leadership of the Object Modeling Group, and then the rest of the defense industrial base, of course the major time that academia has put into that language has been really, really powerful based on the last 20 years of systems engineering to meet the actual needs to perform those activities in a really interesting way.

And we started thinking, well, the new textual notation just has all of the concepts we were putting in a data model anyway. We were spending a lot of resources trying to bring in Git-like branching and merging into that data structure. But if we just store everything as textual notation and store it in Git, we get a lot of that for free.

And then we map to a standard that the rest of the industry would like to move to. Uh, and we just get a lot of the really, really hard things that we were spending a lot of resources on basically for free. And then we could focus on what matters, is having these interactions as positive as possible for the engineers, as well as really interesting things around, bringing the concept of a pull request directly into system level engineering and then acquisitions.

We're hearing this big thing around, we want smaller milestones more frequently, and we think that this specific architecture is the only thing that will actually enable that. 

MR: And that's really the shift. The software development experience was the waterfall to agile and not only waterfall to agile individually, but also this sort of globally cross functionally, co-collaboratively across different teams and different organizations that's sort of the you know for a different way to say it and really simply is sort of this is the There's the waterfall to agile moment, but there's also sort of this Microsoft Word doc to Google Docs, right? The simultaneous collaboration on the same project, which is another big thing that I think has really resonated with customers and, um, everyone you've talked to. 

SM: Yeah, I think what's really interesting to pull, pull on that a little bit more is that collaboration needs to cross firewalls, either inside an organization or outside an organization.We were building a product that makes sense in the ecosystem of SpaceX, vertical integration, we're all inside the same building, working towards the same thing, and you might be able to find small to medium sized businesses that are modeling themselves after that, but that's not the way the rest of the Defense Industrial Base is operating.

Engineering teams that are competitors in one program might be collaborators on another, as they put together a larger team of primes and subcontractors and vendors to deliver the best capability among the seven or so major defense acquisition programs. 

MR: So this is a piece that you're really getting at, like what the company sort of this bigger vision that you have for SysGit. It’s the technical component of interoperability, but you're also talking about interoperability at the system level, at the government to industry level. Tell me a little bit more about that. 

SM: I think it's really interesting sort of the way you philosophize both sides of that technical and, um, you know, in a way, uh, structural. Yeah. And, and a lot of this is really enabled by the great work going into. to, uh, SysML v2, uh, specifically, and we can get way into the nerdy part later, where, uh, you're looking at the way you can have multiple files, multiple imports.

We have, uh, organizations we're working with today that they have a, a diverse set of SysML files, and they're bringing in the references and the namespaces to make sure they can cross collaborate and work on similar parts of the codebase exactly like software engineering teams, and that's really exciting.

But where it gets interesting is the ability to share either your top level requirements document, your top level system model, and then import that into the things you want to keep secret. Your set of derived requirements, maybe some underlying decomposition of those models that is core to your IP, but share that top level information in the new open standard with your compatriots on this program that you may find as competitors later on.

And it's this approach that actually enables the vision of MOSA, a modular open systems approach itself. Because you can more freely share the information that you want to share and then keep locked down the things that you don't want to share. I think that is what's going to actually enable this rapid fire acquisition process of just trying new things and just having full agile all the way down from the program office, down to the, the prime, the subcontractor, and the vendor level, just based on the strategic sharing of the right files. And I think where SysGIt comes in the middle of all of that is that where we really shine is on the pull request, as it's known in the, the software world, and the diffing to make sure you're bringing in the correct information, and fully trusting the information you're bringing in.

And that's really the transformative piece is that we're facilitating that information sharing when at the points where it's necessary and keeping safe, secret, secure the information that's really proprietary to these different organizations. 

MR: We’ve gotten to spend a lot more time together here out in D.C. You've spent a lot of time at different events and different meetings with different types of stakeholders. Tell us a little bit about what you've seen, what you're hearing. Give us some forecasting around, we've heard, digital thread, digital engineering, MOSA, MBSE. These words are very much in the ethos right now, especially with the administration change.

So tell us a little bit about your forecast, what you're hearing. 

SM: People want more capabilities faster. They see private industry being able to support that in either automotive or certain companies in launch. And they want to be able to bring that agility to the rest of the Defense Industrial Base.If things get spicy tomorrow, like you're not going to come in with a bunch of new entrants to build more F 16s, we're just going to ramp up production on that, right? And so, there’s a lot of really excellent work being done at the existing incumbents by really smart people that we just would like to accelerate and move faster. And they want to accelerate and move faster, too. No matter what side of any organization you're on, that's really the goal. 

One thing I'll say is that the new platform is moving away from really digging in on the digital threat side of things. I think there are a lot of companies out there working to solve that problem. I think we're acknowledging wanting to be able to build things that go across the firewall. I don't think that's really something we want to focus on at this time. We want to focus specifically on requirements management and system level modeling so that we can share the information that at the very top level, everyone needs to use to be on the same page even crossing company boundaries.

And so we're hearing a lot of interest in the requirements management space, wishing for new entrants and wishing for more support there. And then also the system modeling space, because there's the new language coming out, there's a lot of excitement around SysML v2. And so there's a lot of interest and opportunity to break some of the stranglehold that we've seen over legacy tools in this space, and expand from there and really enable this push towards a digital acquisition process.

MR:  I think something that we've talked about over the years, you know, you're former SpaceX and there has always been this focus and intent on efficiency. I think people sometimes get hung up on efficiency being a factor of time. Can you tell us from your experience in these launch roles and then sort of coming through different parts of this industry, what that actually means to you? What do you think it means for where things are going?

SM: You're right about it being a function of time, because ultimately it's how fast can you field a new system to support your end goals, whether it's a business or policy, or even fourth production or Y. Fundamentally, that time component is important. What we're really interested in solving though is, well going back, there was always this simplified way of describing the engineering process of SpaceX as being empowering a lot of engineers to build the system they think is correct to make the larger system work. And, in a very simplified way, you could argue that we're designing almost 20 percent of the adjacent parts that your module would plug into. And, you were able to sort out any sort of conflict in person because the organization was very vertically integrated. What that says to me, at first, I thought that was, I want to propagate engineering parameters into the other teams who know when things change. 

What that actually means, we've learned, is, we want to enable parallel development so those individuals can work on the same platform, the same part of the vehicle at the same time and then gracefully resolve the changes. And if you can figure that out in the security environment that we're working in, you can then do that across vendors as well, where you're working on the payload attach point of the F-16, building a new module, a new fuel tank or sensor pod that goes underneath, and you can do that without having to spin up a massive integration study contract with everyone involved in that. You can instead bring in enough of the system design files that the end customer owns, build against that, and then do a lot of integration study virtually using what you've been able to share. As long as you've sufficiently captured that definition in something like SysML v2 and can gracefully resolve any conflicts that might have come about around the changes that you're building. 

MR: And so that parallel path development for hardware concept is really what SysGit is enabling. It's sort of one of the core value adds to that. How have people responded to that, um, bringing that concept into the hardware and large acquisition and system development space? 

SM: I think it's really, really positive. We have a little bit of education to do because, I feel like I'm kind of spoiled having a software engineering background and being on both sides, and I know what a pull request is instinctually, but there's still some education we need to do with that because that's a very software focused concept.

So we're starting to call them things like, you know, small R designer views, mini design reviews. Even though the underlying functionality is the pull request or the merge request, depending on what your underlying platform is, really you care about seeing a red lined table of requirements just like you could see in a diff coming out of word or a vendor tool.

And you really want to see the red line of a system model diagram as well to understand with literally red lines. What has gone away with green lines, what has come in and doing that same conflict resolution process that the software engineering world is used to under the hood, but presenting it in a way for engineers that are incredibly technical but more in a either systems level or mechanical way and not actually a software engineering way. 

MR: So let’s take those concepts and map them for a second. We had design review — design review in hardware is sort of like an epic roadmap review in software. A mini design review is sort of that sprint meeting, it’s the deployment procedure. What are some of those other components? Help us educate people going from that hardware side to the software side. What's the connection?

SM: We see like a big design review, like a PDR as basically a tagged release that you would have in a software release. And we see those mini interactions the engineering teams have with each other.

That can be that pull request or that merge request that can de-conflict the changes that you'll find. You have approvers that come in and, and provide approval that, hey, this software is okay to merge. You still have those subject matter experts coming in on your mini design review giving that thumbs up on that approach. So that definitely maps one to one there, as well. I think one of the things that will be challenging is just being comfortable with working on the same file at the same time and expecting the changes to be resolved through the pull request process gracefully. But after 20-plus years of experience in the software engineering world doing that, since the advent of Git, I'm confident that we made the right decision in doubling down on that specific software to support that as opposed to rolling our own layer. 

MR: And any change like this, like it's an advancement in technology. It also requires a sort of advancement in culture, right? Like the first time that became, or when that was introduced to a development team, that was novel. That was, I don't want to do that at the same time, right? It was, but over time it's proved over and over again to be the best, most efficient, most collaborative, most engaging for team members, as well, way to build great software that has a good impact. So that's, I think, you know, very clear that we're seeing that pull over on the hardware side, which is good as well.

SM: Yeah, I'm really excited. I mean, I think the way we're setting this platform up and the way that we're doing it in such a secure way as well, in that we don't store any information. We're really just interacting with the system models, we're interacting with the SysML language itself, and we're storing it directly into the Git provider that the users that log in already have access to.  We don't store any user information either. We completely inherit the existing security posture of our customers. And we can run either, uh, an on-prem deployment if you want a convenient web URL to go to. We can also just deliver client only builds like any other piece of software. We're really flexible in this aspect.

And it minimizes the overhead that IT has to have to wonder, like, when did you last run CVE scans on these microservices? Where did this random library come from? How are you doing your static code analysis? Like, we've really minimized our cross section there, so that the IT teams and the security teams that support deployment of a platform can with confidence expect that we're delivering the software to work inside of, and within the team,

MR: So I know there's a whole lot of different stakeholders that we've already worked with and continue to, you know, speak to as our customers. Can you tell us a little bit about the different kinds, sort of like, where are the different entry points for people into working with SysGit? 

SM: Give us some of that persona of, who should be reaching out? What's the right sort of stakeholder to engage with? I mean, if you are a product level owner of a platform and your team, I was considering using a more legacy requirements management tool, or like a MBSE tool. We'd love to talk with you and see if SysGit is a good fit for your team at this time to use us instead. Because again, we're not only writing requirements, but also the system modeling part. And then also the collaborative storage of that information. It's really replacing four tools that you're otherwise spending a lot of money on.

And so it ends up being a reduction in software complexity for your organization as well. This brings us off to the IT team that, uh, maybe they want to minimize the amount of services that they're managing internally. And they'd like to double down on their investment in a GitLab or a GitHub and the two to three tools that you're using to manage requirements, to manage MBSE files to manage the collaborative use of those files that are also proprietary and vendor locked. So we can come in, and support a simplification of your IT organization through that process, and then just because we're basically charting the waters on this agile design review process, we can be a differentiator for your organization if you go out and bid on a new capability on a major defense acquisition system.

We can have the expertise as we're defining the process using SysML v2, using the concepts around MOSA, and then using the design review process we've built on top of that, we can support any organization to make sure that they're delivering the best capability, the fastest, to their end customers. 

MR: Okay, and then to wrap this up, we're going to go right back to the beginning. Steve, we've had a really exciting couple weeks here as we've led up to the launch of SysGit.  Tell me simply, what is SysGit  today? 

SM: SysGit today is a collaborative platform for requirements management, for model based systems engineering to do collaborative design reviews at the speed expected by software engineers, we're bringing that to hardware. We deploy into secure environments, and we're ready to work with people today.