After a couple of weeks spent looking at data management related tools, Al Dean has a little rethink. It might not be the most interesting of subjects, but it’s one that’s seeing some innovation and fresh thought
No one went to college to study entering things into cells on a spreadsheet (except, maybe, accountants). Yet, when we think of data management, that’s the fi rst thing that comes into our mind — at least it does for me.
At DEVELOP3D, we’ve always thrived on writing about the creative aspects of design and engineering and, yes, the tools involved in the process, be they a 3D design system, a simulation code or a method of building prototype parts. But alongside this, there’s always the need to document the development process and to control the evolution and progression of that information as it makes its way into production.
Management is never a word to get the blood pumping, but it’s an essential part of the process.
With the wider adoption of 3D design tools and their inherently more complex interfile relationships, came the need for more complicated data management tools. Whether you called it Engineering Data Management (EDM) or Product Data Management (PDM), these allowed those engaged in design and engineering to capture the state of documentation, control version and revision status — basically keep some semblance of order in a chaotic time.
Then came the Product Lifecycle Management (PLM) movement, whose goal was, irrespective of vendor, to extend these tools way beyond both the engineering department (to capture much more data involved in a product’s lifecycle) and pure development and into production, manufacturing, service life and eventual retirement and disposal.
But during this period of expansion and extension of coverage, much of the process hasn’t changed. It still comes down to grabbing your data, filling out another set of boxes and adding it to the stack of data. In short, while we’ve gained the tools we want, the experience of using those tools hasn’t changed — we’ve just got more people fi lling out more boxes in more systems.
But now we’re starting to see some interesting capabilities, if not for the wider “product lifecycle” segment, certainly in the more formative and fluid stages of a product’s development. Recent cloud-based systems have brought about some underlying architectural changes that are allowing a concept of Branching and Merging. This can now be found in both Fusion 360 and Onshape and while those systems’ implementation differs, the core concepts are the same.
But what the **** is it?
Branching and Merging is a concept that’s been a core part of software development for decades now, but it really took off when distributed development systems made the process more connected.
In basic terms, a traditional development process is linear in nature. You have a set of code that gets incrementally edited and versioned. Version 0.1 becomes version 0.2, 0.3 and so on. Each builds on the one before until release.
A Branch and Merge approach differs in that you can start with the same 0.1 version but at any point you can split the development process to explore options, variants or new ideas.
This is called branching. Essentially, you split development into the main branch and have offshoots that are part of the project, but are progressed independently.
In our figure above, you’ll see the linear process at the top, then a Branch and Merge approach below it. You’ll see that the branches are individually version controlled, just as the main ‘branch’ is.
Bringing ideas together
The ‘Merging’ part comes when you have decided how to progress your product further and want to rationalise these design concepts and variants into a single set of data with which to proceed.
It may be the case that one branch is the winner. In this instance, you’ll merge this branch into the main development process, essentially overwriting those before it. And you continue as you would.
Where things get complicated is if you have ideas in branches that you want to combine with the main branch in order to reach the ideal solution.
While in the software world, this is comparatively easy to do (you’re working with text), there’s a little more complexity involved in design, particularly when you consider that a product is, in the vast majority of cases, made up of multiple parts and subassemblies.
Each system that provides this has a different approach to how it handles different versions and branches and, as ever, each has its own language and terminology that needs to be understood to make the most of the potential.
And there is rich potential here and undeniably a benefit to using this type of approach — particularly during those early, fluid stages of design but it’s one that’s going to need time to settle. If you want to make the most of it, your organisation will need to establish best practices (particularly if you’re working on more complex products with a larger team) as things can get very messy, very quickly.
Al Dean thinks that they are seeing some innovation and fresh thought
Default
