It is almost a decade since the UK was told that Building Information Modelling (BIM) would become mandatory for all public projects. The approach that was developed through the UK definition of BIM Level 2 has become the global basis for BIM according to ISO 19650.
After a flurry of marketing activity and huge strides being made in technical terms, it seems that adoption and penetration of BIM is stagnating. The UK BIM Framework is firmly set at embedding BIM according to ISO 19650 and the Centre for Digital Built Britain is progressing to develop the National Digital Twin. No one is talking about progressing beyond BIM Level 2.
This paper sets out a future post-Building Information Modelling to enable the vision set for BIM Level 3. The Internet of Construction shifts the focus from collaboration, information management and model federation, and instead emphasises the interoperability of digital construction processes using open standards to pull the data needed at the time of use.
A history of BIM up to 2010
The term BIM didn’t gain traction (2002), whilst the concepts it encompasses date back to the 1970s (see Chuck Eastman et al.’s seminal paper on Building Description Systems). Ideas like Building Product Models, project extranets and virtual reality applications for construction had become well established throughout the 1990s, with many competing terms for what to call it all. (un)Surprisingly, the term favoured by Autodesk won out when their marketing machine rolled out “Building Information Modeling”.
In 2008, Mark Bew and Mervyn Richards published the ubiquitous (but now superseded) “BIM Wedge” / BIM Maturity Model. It set out a progressive approach to improving how the construction industry could leverage BIM technologies by describing the technologies required to achieve each stage of maturity. The heart of its approach was collaborative production and management of construction information through a Common Data Environment and a client-led approach to information requirements. After all, it is the client’s project and they own the data. A collaborative approach was a stepping stone to interoperable data-based outcomes.
In the academic sphere, another seminal output was Bilal Succar’s BIM Framework, which also incorporates a BIM Maturity Model that prioritises model-based production of information as Stage 1, then collaboration as Stage 2.
Maybe it was the limits of what capabilities were available in the market at the time or that the protagonists were highlighting the requirements of the next steps, but both frameworks were purposefully vague on how Level/Stage 3 would work technically.
Why we’ve stalled
Collaboration over interoperable processes
Collaboration is a human process. BIM has been set up so that the process is human interrogable. It is designed to be accessible to practitioners who are not information technologists. The result is a solution that is neither satisfactory to practitioners or information space.
Unfortunately many of the collaborative aspects of BIM prove to be blockers to the true value humans bring to the table; creativity. Practitioners are required to relearn processes for each project and there is never the incentive to invest in repeatable, scalable, automated processes, because the next project will have different requirements.
BIM requires a new language and dialogue that is alien to most practitioners and something that they have no interest in learning.
Common Data Environments
Perhaps, in hindsight it was an error to make the CDE the centre of the BIM process. The idea that everyone in a project should have access to the the information they need is an absolute necessity. Yet the CDE-first approach meant that having a document management system (DMS) with 1192 naming and metadata and a workflow that reproduces the statuses of the CDE gave people a tick in the “doing BIM” box.
Whilst the spirit of the 1192 standards (and now ISO 19650) was the CDE as a process, with connected tools using metadata to help people understand what a “container” contains and what permissions the user has for it.
In practice this has always meant some variant of a document management system, with other database solutions not being able to reproduce the prescriptive naming aspects of 1192 (is a record a container?).
CDE tools themselves are not built on open standards, which means that suppliers who have to adapt to the client or lead supplier’s preferred system on a project-basis cannot industrialise digital construction processes where they involve interacting with information in the CDE. There are some early stage efforts to connect cloud-based CDEs through open APIs, but little has come to market that allows cross-vendor interoperability.
This lack of a consistent API, coupled with the container (file) orientation in naming and storing conventions (rather than a process-driven view based on delivery outcomes) means that means that many early stage discussions and rollouts for BIM on projects get stuck determining and explaining naming conventions,delaying the benefits for something that offers little value in the long term.
The approach is too holistic
Organisational, asset and exchange Information Requirements, information standards, methods, procedures. The scope of the Information Management role is huge. BIM management practitioners need to understand and articulate board-level objectives, have deep knowledge of a range of technical standards, software products and file formats, be adept at people management, workshop facilitation and a broad understanding of all project and asset delivery roles. It’s too much.
There is an unsatisfied tension between the ultimate goal being improvements in construction productivity to the objective being handover of asset information into operations.
The problems BIM tries to tackle are much further reaching than simply “information management”, and yet BIM aims to globally optimise asset delivery. The cost is inefficiency at the individual process level. The overhead of reconfiguring tools and processes on a project-basis is accepted because it makes a project work better overall.
The practitioner’s role is to be pragmatic about what can be achieved with the resources at hand and people are doing an excellent job with the existing infrastructures. It is not to say that the aims aren’t laudable, but it does not incentivise and often inhibits digital transformation at individual process and discipline level.
The information architecture is too visible
BIM allows people to tinker under the hood. In its design to be accessible to the entire supply chain, supporting the lowest denominator and allowing human workarounds for technical deficiencies, BIM inhibits the bleeding edge from achieving its potential.
For instance, COBie, shouldn’t be something anyone ever sees. There should be a mapping from the constructor’s processes to COBie and a mapping from COBie to the operator’s processes. Noone should ever need to open a COBie file directly. Therefore it should be expressed in XML or another robust serialisation format, but it was pitched as a CSV so that even a man, van, dog and shovel outfit could “do BIM”.
BIM Level 2 is has been a huge and necessary step on the construction industry’s journey to digitalisation. It has transferred the industry from thinking about flat paper-based information to data-driven modelling approaches.
However, many of the well-meaning, inclusive aspects of BIM are, in fact, inhibitors to the next stages. A radically technology-first approach based on technological (not process) infrastructures is required if the industry is going to progress further.
The Internet of Construction
An internet is “a global computer network providing a variety of information and communication facilities, consisting of interconnected networks using standardized communication protocols.” The Internet of Things connects physical widgets with each other and online services. The Internet of Production is connecting purchasers, designers and makers for digital and distributed manufacturing.
The Internet of Construction is based on a single premise: Locally optimised digital construction processes exchanging data via open protocols.
It prioritises optimising individual processes to earn small-scale improvements in productivity, which accumulate to deliver transformative performance outcomes through data and process interoperability .
Definition: A digital construction process is any process in the life cycle of a built asset that consumes, processes or produces data.
Rather than the “information delivery cycle” of BIM, the Internet of Construction is a graph of digital construction processes, based on increasingly automated micro-services. Process concurrency, automation and iteration is the basis for project delivery allowing vastly accelerated project delivery and optimisation of local and global outcomes.
Internet of Construction technologies use APIs to exchange information, not files. Information is either available on the Internet of Construction or it isn’t. There will be no human processing to verify incoming data, it will be automatically validated and downstream processes will be triggered as soon as the requisite data is available.
Traditional waterfall-based project management approaches will be replaced by rapid cross-functional iteration and agile multi-disciplinary teams of practitioners and software engineers. Gantt charts will be replaced by systems architectures and activity webs, where the critical path is expressed as the edges of networks.
The Internet of Construction will interact with automated construction machinery, digital twins, digital manufacturing and other connected processes.
The practitioner experience
Just like the word wide web, the protocols will be invisible at the point of use. Tools will be optimised (where there is a human role) for user experience and maximising human creativity.
Practitioners will not need to learn about others’ naming conventions or preferred software format. Information requirements that cannot be delivered through automation, will be served directly to users in a seamless manner and validation will be native to all tools. This will all be translated invisibly by Internet of Construction technologies.
The project manager’s role will become much more aligned to that of a systems engineer.
Information Managers will become systems architects and systems integrators working with infrastructure and platform as a service cloud deployment applications.
Any other BIM-based role titles will slip away and return to the native disciple the role serves. For instance, 4D modellers will just be called construction planners. BIM Engineers will be called engineers. BIM coordinators will be design coordinators.
A single source of each truth
Semantic Web technologies to connect data based on Unique Resource Identifiers (URIs), that can be mapped to asset naming conventions (where needed).
Data is never stored or duplicated in multiple locations, there is no more uploading to the file store. Instead, it is pulled at the point of use from its original source, or a caching server.
Each built element and digital process is defined by its information needs and outputs.
The project will be defined by its application ecosystem — a microservice, modular architecture — where digital construction processes can plug and play into a project via the Internet of Construction.
No more push or sending data. Data is published via an API documented in the Project’s data register and available for pull. The project’s data register will become the new CDE. The API register will show what data is available.
Reference to data can be outside the project boundary, pulling data from manufacturers, geospatial providers. In this sense, clients will not buy data, instead data providers will provide licenses to data on a project, programme or client basis.
You say “tomato”, I say “Fd_02_05_17”
Translation layer between the process and API. Using Simple Knowledge Organisation Scheme (SKOS) to map naming conventions and vocabularies. The buildingSmart Data Dictionary and other open vocabularies become the machine to machine language, where each each process uses the language of the user. Practitioners no longer need to learn a new language with each project.
Even documents become digitalised, with requirements and content that should be treated as data being marked up, individual requirements receiving referenceable URIs.
Project-specific vocabularies (covering aspects that are truly project-specific) can be published, but ultimately, URIs will resolve any facility, entity, space or system to the language used by the practitioner in their context.
Information Requirements and BIM Execution Plan
Each digital process is defined by its outcomes, inputs and outputs. The latter are expressed as Model View Definitions, which are based on open standards and published in open format.
The inputs for each task require data exchange with other digital construction processes, which accumulate to define the Information Delivery Requirements (or Information Delivery Manual) and Model View Definition (MVD) for each function. The complete Information Scheme for a project is emergent from the processes deployed. Where an information need is not already part of the digital construction process, it can simply be added to the API to be reused for future projects.
Over time the role of the CDE becomes a ledger of transactions and archive of records, rather than a source for information.
Proprietary interchange and formats
Whilst the Internet of Construction technologies exchange data using open standards; with the monopoly of the major vendors, a level of closed interchanges should be expected and tolerated.
The ubiquity of the major vendors will begin to erode as their model switches from full service solution to platform marketplaces where both the profitability and incentive to be open is greater.
Commercial incentive is essential, so black-box processes are to be as encouraged as long as they provide confidence for security and privacy.
Development of the Internet of Construction
The Internet of Construction will be built on open standards and therefore the role of standards bodies to develop, foster and disseminate best practice approaches cannot be understated. Existing open standards from bodies like buildingSmart International, Open Geospatial Consortium, World Wide Web Consortium (W3C), Internet Engineering Task Force (IETF) and OASIS will be fundamental. Like the World Wide Web, the development of the Internet of Construction will be decentralised and uncontrollable.
New open standards bodies will form and de facto standards will emerge from good practice and experience. Libraries that allow interaction at different levels of abstraction and to rapidly develop applications will be created. Visual programming tools will support practitioners to develop their own applications with little or no code and publish these online for their peers to leverage. Innovations will become viral, reaching all corners of the industry in rapid time and will little effort.
Development will need to be sponsored by business, investors and governments to create the momentum to kickstart the transition through a world-wide market development. Exemplar applications, case studies, conferences and infrastructures that are all needed. However an Internet of Construction alliance/consortium should not seek to assert any authority over the Internet of Construction, only stewardship.
Transition to the Internet of Construction
The objective for the Internet of Construction is to transform productivity of how built assets are delivered. It is not about raising the bar of an industry. Many businesses will get left behind. Many new businesses will form and flourish.
Ultimately, organisations will choose whether to be part of the Internet of Construction or not. We will see increasing bifurcation between the industrialised leading edge of the industry and the cottage-scale craft practitioners.
Initially, vendors will play in both BIM and Internet of Construction. With time, the file-based BIM approach will become legacy or archival functionality only. Specialist vendors will choose to support the BIM market for the domestic-scale, but behind the scenes much of the functionality will be driven by Internet of Construction technologies.
Rather than being driven from a centralised information management function, the Internet of Construction will see digital construction practitioners (who are primarily experts in their own discipline) using API-driven applications to optimise their own jobs. This mass optimisation will happen at a small scale millions of times over. Many digital construction processes will be released as open-source software or as Software as a Service solutions, with some practitioners switching from being construction professionals to specialist technology providers to scale specific applications globally.
There will not need to be any strategic implementation for the Internet of Construction. It will be based on open infrastructures, most of which are already available, and market trends, which are already in motion. The Internet of Construction will be entirely interoperable with standards for Digital Twins and in many ways their co-development will drive the adoption of each other.
Whilst many argue that current commercial structures are a barrier to BIM, the Internet of Construction will see no such problem. New commercial infrastructures will emerge that will sweep legacy supply chain configurations, procurement processes and forms of contract away. The pull to the Internet of Construction will simply be too strong for incumbents to prevent it; indeed their own processes will be optimised as a result and will interoperate with other enterprise systems in a way that BIM never imagined.
As the standards will be completely open, clients will be able to specify using the Internet of Construction with no barriers to trade, except suppliers’ unwillingness to modernise. Innovation will move at such an accelerated pace that clients will transition to specifying only performance and information requirements and will not be able to assert prescriptive ways of working over suppliers.
Existing service suppliers will find competitive advantage by clustering these applications into cohesive offerings and will find that increasingly they are winning work based on their creative calibre, rather than ability to deliver rote work by undertaken humans.
Manufacturers will see an acceleration of digital product catalogues, with product data hosted on their own servers and full visibility of where products are being specified. In-context advertising will fund the development and dissemination of Internet of Construction applications free at the point of use for practitioners, through marketing spend by manufacturers.
BIM has been a fantastic stepping stone on the route to digitalisation of the construction industry, but we need to reconceive collaboration and prioritise interoperability. By shifting the focus from information containers to digital construction processes, the Internet of Construction will provide the infrastructures for radically different project delivery models and the productivity promises of digital transformation.
Note: This is a first draft at a paper that I hope to develop and communicate more widely. I would appreciate any comments or feedback you have, please email me firstname.lastname@example.org.
If you would like to be involved with the development of the Internet of Construction, please also get in touch. I don’t currently have any formal plans to develop these ideas into something more concrete, but if these ideas gain traction then I would be very keen to explore the ideas further with others.
About the author: Tom Bartley is co-founder and CEO of Barbal, a platform for collaborating and maintaining technical documents and supports the development of Open Standards for construction and manufacturing. He has an Engineering Doctorate in BIM for Highway Project delivery. Tom is co-founder of dotBuiltEnvironment, has been involved with the development of the PAS 1192 standards since 2014 and is a member of the Institution of Civil Engineers’ Digital Transformation panel.