Do you believe in Engineering “Real time Collaboration” Neo?

Collaboration is vital to any engineering process, but the actual mechanics of such collaboration can vary widely both in theory and in practice.   Not helping at all is the fact that the term itself has been long hijacked as a piece of technical vocabulary, serving to push new products and features in a protracted marketing war including PDM, PLM, ERP, and ECM, and now CAD. When we throw “real time” in there, confusion mounts as to what exactly that is supposed to imply. More specifically what does that mean for engineering? Do engineers want it? Will it work? Morpheus might say that collaboration is everywhere. It is all around us, even now in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work, when you go to church, when you pay your taxes. For purely creative and/or artistic ventures collaboration can be organic, boundless. For engineering however, collaboration must necessarily be coupled with a critically important concept: change management.

Oleg Shilovitsky sparked this discussion by exploring an interesting question on his own blog: Is There a Need for “Real Time” Collaboration between engineers? In that article he concludes:

“Collaboration can empower organizations and people. In my view, it applies to engineers too. However, it is sometimes hard to find a fine line between collaboration that empower people and some prescriptive “collaboration processes” and activities that lock people down to a specific functions. How to [do] that?”

Prescriptive collaboration as described above is a bad thing, because it’s limiting a human process by the artificiality of particular software functionality. Before we pop trying to figure out how exactly to Kung Fu through that limitation consider this: engineering collaboration in many ways has to be prescriptive collaboration. Not because of software functionality. Not because some jerk blogger like me said so. Instead, prescriptive collaboration is a necessary evil to maintain integrity of engineering design. And the need for that discipline rises with the complexity of the design, how many people are involved in its creation, and the consequences of design failure. So is this the end of the discussion? No, not at all, because the real problem is that engineering collaboration, for the most part has been over prescriptive. There’s room to change that and in so doing fostering more innovation. So what do you need? Besides a miracle.

To understand how engineering collaboration could work requires understanding engineering change, but usually that involves getting lost in an endless parade of workflow diagrams and methodologies that will have you begging to get put back in the matrix so you don’t have to deal with it anymore. So we’re going to simplify, man. So here’s the short-short version of change:

  1. Identifying Change: What needs to change and why?
  2. Accepting Change: Is this good? Will this mess anything else up?
  3. Making Change: Change all the things!
  4. Enacting Change: When is the change real?

Most engineering change processes as they are today are carefully structured to preserve design integrity, and in so doing are linear and inflexible by nature, often enforced by the CM equivalent of Agent Smith. These methodologies are modeled after extinct paper legacies including artifacts like check in/check out. They are collaborative processes by the purest definition, but are intrinsically serial which makes change so burdensome that many smaller projects abandon such an approach entirely, settling instead for brute force methods that can never scale (Like our friend Excel).

So along comes “real time collaboration” which equates with simultaneous edit. That means two or more people making changes in parallel and each seeing those changes as they happen. Otherwise referred to as coauthoring. When you ask people what they want for making changes coauthoring is what they will ask for in the belief that this is a viable change process on its own. They keep using that word, but I do not think it means what they think it means. While available on the document front in the form of Google Docs and Office 365, only recently has this approach debuted for CAD design, specifically with Onshape. And while it is most certainly a technical marvel that it works at all, by itself it cannot be a viable change solution except for the simplest of designs.

To illustrate let’s look at change through the lenses of classical engineering collaboration and “real time collaboration”:

Stage Classical Collaboration “Real Time Collaboration”
Identifying Change Need for change is identified by a formal process, typically an issue management / quality process. The need for change is informally identified by anyone.
Accepting Change Change goes through a verification process, signatures, review board. Being real time, acceptance of any change is automatic.
Making Change Selected individuals are given exclusive permission to solely make the change under controlled conditions. Anyone makes changes at any time.
Enacting Change Change is enacted for a specific case, or at a certain serial number, by a certain date, or dependent on another change or event. Being real time, all change is enacted immediately.

Real time collaboration eliminates barriers for making a change, but in so doing, severely undermines the ability to control change. So we’re improving the capacity for innovation in one stage of the change process at the expense of the entire rest of the process. Welcome to the desert of the real. Considering a very tight team of 2-3 people and compact design with few requirements, this might just be marginally viable, but anything beyond that and it’s not long before you’re in complete chaos.

