What makes Built Environment data different?

The premise of this (relatively short) article is that there the challenge of using data to improve our built environment is not completely tackled by industry-agnostic data texts. If there were no unique challenges in applying data to the built environment then could simply read a few of the many great books on data architecture, governance, strategy and science out there and forgo this article entirely. I do not believe this to be the case. There is definitely a lot of cross-over in terms of data domain technical knowledge, as a data professional working on the built environment you will be using many of the same tools and techniques as your peers in other industries. However, I believe that to apply data to the built environment in a meaningful way, we will benefit from first reckoning with what is and is not unique about the sector.

So what are the unique challenges in applying data to the built environment? Whilst it would take an entire book to answer that question convincingly, there are a few broad themes...

First is the connection to the real world and physical assets. Working in this sector, you are likely to be part of the cycle of collecting information on physical assets, and helping to determine actions that can be enacted in the real world. This affects the types of data we use, and how it is used, in profound ways. It also often increases the cost and complexity of gathering data in the first place and raises the risks involved with getting it wrong.?

Second is the culture of the built environment sector. Our culture flows from our history- both good and bad- and the distinct professions and ways of working that have evolved over hundreds of years. This culture has in turn determined how the sector has, and has not, successfully adopted digital technologies. Just as importantly, the culture of the built environment changes the experience of working there. It’s worth noting here that the sector has always been dominated by mostly white mostly privileged men. It has not always been a welcoming sector for women, people of colour, or people with disabilities. And these problems are far from resolved. The culture can be extremely hierarchical, slow to change, and often quite risk-averse. We write more about how you can help to address these issues as a data leader later in the book.

Third, related to the points above, is the historical legacy of the sector. The ways of working that we have inherited from storied institutions such as RIBA, ICE, and RICS still inform how many people in the sector think about their skills and their career progression. These ways of working have also created uses of technology that are unique or particular to the built environment, as well as a long legacy of incomplete adoption of good practice digital processes and tooling from elsewhere. From a technological perspective, the built environment can feel like an island, cut off from the mainland, where the local flora and fauna have evolved in strange and surprising ways.

On the other hand, data is data (or should it be ‘data are data’?). The ones and zeroes that comprise data concerning the built environment are no different to those used in any other domain. Much of the underlying infrastructure is the same, particularly now that so much of our data has migrated to AWS, GCP, and Azure. Nor are the volumes of data generated by the built environment particularly profound. IoT-enabled infrastructure can quietly rack up billions of rows of data, BIM, point clouds, and high-definition imagery. Sure, they all get pretty chunky, but rarely do you come close to the types of volumes seen in social media, streaming content, banking, or retail.?

So if the difference isn’t the data itself, then perhaps it is the meaning we ascribe to that data. We write later in detail about the use of taxonomies. The built environment is full of taxonomies, even if they are rarely labelled as such. Perhaps this is because construction has always relied on a degree of mental abstraction. Architects and engineers are people who can imagine physical things that do not yet exist. They are also people who can lay out a logical structure of activities, often consuming vast pools of resources, and make those imagined physical things a reality. This exercise in abstraction is made much easier through the introduction of standard subdivisions: division of work into stages and tasks, division of structures into their component parts, and division of resources and skills into specialities. It is only by subdividing and standardising that building and maintaining structures designed to last for centuries becomes anything other than completely overwhelming and mentally fatiguing. A taxonomy is a means to subdivide and standardise. Much of the data that we collect on the built environment will be part of a taxonomy. For example, to define a task that forms part of a construction project we probably need to be able to associate it with a) a taxonomy of activities, b) a taxonomy of assets, c) a taxonomy of locations or space, and d) a taxonomy of resources, in turn, related to taxonomies of risk, benefits, costs, etc. This is how we derive meaning for raw data, we associate that data with pre-defined and meaningful classifications (or, phrased another way, data definitions). If we can make our data meaningful in this way then we have gone a long way towards making that data useful to the built environment.

So built environment data is sparse but dense. There isn’t always that much of it, but what does exist is filled with meaning.?

If one were to compile a list of critical datasets for infrastructure-owning organisations many of those datasets would only be a few kilobytes in size. However, the meaning, completeness and accuracy of those records could have a profound impact on the well-being of others. Directly, or indirectly, they could be a matter of life or death. Many of us, particularly those of us fortunate enough to live in advanced economies, take the safety and functionality of the built environment for granted. But we shouldn’t, the first truth of the built environment is that nothing lasts forever. Every physical asset that humans create will eventually fail. Some fail quickly, others slowly, some predictably, and others at random. The built environment functions in spite of the inevitability of failure in large part because we have learned to use data and information to coordinate our response to failure. And we did so long before there were such things as terabytes of data. Instead, we relied on a few small but important facts about each of our assets: where it is, what it’s made of, when it was built, when someone last went to look at it, and what condition it was in when they did. We wake up in the morning and expect the lights to switch on, for clean water to come out of the tap, we expect to be able to plan a safe and timely journey to work, and be able to text our friends on the way there. All of these actions that we take for granted are a triumph of the built environment over failure, of order over entropy, and often thanks to small but critical amounts of data.

