Git-Inspired Change Management for Hardware

Let's jump right in with one of the most controversial subjects about Cascadia's design: git-inspired change management for hardware.

The Problem

Traditional engineering change management takes a different form in every organization, but typically involves at least two core phases: change request -> change execution.

The change request or change proposal phase is often not a "strict" phase, in that it doesn't in any way lock down the proposed items (existing released parts and documents aren't "uprev'd" or locked for edit); that happens later, in the change execution (otherwise known as the change order, or change notice) phase. But while in good CM orgs much of the assessment, planning, and pre-development work happens in the change request phase, a lot of work still necessarily happens in the change execution phase, from doing final modeling, simulation, analysis, and more. And while all that change execution work is being done, the parts and documents being worked on are typically locked — they can't be added to another change execution. So if a released part is undergoing an extended change execution, but an urgent critical change comes up on that part, workarounds have to be pursued to get that change out the door. This is a story every manufacturer knows all too well, and a problem Cascadia aims to solve.

How Cascadia Works

Now, it's important at this point to note that Cascadia isn't trying to be the PLM for everyone. Most PLMs out there are Part/Document-centric. This is the most flexible model, and allows the PLM system to be useful (after some expensive configuration and customization) for most every industry. Cascadia takes a different track; we're Design-centric. What does that mean? It means at a high level we ship with the idea of systems at the core. We'll get into what this model looks like more in detail below and in future blog posts, but the primary target audience for this model is ETO (Engineer to Order) or HMLV (High Mix Low Volume) manufacturers, whose entire business model is focused around designing and shipping limited numbers of highly custom projects.

To tackle that, the basic organizing principle behind Cascadia is the "Design". A Design is a conceptual model and data repository for any given high level entity. There are several categories/types of Designs in Cascadia, from Engineering (think of this as your EBOM for a given project), to Manufacturing (your MBOM), Family (for family of assembly type collections), and Library (e.g. standard parts collections). Designs can also be children of other Designs, and your standard PLM items (Parts, Documents, Requirements, etc) are all children of Designs.

For our software people out there, think of Designs like repositories in git.

This organizing principle allows us to track the history of a given Design in complete detail, and to create "branches" off each Design. These branches are the cornerstone of our unique change management implementation.

What This Unlocks

In Cascadia, we are able to allow the change process to naturally collapse into a single phase. You can think of it as change proposal + execution, but we'll just call it an "ECO" (engineering change order) in this post. We can do this by creating copies of each affected item in an ECO, each of which retain full traceability back to their original items in the Design's "main branch". We can then use that crosslinking to see, from any given ECO, what other ECOs are working on the same items, and thus detect and resolve any "merge" conflicts that might come up when the users are ready to finalize their changes back into the main Design branch. These item copies, then, can be fully progressed, uprev'd, modeled, analyzed, etc, to take each change as far as needed for all approvals before releasing.

What about changes that don't get approved? In traditional PLM this could be cheap (change requests/proposals that simply don't get approved), or it could be expensive (approved change executions that stall or get cancelled, which blocked other work from happening simultaneously, and then for no payout, not to mention potential difficult data remediation with rolling back revision numbers, etc). Cascadia makes that cheap, always, without sacrificing auditability. A cancelled ECO in Cascadia just means those item copies never get pushed back in to the main Design branch, but that ECO, and the review, approval, and decision steps associated with it stay where they are, and are always visible as branches off from the Design. Or you can go the step further, if the ECO creation was a mistake, and delete the ECO, clean up your data, and skip all the messiness of data remediation with traditional systems because the items in Cascadia are copies of the main Design!

Why hasn't everyone done this?

Now, we've established that git-inspired change management is made possible by a focus on systems-centric design as opposed to the more flexible Part/Document-centered approach, but you might be asking why doesn't any other PLM system work that way? Well, the first part of that answer is that the major PLM players have been around longer than git has, and once your whole process (and much of the educational system in the industry) is built around a certain method, it's very hard to change it. The other part of the answer is: this isn't a truly unique concept. Onshape's PDM has an excellent working example of something very similar (though you're limited to their CAD and workflows; Cascadia is CAD-agnostic), and I've come across a couple of other modern PLM/PDM systems (Duro, Bild) that purport to have "git-inspired change management," though I haven't seen anything to back those claims up in their blogs or documentation. This is the wave of "software for hardware" finally catching up.