All too often I hear that BIM is ‘just a tool’ – typically a thinly constructed attempt to supress BIM below more traditional workflows. Most experts agree that BIM is in fact better described as a process, one of which has significant benefits at all stages of the design and construction process itself.
In order to function effectively as a process, there are many aspects of BIM to be utilised. This article deals with the first aspect, and future articles will discuss more – with the goal in each case being to suggest solutions or steps we are taking towards them.
“B i M-wash”
Nestled in between the B and the M in BIM is a poor little i. That i stands for information!
As I wrote that sentence, even the auto-correct function on my computer knows to correct this i into a nice big capital letter – so why do we so often get this so wrong in architecture?
A BIM model with no information is just that, a model.
When the project is over, the model is archived and left on a server – never to be opened again most likely (it sounds so sad!). What really sticks in today’s digital world is information – or ‘data’ in an unprocessed sense. We can learn so much from the data we collect, and also find real time ideas and insights from utilising it effectively – so it needs to be good!
If we spend just a little bit more time focusing on that little letter in the middle, our BIM models could do so much more for us. This article will discuss good data practices as well as some methods and benefits of implementation.
Success = Data.Management()
A coder recently told me that ‘good’ data has to be workable – it needs to have structure, as from this we can find patterns, form predictions and run processes. If a cat tells us it is a dog, from a data perspective it may as well start barking.Such traits of workably structured data include:
– Shared prefixes and identification systems
– Common classes and file types (e.g. use of numbers vs. text)
– Consistent delimiters and separators
– Predictable character positioning
– Flexibility and ability to grow/adapt to challenges
– Single or unified points of control (e.g. software parameter files)
The list goes on… so much to consider! Where to begin in building our own system?What ultimately matters is strategy – a ‘good’ Data system is planned ahead with enough rigour that it can fulfil its requirements. Companies must respect the need for upfront investments before putting a data management strategy in motion.
Architects are notoriously inventive – thinking outside the box in ways which anyone else would simply propose a copied and pasted solution. Architects are also notoriously re-inventive – look up Einstein’s definition of insanity and you’ll get the idea.
Data is often extremely explicit; 1=1 and 0=0 – don’t even start me on 2!
Just as different data systems don’t play well together, the same can be said for BIM models and content derived from within them. Forcing two BIM models into a common data environment with no consideration made to their data structure is like skating on hot water – it simply doesn’t work.
Companies should pursue reinvention only where absolutely necessary; otherwise information no longer serves a purpose in their workflows as there is so much of it, yet so little to be done with it. Systems should be pursued on the basis of legacy – improve vs. discard.
The truth is already out there
As mentioned before, one common hurdle to establishing a good data structure is that there are so many ideas and systems – but which one is fit for your purposes? Some commonly accessible formats worth considering when structuring BIM data are;
– NBS (UK)
– MasterFormat (US)
– NATSPEC (Australia)
Some cover more areas than others (elements, assets, specifications, naming, numbering etc.), but most are typically sufficient to establish a general framework. Whichever format(s) are chosen, a worthwhile goal is to be able to move this data into an open BIM file format such as IFC.
Companies should discuss and agree on uniform data structures with their design and construction teams prior to delving too far into a BIM modelling process – I don’t see or hear of this occurring often enough.
We should also keep lessons from PAS1192 in mind (and now ISO19650-1 and 2) which require us to draw specific data requirements out of our clients before we proceed with our designs – ideally embedding these into our contracts or BIM Management plans.
Data doesn’t grow on tree$
I’ll be candidly honest – setting up a company BIM data format takes a very long time. It requires patience, discipline and upfront investment (time = money!).
This expenditure returns itself to the company in more ways than can be listed or measured, but some typical benefits to expect are:
– The ability to streamline workflows driven by data
– Consolidation of libraries and templates
– Easily identified audit targets
– Software interoperability
– Improved coordination quality with other companies
– Less frustrated users
– Ability to join data across projects (databases etc.)
As software continues to develop in the subsets of AI such as machine learning, there is no doubt that these data driven workflows will also contribute further payoffs to the custodians of well-structured data.
All that remains
As history shows us, everything we do will one day retire into legacy. Our bodies and minds fade away, but what we produce can leave a resounding imprint on its respective discourse.
BIM models are of a similar nature; eventually the model is modelled, the building is built and all that is left to continue on is a lonely little i, information to be learnt from and drawn upon.
But remember; it’s not an i, it’s an I.