Parkinson's Law, BIM and blobs

"Work expands so as to fill the time available for its completion."

In order for BIM to deliver the much advertised revolution in efficiency we need to overcome this fact. As Radio 4 reminded me a few weeks ago, Cyril Northcote Parkinson stated his 'Law' as part of a humorous essay for the Economist in 1955. However, it struck a chord and still holds true for many aspects of life today.

Parkinson referred to contemporary British bureaucratic examples. As the Empire shrank the Colonial Office expanded, reaching its zenith when it was morphed into Foreign Office due to lack of colonies to run. After the First World War the British fleet shrank dramatically, yet the number of Admirals rose in similar dramatic style.

Admirals v ships

Unfortunately this rule continues to be applicable in many other fields - for instance sustainability. In the 70s we all started showering, saving all those baths full of water. However we 'improved' the shower into the power shower and moved to daily washing (or more for teenage daughters!) so as widely reported in 2011 we have now clawed back all the gains we thought we'd made and more! Similarly, modern cars are much more fuel efficient than in previous years, yet whilst I was living abroad I saw on my visits the size of the average UK car grow incrementally, with many more 4x4s and people movers now shuttling said teenage daughters around (not my one this time).

And now we have all these wonderful labour saving devices to replace the drawing board. I worked on the Broadgate at Stockley Park projects back in 1986, two of the first to implement 2D CAD for buildings in the UK. Somehow we all felt we should be being more accurate and some users would proudly show how how they had drawn all the threads on the bolts when they zoomed in - followed by complaints about how often their GDS terminal crashed.

And the poster child for 3D CAD was Frank Ghery, and in particular his Guggenheim in Bilbao. Amazing things can be done with new technology and a high performance team, but a generation of contractors and clients have since had to deal with cost overruns and leaks resulting from less talented 'blob architecture' on his coat-tails - and a generation of cynics about this new-fangled BIM thing were born.

Bilbao roofs

To avoid the BIM revolution failing due to Parkinson's Law we need to keep our eye on the ball, and make sure we don't get lost in the expanding possibilities of the technology. Be clear what we are delivering now, and use BIM to deliver it better. Too often our industry's deliverables been ill-defined, leading to disappointment and rework. My holiday reading at the moment is the RIBA Plan of Work - I need to be precise about what the old version was, and what the 2013 vintage now requires. My attempt to define 'the way our drawings should look' is another attempt to prevent the many possibilities of BIM undermining the actual delivery of its efficiencies. Define what you want to do before moving forwards.

The vast majority of the world's buildings are boring, conventional and delivered by low performance teams*. If we can define and deliver what BIM means for these projects we will answer the questions now being asked of our industry by governments around the world, and realise the cost and energy savings we all need. 

The future is not blob shaped. Mostly it is rectangular and low rise. And hopefully über-efficient.

(* - a low performance team is any team you consider is worse than your own.)

IFC and World Peace - or not

"There are two types of people. Those who think that IFC does nothing and those who think it solves world peace."

So said Angel Velez, Senior Principal Engineer at Autodesk. Since I have increasingly found myself using 'IFC' as a magic word to solve all data sharing issues - without actually knowing what is behind the acronym - Autodesk's recent strategic briefing on "Revit Interoperability via IFC" (Industry Foundation Classes) was a good chance for me to get somewhere up a learning curve and convince myself I knew something.

Angel has for the past 8 years been responsible for interoperability on the Revit Platform, and he saw this session as a chance to communicate what has been done to date and where Autodesk saw IFC going. He gave an outline of IFC in Revit today, followed by a look at the current capabilities of the export/import and open-source functionality. He then led a workshop-style discussion on the strategic direction for IFC in Revit, talking specifically about Autodesk's roadmap for future development, using the session to get feedback from the UK's user community.

To paraphrase Wikipedia, “The IFC data model describes building and construction industry data to facilitate interoperability in the architecture, engineering and construction (AEC) industry.” It is a neutral and open specification that is not controlled by a single vendor or group of vendors, but instead run by BuildingSMART - a pan-industry alliance. Clearly it is already one of the key ways that data can be exchanged between BIM platforms and our confidence in how well this exchange works is central to successful future collaboration.