One might make the argument that for developmental engineering, where a product doesn’t yet exist in the field, might justify using a more relaxed change process. But any modern design has complex and non optional dependencies including regulatory, environmental, and safety considerations. Changes can cause product failure, and depending on the application may threaten property and even human life. “Real time collaboration” might work for your 3 pages of co-authored Matrix fan fiction. But it’s otherwise a non-starter for any legitimate engineering design.

But before you surrender any hope of collaboration to the machines, the path to streamlined engineering change is a solved problem in the software universe. I’ve written about this at length in a number of places, especially Fork Over Your Engineering Changes over on the GrabCAD blog. Because software is subject to many of the same challenges as engineering physical product, the change methodologies are indeed relevant and are applicable to massively complex products undergoing massively parallel change. What does change look like for this methodology?


Software Source Control

Identifying Change

Need for change is identified by a formal process OR anyone at anytime.

Accepting Change

Change is accepted by merging parallel changes into another branch through a diff to determine the precise nature of the change and the impact on the product.

Making Change

Anyone makes changes at any time and preserved in parallel branch until needed.

Enacting Change

Build and patching techniques control when accepted changes appear in product.

Software Configuration Management (SCM) does exactly what we hope to do. Remove the barrier to making changes while still preserving integrity of all changes and the overall product. Up to now, it’s been an impossible dream for CAD, but Onshape has already taken a tentative first step, albeit an incomplete one. While you can branch designs in the online CAD/PDM tool, merging the design back into another is an overwriting process and does not exhibit the conflict management of a typical diff as used in source control.

While you could use comparison tools to analyze different versions of the same design to qualify changes, it’s dangerous to do outside of something like a relatively simple (and short) Word document. That’s because some otherwise critical design changes aren’t readily apparent visually. Take for example a change in hole size which might change the type of fastener fit, and ultimately the strength of the joint. Visualizing a changed model that may also be flooded with surface changes from minor adjustments like fillet radii may make understanding the most impactful changes difficult. Tools need to be in place the explicitly identify variations in model versions and precisely catalog what changes are carried over in the merged version for something like this to work. What good is a phone call if you’re unable to speak?

So do you still believe in engineering “Real time collaboration” Neo? We can’t dodge bullets just yet. But when the tech is ready, you won’t have to.

  • Ryan

    Another great article. It is interesting that you compared the traditional linear change process with the “collaborative” process. It would also be good to include how these change process might work with ERP system. ERP is the tool that is going to have to stage your changes as well. I feel separating these systems is a disservice.
    A system like Onshape has its niche and that would be, as you alluded too, the initial design phase where you don’t have a integrated manufacturing system to worry about.
    Merging changes is a tough one..You can validate your products for each change but do you have to validate your change for the combined change?
    Here’s a thought. Have a system that allows you to assign a change order number to the feature itself and then allow those changes to be “turned on”/ effective when the change process is approved. Here you could group multiple change requests into one change order and then have the features update when the change order is approved.
    My only concern here is that this type of process requires that you have a “feature-based” model to start with. This in turn usually requires a history-based CAD system. How would you handle a model that isn’t a feature-based model?

    • Ryan, you bring up a great point about ERP which has traditionally been much less forgiving about any process involving parallel changes. I suppose I’ve become a little complacent with ERP’s unwillingness to evolve. One of the many reason BOM synchronization becomes a challenge. I think growing the right capability out of ERP probably won’t happen in a timely fashion; I expect some new products to rise that perhaps define a new category that is a hybrid of traditional PLM/ERP domains.

      Validation is obviously something that will need some level of automation for it to work effectively, especially w/r to impact analysis for multiple overlapping change. I imagine you could have something like a (Merge Change Order (MCO), that validates and authorizes an individual merge, and any subsequent merges would need an automated way to aggregate the change and detect overlapping conflicts. So we’re really talking about the evolution of impact analysis, yes?

      Finally, I’m not sure a feature history is required. What’s exposed as a feature history to the user can be something entirely different underneath, you just need the kernel to be modular enough to allow geometry comparison/replacement/combination to occur. This probably breaks down in lofted double-contoured surfacing, but that’s a special case – make it work first for the sheet metal and machine parts that are so very common.

  • Absolutely spot on. I think the biggest blocker is the diff & merge part. I think the industry standard file formats are not designed for that use case, and really in this day and age that is the most important feature.

    • Thanks and I agree diff/merge is the tallest hurdle. That’s where the newer cloud-based CAD paradigm has an advantage by abstracting file structures, opens the door to build something that could work. There are ways to do it even with traditional binary file structures though, I have been involved in a tech that can do this for MS Word binaries by leveraging Word itself.