An experiment in Digital Transformation has been going on for 40 years. Whilst many good things have come out of it, there have also some bad, and the downsides are the way it has changed people, skills and professional culture.
This experiment has been the introduction, and then continuous development, of structural analysis software. This started with simple stick models at universities and innovative companies. These became linked to spreadsheets, then moved into Finite Element Analysis of solids. Then checking code compliance and connection design emerged followed by links into our drawing tools. Now the future is increasingly parametric with artificial intelligence on the way.
I’ve been able to watch all that happen over the past 35 years, and we have all rightly embraced each of these miracles. But each development has also shifted the balance of skills in teams and subsequent generations structural engineers, and many think not all these changes are for the best.
Are we storing up problems going forward?
At university I was taught two approaches to structural design:
- Quantitative; which works out exactly where the forces are and their values, and
- Qualitative; which is used to gain ‘a feel for the behaviour’ of a structure
Later I saw this split expressed as:
- Quantitative design takes an existing geometry and focuses on defining the force path in detail through that geometry.
- Meanwhile qualitative design
allows the engineer to place the forces
where they want them.
I’ve always loved that idea of placing the forces and the element of choice it brings. You are the one in charge of the design, whilst with a qualitative approach you are the victim. You get what you get. The qualitative teaching at Southampton University, based on the work of David Brohn, had the greatest influence on my career of any course I ever took. It gave me the ability to quickly think about structural options, mentally play ‘what if?’ and know how to morph the scheme towards a better solution.
Let me tell you a story from right back when I started working as a structural engineer
The first moment I had my eyes opened to this idea of ‘placing forces’ was a few months after I joined Arup Associates. I was working on Stockley Park for Charlie Wymer. He was a fantastic person to have as your first project engineer, spending much of the time with his feet up on the desk, smoking roll ups and thinking great thoughts.
He was designing the vaulted roof of the sports hall on an A4 sheet. The arch was pushing the supporting wall outwards and the resultant bending increased the column size, meaning it was wider than the wall. The resultant brick pier inside might injure people; on the outside it would be ugly from the approach road.
So, Charlie added a short cantilever at the top of the column and landed the roof beam on that. That moved the reaction and creating an opposite flex in the column, halving the moments and, magically, the column fitted inside the wall without a pier. This change also led to a better way of accommodating the gutter and a new lighting arrangement in the hall. Win. Win. Win.
In a way this is a trivial example (1), and since then I have seen and been the cause of many more dramatic adjustments to structures that move, reduce or express the forces. But for me this example was the lightbulb moment when I realised all that qualitative ‘feely’ stuff could put me in charge of a structure, and that has been the basis of much of my subsequent career.
I fear digital transformation has reduced the likelihood that changes like this would happen. An engineer would refine the answer to the first scheme presented rather than wondering what changing the question would bring. The final product would suffer as a result.
The rise of Quantitative over Qualitative skills
Computers are good at doing calculations and hence are fantastic tools for quantitative analysis. They are naturally precise and good at answering ‘closed’ questions. Software development has focused on detailed design, which is where most of the design hours are expended and where they clearly can save time.
But computers are currently not so good at intangibles like gaining ‘a feel for the behaviour’. The increasing reliance on software has encouraged these qualitative and quantitative approaches to split into two separate groups of thinkers, rather than being blended within each one of us: Designers and analysts.
Back in the 80s and 90s hardware and software was more rudimentary, meaning you needed to build all aspects of analysis models up from scratch (2)
and therefore you had your hands all over the assumptions of how your engineering was going to work. Qualitative and quantitative remained naturally intertwined.
Over subsequent years more and more assumptions have been built into the tools. Code based analysis of members and connections have become integrated. Yes, I think this is a great step forward, and yes, there are still ways to climb into the model and vary these underlying assumptions, but too often engineers just accept the defaults. Many say it is due to time pressure caused by reduced fees, but it is increasingly a result of shifting skills and team cultures.
It is not just new recruits that are being influenced by the software tools we are using. In some sectors major projects have design period that can last for a decade. As a result, engineers aren’t seeing the early, fluid stages of design very often in their careers. The focus has become building sophisticated models for final assurance, sometimes at an inappropriately early stage.
What can the wider construction industry learn from this experiment in Digital Transformation?
As the pace of digital transformation accelerates, we need to remember that people are always a key part of any system we create. We forget this because, psychologically, engineers are often more comfortable with things, systems and processes, and less happy dealing with the soft, squishy people issues we encounter. There is a danger that we end up seeing people as a problem, getting in the way of digital transformation.
Yes, but also no. I’m going to borrow a slogan from Laing O’Rourke’s ‘Next Gear’ safety campaigns. ‘People are the solution’.
If engineers can train with use tools that allow them to play qualitatively with their designs and use the right level of model granularity at the right project stage, software will be an increasingly wonderful thing. Can there be a qualitative ‘front end’ that allows mental exploration before the jump into detail that requires change to stop? University training (3)
and software providers need to step up to the challenge.
Then the culture of design teams needs to nurture and reward these qualitative skills. It is encouraging to find companies like Robert Bird Group working with David Brohn to develop and maintain the awareness, skills and culture needed for people to remain in charge. This cultural change will require constant nurturing but is vital.
Digital transformation will be fantastic if people can see inside the black boxes we use, and if these tools give understandable feedback allowing engineers to remain in charge of the outputs. If we get it wrong, we could be in for some unplanned and unpleasant surprises – and artificial intelligence will compound this mess rather than refining and improving as is hoped.
We must always remember that digital transformation involves people and our tools, process and culture must allow them to remain in charge. Where do we want to go? What do we want to do? How are our tools going to help us?
People-centric transformation please, not disruption.
1. Not only is a hammer beam a trivial example, it is one Charlie borrowed from centuries of cathedral builders
2. Fun fact: I wrote the code for Arup’s first composite beam analysis software as part of my summer job in 1985. 35 years ago!! AAAAAGGHHH!!!!! There will be a blog post in July.
3. I am aware that several university structural engineering departments have been butting their heads against this for a while. It doesn’t feel yet like we are winning the battle.