It is worth noting that everyone at the session agreed that assumed intent behind IFC was that imported data will be used as a reference only, not for editing. Mostly the format is used as a basis for coordination and this will become increasingly important as the amount of data being passed between parties and platforms increases.

Autodesk's roadmap for implementing IFC

At the moment many people gripe about IFC export and input being unreliable and slow, resulting in missing information and difficult 'round tripping'. Code has got out of date as development effort has focused on other aspects of Revit – or at least that has been perceived by some outside Autodesk. At the moment its import code basically dates from 2005, but the intention is not to fix this code, but instead to rewrite to give a new foundation, hand in hand with open source code. There is an increased emphasis on IFC's importance despite being an old file format, especially since the UK and Scandinavia are committed to future use of IFC and Autodesk will be adopting IFC4 when it comes out.

One interesting aside was Angel's vision of IFC as a future way to achieve backwards compatibility! Revit cannot save backwards to earlier versions but you could go via IFC. However it is not great at the moment. Angel would like this to be improved as he knows this is potentially the only way to go for people with that need.

Export and import code will be developed separately and the quality of IFC in Revit will be "improving in stages from 2013 to 2016' with export leading."

Certification by BuildingSMART

There was a very interesting conversation around how you certify the performance of the import and export functions. I hadn't thought about this before and it turns out defining how to do this is quite tricky! Import and export each have their own certification process and for Revit export this is being completed before import as it is better defined and easier to achieve.

Before certification Autodesk works closely with the other companies involved with BuildingSMART to establish precisely defined test cases. A large amount of automated testing is then followed by manual testing. Certification is partly against a basic standard and partly against interoperability with other platforms, but this last aspect can't guarantee transfer into every program out there.

BuildingSMART is actively learning current lessons so that the certification process can be refined for IFC4. To use Angel’s fantastic phrase, it ‘used to be a bit hand wavy' and import may continue to be. Testing and certification occurs during one intense face to face session by BuildingSMART members taking several days, sandwiched between two web conferences.

IFC export is now certified for architecture and structure in Revit 2013 and MEP is about to be. Once that is done the plan is to work towards certifying import in Revit 2014, with the intention of doing a minimum amount to get certifications. The plan is then to completely rewrite IFC import for Revit 2015.

Given that even with the best will in the world there remain a degree of vagueness in the certification process, I now start to understand the requests for ‘native file formats’ from high assurance sectors such as the nuclear industry. If we need to be completely confident that all data transfer is complete, correct and safe how can we define successful performance between various platforms? I anticipate that certification will satisfy most of the construction industry but some corners will remain hard to persuade.  

Open source code

Another developing aspect of IFC that I was unaware of was open source code. As more of us start adding bespoke properties, property sets and data to our models that are peculiar to our businesses, projects or markets, how can we pass them over to the next program in the chain? Do you need to tweak your IFC output for improved interoperability with other ‘non-certified’ systems? The way to achieve this customer flexibility is to write your own import and export code.

IFC export has been open sourced from Revit 2012 and the plan is to do the same for import from Revit 2015. In support of this the IFC model specification is open and available and IFC is an official International Standard ISO 16739:2013.

The best place to get the open source code is from SourceForge which always has the most up to date version and also a discussion group which Angel leads. It is also posted on the Revit Exchange App Store. The Store gives you a reminder when a new release comes out, but there is perhaps a 1 to 2 week lag in posting behind SourceForge.  The code has now been downloaded 15,000 times, but interesting that no one at this briefing had done so. Angel thinks this is evidently an underused aspect of IFC.

Updates of the source code are decoupled from Revit’s release cycle, and code can be revised after certification if issues need fixing without triggering recertification. BuildingSMART allow Autodesk are allowed to do anything with the code so long as it is ‘reasonable’ – which in a normal world is ‘reasonable’ but, as mentioned above, would make a high assurance industry freak!

Final thoughts

Thanks to Angel and Autodesk for this session. I hadn’t had a chance to previously think hard about what lay behind these buttons. IFC is clearly a key exchange format in the years to come, and for our major projects users need to do more than just press and hope. As we know, data transfer needs to be planned, checked and understood within our overall BIM processes. This session helped me on that journey.