Product development and manufacturing process has come a long way in the last few decades. There is one constant thing in the product development process – changes. The question of how to manage changes and perform revision control is one that most companies are looking after. It raises many questions and, to be honest is still very complex and confusing despite it being implemented so many times in many PDM and PLM systems. The roots of the revision control process in most PDM/PLM systems go a long way back into CAD file management. The typical mechanism of revision control for all traditional PDM and PLM systems includes 3 steps: (1) create revision; (2) make changes; (3) save revision (or release). Historically, these three steps were born to align with the typical steps of checking out a file, locking it for changes by a single user, and later saving and releasing a revision. This mechanism is extremely prohibitive when multiple changes need to be done by a group of people.
In my blog today, I want to talk about the modern trend of product lifecycle and revision control inspired by agile software development and Git-a-like processes.
Agile Development – Complexity, Connectivity, and Collaboration
For the last decade, we can see a growing level of complexity in the product development process. There are multiple reasons for that. Products are now not only mechanical parts and assemblies. New products are a combination of mechanical, electronic, and software development processes producing a product that not only behaves as a complex system but is also connected to the internet and evolving over time. Together these products require much more sophistication and collaboration in the product development process across multiple teams.
Another thing is the demand for agile product development. Adam Keating, CEO of CoLab Software, published a great article speaking about evolving trend of agile product development – Can Agile Be Used for Hardware? Read it and draw your opinion. My favorite part of the article is related to the description of modified agile methods that can fit modern product development processes and teams – distributed, overlapped, and collaborative. Here is an interesting passage about breaking sprint goals into reviewable increments and freezable chunks:
Although it’s less straightforward than adjusting sprint cycles, getting comfortable with the concept of reviewable increments is a big power-up for engineering leaders. That’s because this type of agile modification requires developing the right mindset. But once you get there, you can look at the product development process through a new lens — which means you can spot creative or innovative ways to break things down into highly effective sprint goals.
“When key parameters are frozen, dependent design can be finalized. For long lead time items, the lead time governs the point of part freeze,” Eger et al explains. “The design process can be structured by the freeze order of the parts. A design order based on part freezes evolves. It can be used for planning the detailed design phase and reducing the risk of rework. If the design process consists of many phases and tasks that overlap, then freezes can set preliminary information as the basis for further work.“ In other words: thinking about “the freeze order of the parts” can help determine how you might break down your product development process into agile-friendly chunks.
Git Concepts, Collaboration, Workspaces, and Revisions
Agile software development was heavily influenced by the ideas of the Git revision control system. Branches, multiple commits, pull requests, and design reviews. All these concepts were part of software development teams for the last 10-15 years. With software infiltration into hardware development, many product developers started to think about adopting similar processes in hardware design and development.
Here are a few examples of modern CAD and PLM systems rethinking the versioning and revision control system to make it modular and collaborative.
Onshape MCAD introduced a Git-like concept in mechanical design. Check the following article by Onshape -Under the Hood: How Collaboration Works. Onshape creates a single workspace where users can make changes and pull data from multiple iterations to see results. Multiple people can collaborate to make those changes. At any moment in time, you can create a version (immutable snapshot of design) that will be preserved and used as a small step in the product development process. A micro version is a concept that was taken by Onshape from Git to implement a workspace/version control approach.
Here is the passage:
This mechanism is similar to (and was inspired by) what the popular software version control system git does, with microversions corresponding to git “commits” and workspaces corresponding to branches. A conceptual difference is how we handle conflicts: if you’ve used git (or any other version control system for text or code), you’ve seen a merge conflict that happens when two branches have modifications to the same piece of text–the user is left in an invalid state until the conflict is fixed. In Onshape, we try to never block the user: if a dimension is modified in two different ways on two workspaces, in a merge, the “from” workspace will win. Merge conflicts should never happen.
I found a similar mechanism implemented by AllSpice, a new data management system for electronic design data management inspired by Git. Check the article – Git for Hardware. The article outlines the way how AllSpice revisited agile product development and the Git process for PCB design to make it decentralized, to support, pull requests, branches, and design reviews.
Here is an interesting passage, which explains the advantages of decentralization. The concept of AllSpice (and Git) is to allow to pull files and data under user control and after design review to merge it into a single branch (or use multiple branches) until pulling it all together.
Centralization has certain advantages, like everyone having access to the exact same set of files and the final released files being unambiguous. There are a lot of downsides, though. In order to make a change to a file, you either use a system with the first change to a file going through, or you need to use a checkout/checkin process. Locking files can prohibit productivity and can often prevent people from contributing their changes while someone else works on the design. Centralized revision control also limits the types of changes you make to the design. It can be prohibitive to create an alternate design with prototype or experimental changes
Decentralized revision control gives everyone equal footing to look at and make changes to the design. Because everyone has a copy of the design on their local filesystem, they can make whatever changes they want to the files and push them to the server when it makes the most sense. Some might think that a centralized design would create a process that is more rigorous and produces the correct intended design, but with a decentralized approach, every change must be reviewed before being merged into the design.
Users of a decentralized system push their changes to the server, and the maintainers decide which of the changes get accepted into the repository. Decentralization may seem backward to some, but the added flexibility allows for more people to participate more frequently.
My next example of a Git-inspired revision control system is OpenBOM (disclaimer- I’m co-founder and CEO). OpenBOM created a Git-like system allowing engineers and everyone else to work on changes in Items and BOMs in a collaborative workspace (called Latest State) and once a minimum of small incremental changes work is done to save it as a revision in such a way it will become available for everyone for reference while the team can continue to work on the “latest” state in a collaborative fashion.
Check the following article – Change Management in OpenBOM – Revision, Change Request, and Change Orders explaining how this mechanism works for Item/BOM revisions, change requests (revision candidates), and change orders. OpenBOM’s new type of revision control automatically collects all changes and allows collaborative work without blocking individuals and multi-disciplinary teams. Check the following passage:
Modern manufacturing and product development environments created a demand to rethink the way revision control can be done for distributed teams to support agile product development methods. OpenBOM allows multiple users to perform simultaneous editing of BOM’s “latest state” and promote the results to a revision once the desired maturity level is reached. OpenBOM allows the team to manage revision and change management processes by multiple engineers, production and procurement planners, contract manufacturers, and suppliers all working together collaboratively in real time. It saves tons of time and money for manufacturing companies.
My last example is Adam Keating’s company CoLab Software which introduced a novel design engagement system to support a review process allowing multiple teams of engineers to work together to make the right decisions faster. Here are interesting capabilities of CoLab:
Requesting a review is fast and simple, so designs can be reviewed early and often without any extra admin work (like building complex PowerPoints, scheduling meetings, endless email chains, etc) Asynchronous collaboration is more effective because feedback and design files are centralized, with comments and revisions updating for everyone in real-time
What is my conclusion?
The agile mindset is here. Modern product development demands new types of processes and collaborative work organization that are different from the way traditional CAD and PLM systems were designed to work 20+ years ago. The need to collaborate in a distributed environment across a multi-disciplinary engineering team to support agile product development and project management, distributed revision control, and agile and faster change management process. I can hear about requests from many agile development teams looking for concurrent versions systems, and early and continuous delivery systems as a way to get customers’ competitive advantage to introduce agile methodology into new product development and engineering change management for all mechanical, electronics, and software development together. I expect in the next few years to see modern PLM software introducing new agile processes to support modern life cycle methods to hardware development. The changes are coming. Watch the companies I mentioned in my article AllSpice, CoLab, OpenBOM, PTC Onshape, and others bringing innovative product lifecycle management technologies to the world of manufacturing.
Just my thoughts…
Best, Oleg
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital thread platform including PDM/PLM and ERP capabilities that manages product data and connects manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.
