All software does 4 fundamental things:

• Record information
• Store information
• Retrieve information
• Transform information

That’s it. From the most simple, like Wordle, to the most complex, like SAP’s ERP. At its core, all software is doing these same 4 fundamental tasks but what differs between software programs is the type of information they process and the way they represent this information.

Whether they are aware of it or not, developers are making deep philosophical choices when selecting the types of information they process and how it is modelled.

At one end of the spectrum data is kept very structured and typically stored within a rigid hierarchy. At the other end of the spectrum, the classification or hierarchy of the data doesn’t matter at all. The only thing that matters is how the data is used.

A Structured Approach

Structured hierarchies are great at helping you classify information and quickly find the information you need. However, it has two main challenges:

1. No such thing as a tree
2. This, or that

The first challenge is that our representation of the world may just be wrong. For example, if you walk around outside today you will come across many plants that you will classify as a “tree”. The problem is that many plants that we call trees don’t share a common ancestor. Rather many different plants have evolved into things that look like a tree, but genetically speaking there is no coherent category of tree. Now typically within engineering we have a good understanding of what things truly are and all the characteristics associated with them. But in the early stages of design or with R&D there is a clear danger of miss-classifying engineering data.

The second challenge is that creating a certain hierarchy forces us to make choices about where information belongs. But a lot of knowledge can be classified in different ways depending on what you want to do with it. The easiest way to demonstrate this is to look at shared folder systems. Shared folder systems quickly become unnavigable because different people tend to characterise work in slightly different ways and these differences compound over time resulting in similar documents being filed in different branches of increasingly complex folder structures.

An Unstructured Approach

Unstructured filing of data has been enabled by better search functionality. Previously, with just keyword search, if you wanted to have any chance of finding a document you wrote a year ago, you had to have saved it within an easy-to-navigate folder structure. (See: Effect of File Structure on Personal Navigation for some research on this).

However, nowadays it is possible to just drop a lot of documents in a Google Drive (other shared drives are available!) and use more powerful search functionality to have a good chance of finding the file you want. [As a side note there may actually be a generational divide in how people store files on their computers: File Not Found]

But having no structure to your data storage can also be problematic. Firstly, it doesn’t scale well, particularly in a context where you may have many versions of similar data as is often the case in engineering projects. Secondly, if the data is unstructured it is very hard for a computer to deduce what it means. Meaning is dependent on context. To have software be able to process, understand and manipulate data, it must be structured to provide the context the computer needs in order to understand the meaning of that data.

So where do we go from here?

Engineering data is vast and varied and with multiple differing use cases. In managing engineering data over the project life cycle we need an approach that can span the full spectrum from hierarchical to networked.

If the use case for the data is very well defined, we should be as structured and hierarchical as possible. This will enable fast response times and high levels of context for automation and machine learning tasks.

However, where the use case of our data is not yet defined or where multiple use cases may exist we need to take a more open approach. In this case our data structure will resemble more a network than a hierarchical tree to provide us with more flexibility in how the data is managed whilst still providing some context to the data.

What We Have Been Looking At…

Some links that we have found interesting over the past month:

What we have been watching

A video from Tom Scott about a bridge refurbishment project in Cork that decided to recreate the bridge’s infamous wobble in its reconstruction. It’s remarkable that the bridge originally only cost £700 to build (about $55,000 USD in todays money) using what appears to be a modular approach (there is truly nothing new under the sun!).

Why are the costs of a similar project today so much higher? Certainly material prices are not significantly higher in real terms (see: commodity price index) neither have modern design practices prevented design “flaws” from ever occurring (see: Explaining Why The Millennium Bridge Wobbled). We have a few theories, but we’d love to hear your thoughts.

What we have been listening to

Knowledge Cast by Enterprise Knowledge – Darryl Wing – Director of Knowledge Management at Fluor

A great podcast featuring Darryl Wing exploring Fluor’s knowledge management practices and much more. We love the idea that the focus of knowledge management is to help the project team to “make the best decision every time“.

What we have been reading

Rail accident report: Derailment of passenger train at Carmont, Aberdeenshire, 12 August 2020

The Carmont derailment in Scotland resulted in the tragic loss of 3 people’s lives. Engineering is an empirical discipline that often seems to progress only after some tragedy occurs so it is imperative that we try and learn as much as we can from such events.

3 key takeaways from the report that are applicable to any engineering project:

1. There needs to be a strong process in place to control changes between design and what is eventually built on site
2. There needs to be better information and training provided to the operators of an asset so that there can be more effective incident response
3. Climate change is already increasing risks to our built environment. These risks need to be better understood and both adaptive and mitigative responses made