Some examples of ‘small but dense’ datasets vital to the built environment include:

• Asset registers (the composition, typology, and location of a portfolio of assets): what is this asset, and what other things is it comparable to?
• Condition assessments: how proximate is this asset to failure?
• Maintenance records, when did this asset last receive care??
• Risk assessments and health & safety files: what are the hazards associated with accessing and maintaining this asset?
• As-built drawings and models: what is the structure and composition of this asset, and what is it supposed to look like?
• Engineering models: how is this asset supposed to behave?
• Whole life cost estimates: what resources did this asset take to create, and how much will it cost to replace?
• Telemetry/monitoring: how is this asset performing now?
• Whole life carbon estimates: what impact does this asset have on the natural environment?

As the simple questions appended to each of the datasets above imply, it’s not asking much to capture this information about the physical assets that compose our built environment. Properly specified, and stripped of supporting images and documentation, you could fit the crucial records of an entire country’s critical national infrastructure on a USB stick. And yet, many infrastructure owners have historically failed to accurately capture and maintain this fundamental record of their assets. The impacts of not collecting and maintaining accurate records on our built environment are direct and indirect, visible, and hidden. They include:

• Direct, visible impacts:
• Risk to the lives of members of the public: while infrastructure failures are rare, when they do happen (such as Greenfeld Tower or Hatfield Rail Crash) they can have a profound human cost.
• Risk to the lives of staff: poor records in construction contribute to the loss of life in the industry, for example failing to identify on-site hazards or hidden services.
• Indirect, hidden impacts:
• The less we know about our assets, the more likely they are to fail unexpectedly. This can quickly result in substantial knock-on effects as members of the public struggle to get to work, or to access vital services.
• Conversely, if we do not know enough about our assets we may be overly conservative in our maintenance activities (e.g., seeking to maintain assets when they are still in good condition) resulting in excessive costs and/or poorly prioritised work.
• Poor planning due to poor information results in redundant or sub-optimal allocation of resources, from simple examples like digging up recently laid tarmac, to more systemic problems such as making major public expenditure decisions on incomplete or misleading ‘return on investment information.

Often the problems that really bedevil the built environment involve ensuring the accuracy of these moderate amounts of data. We need to be sure that the records we hold in the information domain actually reflect the reality on the ground. There are many reasons why they may not, some causes of inaccuracy include:

• Measurement errors: we simply don’t collect the right data, either due to poor tooling or poor training.
• Validation errors: for example millimetre dimensions recorded as meters.
• Loss of historical record: lack of effective information/records management and/or deprecated or inaccessible file formats lose valuable information that we have gathered in the past… or we simply don’t think to look.
• Inconsistent definitions: accuracy depends on definitions, in the sense that one can only say whether something is accurate if one has meaningful definitions to test that accuracy against. Where organisations work with inconsistent definitions then loss of accuracy is inevitable.

Not all physical assets are created equally. Typically greater data accuracy and/or higher levels of precision incur greater costs. For less critical assets a degree of inaccuracy may be a cost-effective choice, one may not, for example, need to know the location of streetlights or telecoms base stations to the nearest millimetre.?

Where built environment data matters it can really matter. I became aware of the importance of data quality early in my career as I tried to help a large infrastructure owner figure out how many tunnels it maintained. The low precision order of magnitude answer was always somewhere between roughly five hundred and seven hundred, a trivial amount of information. The specific answer was another matter entirely and depended on meaningfully answering questions such as:

• At what bore diameter does a culvert become a tunnel?
• If I build a really wide bridge, cover it with soil, and run trains under it... have I actually built a tunnel?
• Does a tunnel that has been sealed up and is no longer used still count as a tunnel?
• How do you account for tunnels that you share with other infrastructure owners?

At times it was possible to enjoy the absurdity of your task, was it even possible to meaningfully answer these questions? But then parts of tunnels and culverts started failing, in ways that could potentially have hurt lots of people. And it became clear that the categorisation of these assets would determine how they were maintained, who was responsible for keeping them safe, and what kind of level of investment they would attract.?Ultimately that’s what makes the application of data to the built environment meaningfully different is the impact that it can, in turn, have on wider society, the quality of life that people experience, and the safe enjoyment of public services that we all take for granted.