The Implications of Going Fileless
Table of Contents
A few weeks ago, we covered the general advantages of switching from a desktop-based environment to the cloud for collaboration. Emails can get lost. Attachments can be deleted or forgotten. Merging multiple changes is difficult. The cloud addresses all of those challenges in collaboration.
Now, we talked a lot about files and the challenges that come with them in that post. Frankly, the issues in that post are relevant to almost any scenario. They weren’t necessarily specific to circuit board design. However, there are some specific issues specific to design that we haven't discussed yet. Those are issues that can be relieved by moving to the cloud.
So that’s the topic that we’ll dive into today.
First, we need a baseline for this discussion. For that, we need to review how ECAD applications and files work. These tools were initially developed long ago before the internet rose to play a prominent role in product development. Engineers would develop diagrams and layouts with their ECAD application connected to a company standard library, which was full of static information about electronic components. Those diagrams and layouts were saved as individual files.
The key here is that these files represented different ‘states’ of the design. Create the first diagram and hit save? That represented one state. Make five changes and hit save? That was a second state. Build out the first board layout? That was the first state. Move three components? That was the second state. Sets of changes were bound to a single file.
So, what if someone wanted to move one component one millimeter? Well, they would have to gain file permissions to the entire file. Once they gained access and made the change, well, that would be another state. That wasn’t very convenient.
What if, during desperate times, three people needed to explore three different design simultaneously. Sorry. Can’t be done. One person could open one file at one time. That is inconvenient, but we learned to live with it.
Unfortunately, this one-file-many-changes paradigm has persisted to today.
How do things change when they move to the cloud? Well, it depends on how the software provider makes the switch.
Some want to get their application in the cloud quickly. In many cases, this means hosting the software in a virtual machine that runs on a remote service. With this approach, it is basically like remotely connecting to a software application running on another computer. It still has files. It hasn’t been architected to take advantage of a cloud infrastructure like expandable compute resources. The file-based issues persist in this kind of setup.
Some develop the software specifically for the cloud. Here, the individual things that exist in the files are individual objects, each of which can be changed independently of one another. Need to move a component? The location of that component in the layout changes, not the entire layout. Need to swap out one component for another? That is an individual change that affects the assembly of the layout.
This latter approach allows for granular changes that can be executed individually without locking out anyone else. This is the critical capability that allows many people to make changes simultaneously to different aspects of the same design.
Let’s step back and consider the value of this change. Here are some implications.
Design Collaboration: Multiple engineers can make design changes in the same diagram or layout at the same time. In some industries, individual boards and board systems are getting quite large. It is increasingly likely that multiple engineers will need to design boards concurrently.
Exposure of Design Changes: In a file-based world, individual changes were hidden away in the file. Someone looking at the file could tell that a change occurred, but without opening the file, they didn’t know what the change was. Engineers won't need to open the diagram or layout to see those edits. Instead, a dashboard can show what types of changes like a moved component, switching a component out, or a board outline modification occurred. Everyone can see it.
That, in turn, leads to some of the following.
Increased Throughput: Sometimes, especially at the end of a development project, there is a crush to meet design release. Engineers will, at times, be in a queue to make the change to a board or relay their requests to the one engineer making changes. With the cloud, they can get those changes completed faster.
Lower Effort Oversight: There’s no shortage of project management meetings where engineers have to relay the status of their design. In the past, preparing for this meeting took some time. With the cloud, that information can be accessed directly instead, eliminating some of that prep work.
At first glance, going file-less with a cloud solution might not seem like much. However, some advantages can make a difference. You have to look at some of the details, traditionally hidden away in files, to see them.