While drafting boards and vellum are either a distant memory or a perplexing Wikipedia look-up for the younger set, most engineers are still handling design changes like chain smoking and leaded gasoline are still all the rage.
We’ve grown a little complacent to the change techniques that were carefully crafted to work within the limitations of the past: checking things out one at a time, revising linear histories, and writing ECOs as separately released changes. The cloud has introduced new technology that is fostering a collaboration renaissance. It very well may transform how engineering is revised forever.
An eternity of linearity
Classical engineering change is highly linear, purposefully invented within the limitations of the physical realm, when designs were kept in a physical vault. Even as software has developed over time, physical vaults were merely replaced with digital ones operating under the same principles. The paradigm was only enhanced, not transformed. Only one person at a time can work on anything (check-out, check-in) and ECOs are heavily favored over direct revision in many cases, regardless of the stupid cost of unincorporated change.
This is especially true when identified change is implemented out of sequence, or when change is applied to a specific variant of the product either according to service date, production lot, target customer, or various other stipulations. Products becoming more complex doesn’t help matters, often requiring a variety of complex management solutions like effectivity or configured variants to handle pesky change on change scenarios.
Sounds like engineering has to stay in linear purgatory, and ECOs must continue to spew forth until the end of time, doesn’t it?
And now for something completely different
As all design going forward is exclusively in the digital realm, the physical limitations in handling change are no longer necessary, they are a choice. For an alternative we need only look to another industry struggling with enormously complex products constantly overwhelmed by multiple sources of non-sequential change authored by large, diverse teams constantly perturbing configuration.
Of course, we’re talking about software source control.
If software is eating the world, then source control might very well eat engineering change and configuration management. It’s only possible now because cloud solutions are abstracting away from conventional file systems and file-centric database structures.
What that means to you: Save and SaveAs may just go away. The digital vault no longer has to be a facsimile of the traditional physical vault.
Calm damaging DAGs
The key in source control is that it’s entirely non-linear. I could get into a protracted discussion about Directed Acyclic Graphs (do ya like DAGs?) but it might begin to damage your calm. So instead I’ll show you a picture:
Via http://nvie.com/posts/a-successful-git-branching-model/
Traditional engineering change is a single line, each change comes sequentially and inseparably. The model severely limits how you handle out of sequence change, but makes changes easy to manage and implement. In source control, however, change can be isolated on its own “fork” on a whim, occurring in parallel with any number of other change forks. Think of forks as a branch on an inverted tree from a common earlier version. In addition any of the forks can be merged back into the main product line at any future time or with each other, or left out to grow as a full alternative design. In the case of a merge you look at differences between each fork and resolve any overlapping conflicts where different changes exist for the same feature.
Resolving those differences is appropriately called a “diff.” With each fork, merge, or even new version in any given fork, metadata can be stored. That’s where we’ll maybe see things like Fork Change Order (FCO) or Merge Change Order (MCO) in the future. It sounds complicated (and it is) but the model is extremely powerful and applicable to engineering design. The paradigm removes the consequences of change, allows collaboration to happen in parallel, and permits an infinite combination of change upon change for even the most complex development process. All around, it’s pretty heavy.
Famously, Github has popularized software source control for both individuals and companies – taking some (but definitely not all) of the rough edges of handling a more labor intensive distributed Git repository (or “repo” as we like to say around the cool kids). Expect to see a lot of Github-like functionality popping up everywhere in the CAD landscape. It’s already started with products like Onshape, but this is only the beginning.
But Why Should We Bother?
If it ain’t broke don’t fix it. Expect objection from older engineers especially at the mere suggestion of changing some of the most sacred and long-lived engineering practices (like ECOs for example). Current check-in/out and ECO change management works, right? That’s not the point – the point is what we need to evolve engineering change for the future. It’s kind of like coal for power – sure it works quite well now, but you know in the long term, it’s time to move to something better. Look at it this way: it’s yet another change on change.
