It is easy to understand the attraction of re-branding 3D AEC CAD as Building Modelling (BM, or some similar acronym). The simplicity of the concept - a master, intelligent 3D model, resulting in the as-built database, ready to hand-over to the building operator on commissioning - makes it a convincing vision to sell. Similar moves by mechanical CAD vendors to progress users from 2D design to 3D solid modelling and PLM (Product Lifecycle Management) have accelerated sales of solid modelling systems over the last few years, so why not in AEC?

3D design has been around for at least 30 years and there have been pioneers in AEC championing the technology from the beginning - GDS, Sonata, Reflex, to name a few. Unfortunately, they were "ahead of their time" and, like many missionaries, did not last long outside their own environment. Companies like Graphisoft, Bentley (with Brics/TriForma), Nemetschek and Revit (now Autodesk), have since taken up the baton.

The technology has moved forward, but has the industry's ability to absorb these advances changed? Not from the evidence of our participation in various industry panels over the past few years. A recent AIA conference reported a staggering $100bn as the estimated cost of fixing and administering construction errors, whilst $24bn is spent on design itself. Clearly, if BM offers a solution to reduce error and rework, now would be the right time to buy.

Custom & practice accepts error

Perhaps, in their eagerness to bring their BIM vision to market, vendors continue to underestimate the differences between their logical model and the realities of AEC industry practice. Experience of mechanical design is not a good guide - for example, whilst mechanical products may be digitally modelled, prototyped and refined prior to production, buildings and plant are effectively prototyped as they are constructed. Also consider the ordered flow in discrete engineering and compare that with the typical chaotic construction site. There is plenty of scope for on-site errors to occur, even when the plans are 100% correct.

Skilled practitioners on the ground may minimise the confusion and query the detail of their tasks, but once a hole is dug, steel fixed, or concrete poured, it can't easily be erased and re-done six feet to the west. Yet buildings are completed, sometimes on time, sometimes within budget.
It is perhaps worth having a closer look at the industry ecosystem that not only copes with errors, but also finds solutions for unspecified aspects of construction.

Does the BM vision fit?

Current practice brings together large consortia to bid for AEC projects, often linking many different sub-contractors, each with different skills and responsibilities for different parts of the construction process. Each organization in this complex network will have an interface with at least one other organization in the network. Each interface must successfully transform technical information, such as design, specification, standards, project plan, and location, as well as commercial information, into contracts between the parties concerned. The ecosystem works because, at each interface, people who understand the business, perform the negotiations to balance the 3Rs - Risk, Responsibility, and Reward.

To succeed in these negotiations, management teams need to fully understand the value they add and the risks they will encounter before they can take responsibility for the added value and negotiate a fair reward for their efforts. For people and organisations to do this, they must have control of the data model that defines their added value. If the vision for an integrated BM does not take this issue into account, then there is always going to be resistance to its uptake.

This is not to argue against the value of a BM in supporting easy communication between the multiple disciplines involved, either by data communication or data sharing. Of course these capabilities save costs and reduce errors. But this is not enough - it is also necessary to give each player in the ecosystem enough control to allow them to manage their interfaces with other players effectively. Where companies are unsure of the completeness or quality of the data at these interfaces, they will continue to factor-in costs during their risk assessment. If the BM is not integrated with the business systems that support negotiation related to the 3 R's, then the BM will continue to be disconnected from the core strength of the industry ecosystem.

This line of thinking supports the concept of "federated" data models, in which independent sub-parts of the BM are somehow "federated" together to form the complete BM. Current practice begins to deliver this federated capability using data exchange coupled with automated or manual workflow procedures. This approach enables changes to be propagated, and allows for basic business system integration.

It is perhaps natural that a federated data model best suits a federated industry. When the interfaces in the model match the interfaces between the organizations, then each player will be able to optimize the three R's - Responsibility, Risk and Reward - that drive their business.

Development Directions

What are the implications for information technology development?
The vision of an integrated BM is unaffected - but the absolute requirement for local control, and business system integration, are examples of the scale of the challenge. For organisations that feel it may be some time before this challenge is overcome, interim solutions are required.

These interim solutions probably involve partnerships. Imagine the case where there are two vendors, each with a product that is dominant in two connected parts of the industry ecosystem. Perhaps just a little more co-operation between the vendors involved could deliver a local example of how a federated BM would function. Last year's announcement of an alliance between Aveva and Autodesk may be a taste of just what is needed.

Alternatively, or additionally, there is a role for industry-wide technologies. For example, in GIS, the industry has set-up the Open GIS Consortium (OGS), which includes all of the major GIS players, to promote use of GIS technology. Currently the OGS is proving how different systems can be used within a single GIS, using their OpenGIS Specifications to ensure data compatibility. Its most recent activity was to present such a project to the UN in January 2004.

In AEC, the International Alliance for Interoperability (IAI) promotes standard object-classes (IFC's, Industry Foundation Classes), but these are not yet in common use, and developers often have to add their own "classes" to the IFC base when these are required by their specific application. Unless these additions drive updates to the IFC base, this seems counter-intuitive to the idea of IFC's in the first place.

Business Strategy

From a vendor's point of view, co-operation must appear a risky strategy. "Surely we should get out there and compete, and expand the scope of our product's use".

Perhaps.

But an alternative strategy is to master a more complete view of how the interfaces between organizations work, and then learn how to manage not only technical data exchange and update propagation, but also the business aspects of the 3 Rs. For example, with a real BM it should be possible not only to optimise material usage over the whole project but also to enable each organization that handles the materials to manage the 3 Rs - Responsibility, Risk and Reward - for each transaction related to these materials.

Could a team of vendors learn how to do this? By bringing together fluency in data exchange, version management, and industry understanding, it should be possible. The result would be a BM that everyone will want to use.

Peter Thorne and Nick Ballard

peter.thorne@cambashi.com nick.ballard@cambashi.com

A version of this article was first published in the March 2004 issue of AEC Automation.

Other Cambashi articles that may be of interest:

Who will pay for the Building Information model?
Is PLM applicable to AEC?
A-E-C Systems 2002 review

back to top