SysGit Origins, with Co-Founders Steve Massey and Zeke Brechtel (VIDEO)

Two decades ago, the invention of Git transformed software development, spurring the creation of agile workflows and best practices that are widely-used today. 

Today, Git is being used in hardware development, bringing the best of agile software development to accelerate time to capability in the defense industrial base.

Recently, SysGit Co-Founders Steve Massey and Zeke Brechtel sat down to talk about agile hardware engineering, the revolutionary advances of SysML v2 and Git, and what it means for the development and acquisition of defense systems.

See the video and transcript below.

ZEKE BRECHTEL: Steve, all right, so I think today we're gonna talk a little bit about why we started SysGit as a company. So Steve, why don't you start us off? 

STEVE MASSEY: It really comes down to thinking about Agile, thinking about how to apply Agile to hardware development and actually acquisitions as well, and looking what the software world has been able to do in the last 20 years. There's the cultural part of agile, which is the meeting stand up, the groom backlog, that ask your customer, what do they actually want, until you actually find out the proof. But there's also this tactical implementation that I think was really only enabled by Git as a piece of technology back when Linus Torvalds invented it almost 20 years ago at this point. He just wanted Linux contributors to work on the same piece of code at the same time and resolve the differences gracefully. And we keep thinking about, how are you managing the system level models and the work you actually have to do, to the complex engineering of the defense industrial base. And the current state of the art is very, check-in, check-out. It's very, ‘Don't touch this. I'm working on it.’ But I remember even to a series of conferences in 2023 and just started to see SysML v2 and textual notation, and that was super exciting for you, and it's great. And, like, it was really cool to, like, dig into that a bit and realize that, well, hold on, there's something here, if we were to shift the paradigm of the software tool building to actually use the same 20 years of software engineering and apply it directly to hardware, we could not only deliver capability faster, we could almost get to biweekly deliverables at the business level of actually proving that we’re building the right thing, and really tighten that decade long time to capability to something much closer to what we, you know, we saw at SpaceX that was so perfectly integrated.

ZB: I think you touched on a lot of key points there. The power of the textual notation and framing it in a way of using it, the way that you would write software, write code. You can store the textual notation. It's text, right? And it comes in a text document, you can open it and edit it with something as simple as Notepad or vim or another text editing tool like that. It's really just a very simple representation of your models, but because it's a text format, that makes it ideal for working, for storing it, managing it, merging, and controlling it in a tool like Git. With the invention of Git and with widespread increasing adoption of it, you see other tools like GitHub and GitLab and other DevOps, CI/CD focused tools evolve around that, where you really build all the useful workflows on top of that code, and we see a connection with what we're doing with SysGit and what we're doing with storing SysML v2 to layer on top of all of those workflows and DevOps and agile approaches to building software. Now you can take the same approach and use it in SysGit with building hardware, and again, it all really relies on SysMl v2 as that core technology of how you define and model your systems. SysML v2 has a lot of great elements and affordances for modeling all sorts of information. One of the most important ones that we think is, starting off on a system, starting off in the program, is really modeling out your requirements and how they're going to trace across your entire system design and evolution. That's a core part of the systems engineering V model, if you're familiar with that, and it's great that SysML v2 provides that because previously you have a traditional requirements management tool, maybe you just want to use something as simple as Excel. It's what a lot of engineering teams will reach for. But with the power and model of SysMl v2, you can have text, you can have version control. You can trace it across the entire history of the development. There's just a lot of really interesting tools and affordances for working with not only requirements, but directly integrating those requirements into your system models and system design and building DevOps workflows on top of that. So I think that's kind of what really attracted us to SysML v2

SM: My favorite part about SysML v2 is that it’s the last five years of the major contractors and researchers putting a lot of work into this, based on the last 20 years of MBSE. It's not just something we're just doing off on our own. We're taking something that is industry is defined, and we're building on top of that. 

ZB: Yeah, absolutely, you know, using my, you know, big college word, three syllables, SysMlv2 has a pre-defined ontology, which is a way to think about and reason and describe systems. And like you pointed out, that's really all of the kind of the mindshare of the engineering community and the Model Based Systems Engineering community has established core defining ways of how you describe requirements, how you describe attributes and requirements, how you describe parts, how you describe how parts interconnect together, and it just provides a standardized way of reasoning and thinking about these systems. So, so yeah, I agree the SysML v2 ontology is great, and it's wonderful to be able to, you know, if you're, if you're a prime contractor working with a vendor, and you deliver them a SysML v2 model, if they have some comments or questions about what's meant by a certain phrase or certain word, you have, there's these great 500 page specification that you can just point them to if they can they can look at that and understand what, what everything means.

SM: From product development perspective, we're not really deviating from the specification. At the end of the day, we’re building a system modeling authoring tool and requirements mismanagement. That's that middle layer of what we're building. But because of that, and our approach to treat hardware as code, we can then enable something different, even at the acquisitions level, right? I think one thing we've been really pushing on, and we've been showing to DOD leaders, getting good feedback on, is going from that 18 month design review cycle of, everyone pile in and make a bunch of slides to, well, acknowledging the system model is a business artifact as much as it is an engineering artifact. You're not necessarily making system models for fun. That's just something you're doing to prove to your colleagues you're doing work. So we can then come, and then, instead of issuing changes to that model in an 18 month timeframe, we do it in up to two weeks. Because, again, we're using Agile Software approaches, we can then get to a world where maybe the program offices are billing every two weeks and vendors are being paid every two weeks. And then they can make decisions about what's best for the program and take a truly agile approach, as opposed to the modelers being kind of off to the side of something else. And that's, that's one of the things that's truly enabled by this architecture.