Digital Transition
Alexandre D'Amours - 2020-07-02
1. Introduction
The advent of the personal computer transformed the everyday workflow of most professionals. The advantages over legacy methods of doing business were multiple: automation of repetitive tasks, the ability to edit as often as necessary and the cheap storage massive amounts of data, to name a few. Starting off as a simple tool that was nice to have, computers now have a central role in any modern business.
2. Accounting
Accounting was one of the first professions that be displaced into the digital realm. With the advent VisiCalc on the Apple-II personal computer, accountants had little choice but to make the move. A good description of the saga is given in NPR's Planet Money podcast, Episode 606. A large part accounting had been updating their desk sized paper spreadsheets. With the personal computer, this could be done and checked visually on the screen in a fraction of the time. Would the new software "kill" accounting?
Figure 1: VisiCalc software (1979) screenshot
It ended up being quite the opposite. With the new software, accounting became faster and businesses simply demanded more of it. Broadly speaking, demand for accounting services increased. While the everyday work of accountants was modified, the profession itself was nowhere near being replaced.
The VisiCalc story became the poster child for the digital transition. Every field was on the verge of having its "VisiCalc moment", where some new "killer app" would sweep in, brings costs down and open up new markets.
3. Structural Engineering
However, some fields, like structural engineering, have been slower to transition (much to the frustration of younger generations). At first glance, much of the reluctance to embrace the digital seems to stem from inertia or resistance to change of older generations. This conclusion has led many young engineers start new firms of their own, where new technologies can be embraced to their full potential. Starting fresh, they are able to cut out most of the redundant paperwork of legacy methods and be much more efficient.
By and large, the speed of the transition to digital seems to be inversely proportional to the complexity of the field. Health-care and construction are examples of such fields with a multiple subfields working together on single projects. More complex fields are more error-prone, and this is compounded when you have multiple actors with different workflows working on a single project. More complex fields also require more complex software, which is harder and longer to get right.
The majority of structural engineering firms rely on a mix of pen and paper and computer software for everyday projects. At the margins, some firms barely use computers (for structural engineering work) while others are entirely paperless. So which is it? Are structural engineers stuck in their old ways and simply unwilling to embrace new technologies? Or is it the other way around? Are newer firms ignoring tried and tested engineering practices while pursuing extreme efficiency? Let's try and break things down to have a better look. A typical structural engineering project can be split into at least five phases: preliminary design, drafting, coordination, calculations and review.
3.1. Preliminary Design
Experienced architects will understand enough about structural engineering to avoid most major structural problems. However, not all architects are well versed in structural design and even the best architects cannot be expected to stay up to date every innovation in structural engineering. Good engineers should strive to be involved quickly in the process to help counsel architects on the impact of their preliminary design choices.
For structural engineers, preliminary design is first an act of creativity. Although the architects usually have a base concept, they need to be informed about the different structural alternatives and their respective advantages and drawbacks. To consider many options quickly, actual calculations must be kept to a minimum. Most engineers still seem to rely mostly on intuition, pen and paper and simple rules of thumb in this phase.
Figure 2: LeMessurier's sketch for the infamous CitiCorp Center, Ney-York City
Preliminary design has not gone through it's "VisiCalc moment". For most firms, sketching with pen and paper is still more appealing than sketching on a screen. Simple equations, rules of thumb and intuition are much simpler and faster than opening up any software that might claim to be of assistance. There are exceptions: some firms have custom-built tools for preliminary design. However, we have yet to see simple and efficient software solutions sweep the whole market.
3.2. Drafting
Even though structural engineers rarely draft their own plans, they should understand how it is done. In the 1980s, the drafting profession went through a rapid digital transition. This time, the "killer app" was AutoCAD from Autodesk. It was the beginning of a new design paradigm: "Computer Assisted Design" (CAD).
Figure 3: Autocad software (1986) screenshot
AutoCAD made drafting much more accessible: anyone with a computer could start instantly. Any mistake could be corrected at very little cost. Physically, the need for large spaces to accommodate drafting tables was eliminated, reducing office size and related overhead costs. The transition from paper to digital was very similar to the "Visicalc moment", leaving anyone behind who didn't adopt the new technology.
It didn't take long for the discussion to extend to 3D models and parametric modelling. Would it be possible to model and visualize every single component from every trade?
Creating an easy to use parametric 3D modeling software has proved a tall order, even for software giant Autodesk. On one hand, centralizing all the functionality needed for all fields into one software requires complexity. To keep the software proprietary and user-friendly, much of the functionality must be hidden or locked from end users. While this creates an incentive to switch for new users, it is to the detriment of functionality for more experienced users (as can be seen here), who often need to create workarounds to get simple things done.
While many believed the Building Information Modelling (BIM) revolution would be a second "VisiCalc moment" in the early 2000s, the transition has not been ideal. In North America, we still seem to be in the midst of a slow transition towards 3D modeling, much to the frustration of anyone caught in between two worlds. The drawn-out transition to 3D modeling adds friction to an already difficult transition, with firms having to understand two different paradigms of design and how to interchange between the two. This has led some countries to legislate, with the United Kingdom leading the charge in April 2016 by requiring level 2 BIM on all public construction projects.
Drafting is way past its original "Visicalc moment". In fact, it's so far ahead it's in the process of upending itself for a second time with parametric 3D modeling. Every new software update adds value with bug fixes and new efficient BIM features. So what's the catch? Is the new efficiency exposing risk elsewhere?
Some redundancy is lost when modelling in 3D as you only build your model once. Any initial mistake has more risk of flying under the radar. However, most would agree: the cost is slim compared with the advantages of actually having a digital model in 3 dimensions. Pushing anything into the visual realm should always be a priority when creating design software. The visual field is great for reinforcing experience and intuition. For anyone who would run into more problems with 3D models than with 2D drafting, adding a 3D coordination (possibly with the 3D structural model or with 3D models of other professional) could be a simple way of adding layer of redundancy.
3.3. Coordination
Coordination is the act of validating that two of more models (or plans) are consistent. The present state of the coordination phase is highly variable. Some firms print out and check the paper version of 2D plans, while others have already moved to shared 3D models and check for conflicts digitally, assisted by software. Most firms seem to be in the middle, using a mix of 3D and 2D models, printing, screenshots and software assistance.
Apart from the consequences of the difficult transition period, we can wonder if something will be lost when coordination moves completely to the digital world. Where is the added efficiency creating fragility? And what is the magnitude of this added fragility?
Software driven coordination means less redundancy between professions, that is, each profession might tend to start "working in silos". If each professional simply adds his elements to a centralized 3D model, he doesn't have to rebuild his own model from scratch. He doesn't have to understand how the other professions work. This redundant modeling might be an important error detecting mechanism that will be lost. Also, it might also lead to blunders in the short term, while the software is still being tried and tested. Most of the algorithms used are "black boxes", so it's quite difficult to know how they work for edge cases until something goes wrong.
However, for the time being, most engineers seem to agree: there are benefits to cautiously using digital tools for coordination and the benefits will increase as the tools are refined. The drawn out transition period seems more problematic than the new technology itself.
3.4. Calculations
Structural engineering calculations are quite varied. They can be graphical, numerical or iterative, among other things. Most firms use multiple software solutions, from paid proprietary products to home-made digital tools and hand calculations.
The move to digital has sped up calculations in many ways. Modifying and editing calculations is much more efficient than by hand. For anyone who knows a little programming, efficiency can increase by yet another order of magnitude.
The backbone of digital calculations is 3D Finite Element Analysis (FEA). Using FEA software pushes a lot of complexity into the visual field, where our intuitions are strongest. Being able to see deflected shapes, loads and diagrams in 3D is not only more efficient, it becomes and added error detecting mechanism. Having a good modeling process (checklist, for example) can help add quick redundancy for very little cost.
However, FEA software will return results no matter how little you understand them (garbage in, garbage out). Unqualified designers can use FEA software and get results like anyone else. There is something to be said for finding ways of restricting use to trained professionals, but that's a discussion for another time.
There are also problems for competent structural engineers. The ease with which you can build, modify and analyze a 3D model is very attractive to anyone looking for added efficiency. Why have preliminary hand calculations if you can already start on your 3D model? Why annotate plans when you can send a 3D screen grab? Why create a calculation report when you can simply access the 3D model at a later time? The collapse of many activities into one is a reduction in redundancy, thus of safety. If you are calculating a project a day or more using FEA software, you might want to find ways of reintroducing artificial redundancy into your workflow.
The use of many different software solutions has transformed a large part of the structural engineering workflow into boring and error-prone data transferring. Transferring data from one software to the next is problematic because it adds steps that can lead to errors, but without error detecting redundancy. Sometimes, software solutions can be programmed to automate transfers, but, more often than not, they are black boxes that cannot be modified. This is understandable. For most structural engineering software companies, the code is the product. Thus, the vendor and client incentives aren't exactly aligned, which leads to less value for structural engineers who are stuck copy/pasting data from one app to the next.
The growth of home-made software solutions is problematic enough to warrant a separate post. Suffice to say, as software engineers have discovered many years ago, all software is created equal: with loads of mistakes. This does not seem obvious to all structural engineering firms, and neither is the magnitude of testing required to reduce risk to an acceptable level. For anyone who knows a little programming, the risks are compounded. For any firm that distributes home-made software to many engineers, loss of accountability and complacency of validation become serious issues that are seldom dealt with.
3.5. Review
The review phase can be split into two parts : review of plans and review of calculations.
The review of plans has not been very affected by the digital transition of drafting. The final product remains 2D paper plans, and that is what must be reviewed. Some firms have moved plan review and correction to the digital realm, with .pdf annotation software, while others still seem to prefer printing them out for manual annotation. According to some, paper plans offer a better global perspective and fewer distractions for the reviewer. According to others, digital review just takes some getting used to.
The review of calculations seems to have regressed in the digital era. Good hand-written calculations can read like a story. They are chronological and it's easy to follow the designer's thought process. You can see plainly what the initial ideas are, what ideas failed and how problems are overcome. This narrative-driven way of presenting calculations is what comes naturally to most of us. With the flexibility of pen and paper, references or quick sketches can always be added to clarify design intent. In fact, for hand-written calculations, there is often a problem of too much flexibility, with many firms keeping a list of constraints on the content and ordering of calculation notes (mostly for the sake of reviewers).
With the first digital calculations tools, most firms printed out digital reports and added them to their hand calculations. The added efficiency prompted them to find new software to automate more calculations. The "hand" part of calculations was slowly replaced with more efficient "printed" reports, until a large part of the calculations were created by digital means. At this point, having numerous digital reports printed out with few hand calculations seemed like a waste. Why not instead digitize the few hand calculations and have calculations live in the digital realm? Once the scanning of hand calculations began, the added friction of scanning and editing pushed designers towards digital alternatives. In the end, notes and sketches were added to digital files in poorly adapted software or on the actual .pdf files. Notes and sketches are now starting to fade, as they are more difficult to incorporate simply. For some, the bulk of calculations never even make it into reports. They reside inside software (often FEA software) that is digitally signed (or not) at the end of the project.
For most firms the state of internal calculation notes is somewhere between "by hand" and "paperless". For an independent reviewer, it has become ever harder to follow the project narrative. What is preliminary design and what is final design? Where are all of the failed iterations? What are the sources for the calculations? How is each individual part linked to the whole?
Reviewing has always been a straining task. All incentives seem to be against proper reviewing: tight schedules, low budgets, no recognition, threat of complacency, etc. Even success in finding a flaw is oddly perceived as bad news: if you succeed in finding mistakes, you create extra work to fix the issues. Making calculations notes more opaque by using database style calculations or not having explanations or sketches only adds additional friction to the process. Reviewing is the structural engineer's final redundancy, it must be encouraged and made to be as frictionless as possible. In this sense, there are very little software solutions that assist with the review process. Most digital reviewing tools are home-made and largely limited in scope. Needless to say, we are far from a "Visicalc" moment for review.
4. Digital Revoluion
A common business goal since the 1990s has been to go "paperless". What this means varies, but it is usually thought of as the transition each individual "task" towards the digital realm. However, this definition of "paperless" should not be viewed as the end goal, but rather part of a larger transition period. Once everything is done digitally, we can then start to ask ourselves how the digital medium can help us optimize, combine or transform different phases of work. In Matt Mullenweg's five levels of autonomy, the transition from physical to digital is divided into five levels, with full decentralization and asynchronicity as the ultimate goals. For Matt, the "paperless" transition is only level 2, where many firms remain stuck for a myriad of different reasons.
Without aiming at full decentralization, having useful software that is transparent and maximally efficient without compromising on safety could be imagined as the "full potential" of the digital experience for structural engineers. Figure 4 illustrates where each phase of structural engineering seems to be, in our modest opinion.
So has structural engineering gone through its "Visicalc moment"? In many respects, we cannot deny that the field has progressed. CAD and FEA have profoundly changed the way we design structures. Home-made and proprietary software solutions have increased calculation efficiency by an order of magnitude.
Figure 4: Approximate area of transition by structural design phase
However, as we have discussed, game-changing innovations did not happen across the field. And where they did happen, they remain incomplete in many respects. The promise of the digital revolution is to maximize the time each professional spends doing actual work, without inflating hidden risks. In this respect, we believe there is still room for improvement in software used throughout the structural engineering profession.