Why Systems Engineering Needs Its Own GitHub

You’ve updated the spec. Again. Seven emails, three meetings and two weeks later, there’s still no trade-off between mechanics and electronics. Sounds familiar? That’s because modern systems are multidisciplinary puzzles.

Whether it’s a next-gen vehicle, a satellite or an energy infrastructure, success requires tight coordination between experts from different fields. Each brings their own requirements, their own set of priorities, constraints, perspectives and vocabulary. Aligning their visions and decisions across the project is hard, and staying aligned is even harder.

Coordination has always been tough. But today, product complexity and development speed are on a collision course. Agile hardware cycles, integrated software, and digital services are collapsing timelines. You can’t spend three weeks aligning on a requirement change when the competition ships every two. Engineering speed is becoming a strategic edge and misalignment is its silent killer.

In today’s engineering landscape, the challenge isn’t just (technical) complexity : it’s coordinating the (social) complexity.

The Cost of Misalignment

Every architect, expert or project manager has experienced it:

• Endless emails threads where half the context is missing.
• Interminable (and sometimes even irrelevant) meetings gathering dozens of people.
• Weeks of circular discussions between disciplines to resolve tradeoffs.
• Management escalation, not because of strategic needs but because a decision has to be made eventually.

The hidden tax is massive: design iterations drag out, experts burn time managing ambiguity instead of solving problems. This isn’t a people problem: it’s a tooling failure. Humans are siloed, data is fragmented, workflows are disconnected.

What is missing is digital continuity: a shared space where decisions, data and rationale flow together.

What Software Got Right

Software developers used to have the same problems as engineers: code scattered in zip files, patches sent over email, no traceability and tons of duplicated effort. Then forges like GitHub and GitLab changed the game. 

These platforms are not mere code management tools, they are the backbone of the social coordination:

• issues and commits give traceability across decisions,
• pull requests streamline reviews and discussions, replacing endless email chains,
• DevOps drastically reduces lead time and change failure rate.

Teams now move faster, align better and ship more often. Decisions are traceable and collaboration scalable.

A few metrics [1] [2]:

• forges can improve developers’ productivity by more than 30%
• forges have an ROI of more than 400%

Forges brought so much that, nowadays, no serious software project exists outside of a forge.

Systems Engineering Has No Equivalent — Yet

Systems Engineering is facing similar coordination challenges, yet despite all the solutions that are currently available — such as PLM and other innovation platforms — none of them replicate what a forge did for software.

Why?

• Closed ecosystems: many tools lock you into a vendor’s universe; they may have an open API and some modularity, but integrating in-house tools or collaborating within an extended company remains a challenge instead of an opportunity.
• Single-domain or field focus: some tools provide great capabilities within one discipline or engineering field, but are not designed to support or even interact with other domains.
• Complexity overload: some platforms are too heavy or expensive for smaller teams to adopt.

And while GitHub and GitLab are powerful, they have been built by and for developers. There’s no native concept of requirements, models or system-level tradeoffs. The workflows, vocabulary and assumptions of these platforms don’t translate well to mechanical, electrical or systems engineering work.

What is missing is a forge built for engineers from the ground up.

That’s why we’re introducing the concept of an Engineering Forge: a new kind of collaboration platform that borrows the best of software forges while speaking the language(s) of engineering.

Introducing the Engineering Forge

Imagine the systems engineering equivalent of GitHub, with models instead of code, requirements instead of issues and trade studies instead of pull requests:

• Impact analysis: change a requirement and instantly see downstream effects, what is impacted, who needs to validate and where risks emerge.
• Digital continuity: don’t wait for meetings for the next sync — context, decisions and rationale are already captured and broadcasted.
• Federated data: each team retains control of their tools and data, while contributing to a collective understanding of the system.
• AI orchestration: intelligent agents orchestrate redundant tasks, augment engineers and take the most out of data.

It’s not about replacing today’s tools or people. It’s about empowering them by keeping them in context. 

We call this an Engineering Forge: a data-centric, open platform designed to deliver digital continuity across domains. 

What makes it different?

• Data-centric: built around modular, composable data services and APIs rather than giant monolithic databases.
• Open platform: leverages open standards to enable interoperability with existing tools.
• Digital continuity: integrates all data and artifacts into a knowledge graph or digital thread.
• Coordination layer: allows bi-directional communication between humans, tools and AI agents.

Real-World Scenario: Addressing a Requirement Change

A customer makes a late request: increase engine maximal thrust, but keep cruise fuel consumption unchanged. Normally, this triggers weeks of back-and-forth:

• Stress engineers run load cases,
• Control engineers check stability margins,
• Aerodynamics engineers run new fluid simulations,
• Everyone is stuck in meetings or chasing emails.

It’s slow, error-prone and burns expert time just to stay aligned.

With an Engineering Forge:

1. The systems engineer updates the thrust requirement in the shared requirement set.
2. The Forge automatically traces dependencies and alerts subsystems that are impacted.
3. Stress, control and aerodynamics experts get notified with full context, including rationale, related models and prior tradeoffs.
4. Each expert runs their analysis in parallel. The Forge collects results, flags inconsistencies and prompts reviews.
5. Within 48 hours, a coordinated response is ready. The systems engineer replies to the client with facts, not delays.

Possible usage scenario of an Engineering Forge to iterate faster

The Engineering Forge enabled a shared understanding of the problem then supported a collective decision making.

What’s next?

We started as part of a France 2030 project which united a consortium of several partners in the aeronautics industry: Akkodis, QuantStack, Inria, Safran and twiinIT. The project led to the development of a research prototype of an Engineering Forge.

We’re now transforming this concept into a product: our start-up, Myrmix, is committed to bringing better collaboration and systems thinking to engineering projects.

If you're passionate about systems thinking, digital engineering, or reimagining how teams build complex systems, we’d love to hear from you.

Follow our journey, or reach out directly at contact@myrmix.tech!