I agree; Lifecycle costs are an important part of both IFC and LEED.
LEED analysis affects all phases of work from pre-design through to Lifecycle.

I was watching a VICO webinar recently showing several case-studies of contractors who use Navisworks and the effect it has on construction costs. Use of clash analysis softwares such as Solibri (IFC) and Navisworks (3D DWG) should and perhaps are worth LEED points.

The results I saw were consistant with the savings, both time and money, achieved by Hensel Phelphs on a local high school project.

Contractors have been having VICO build 3D models for the building or consultant portions of the job when they are not provided with them. They are requiring their subs to use 3D software.

There are SO many potential BIM applications (and Adesk can't own all of them), that IFC is a necessity. BIM for owners and facility managers, for architects and engineers, for contractors, subcontractors and fabricators. To abandon IFC would be to abandon the concept of BIM.

for anyone who is interested this is a website of the company in Norway which runs IFC server:
http://www.epmtech.jotne.com/built-environment.79297.en.html

I have attended their seminar 3 years ago!!! the major features:

1. server based entirely on IFC so any software supporting IFC in/out can tap to the central database.
2. administration of data is purely in a domain of the server provider so coherency and clarity of IFC data is protected from any attempts of contributor's 'tweaking' in regards to standardised protocol.
3. also liability for security and data access privileges are with the server provider rather than any design-involved party (which could impose undesirable overheads).
4. accessible via the internet - the advantages are apparent

I agree that IFC is essential. In a (more) perfect world IFCs would be capable enough that all BIM applications would use it as their native format. That in turn would unlock the potential of BIM servers, Software-as-Service offerings, Cloud-BIM and all manner of specialized analysis tools that could really help with energy modeling, collaboration, and sustainable design.

All of these things are technically feasible today. The problem is there is insufficient incentive to develop IFC to the degree required. To say A’desk is trying to kill IFC is a bit cloak and dagger. They are far bigger than Graphisoft, but like Graphisoft their products have unfulfilled wishlists thousands of items long. Why would they, or any developer, invest heavily in IFC it there is little demand. Most BIM is happening in the confines of isolated teams. Collaboration workflows sound nice, but they need curtain wall tools now.

And therein lies the rub. Crappy results=no demand. No demand=stalled development=crappy results.

The ice breaker is governments. If all the public sector projects that flow from the massive stimulus plans required real, working IFC models, and were held to high, verifiable standards then all the AEC firms doing all the grunt work would demand action form Graphisoft, Bentley, A’desk, and all the rest, as well from the consortium itself, to move this thing forward.

Geoff wrote:
The problem is there is insufficient incentive to develop IFC to the degree required.

What's sad (scary?) is that the IFC effort is being undertaken with minimal funding and much volunteer effort. The level of support is not equal to its level of importance.

A fundamental problem: IFC will not reflect the potential of the software. So you have fancy features in Revit and other fancy features in ArchiCAD, but you would not be able to use them, as IFC does not support them.

If you export IFC from App X, many X-specific data is stored as custom properties. X could (in theory, as it's not bullet-proof) restore these properties when importing the IFC.

However, there is no guarantee that App Y, with different properties, filters the App X properties out. It will most certainly ignore them at import time and the question is will they be retained at export time?

So only when you can roundtrip an App X model into App Y and back into App X through IFC, without loss of your functionality, will people start using IFC on a server level.

You have probably seen the less-than-stellar IFC-compatible library objects from ArchiCAD, which can only do a fraction of the native IFC library objects.

So only when you can roundtrip an App X model into App Y and back into App X through IFC, without loss of your functionality, will people start using IFC on a server level.

No this is not a necessary step. I am talking about 3rd party server service which will administer the data on the server. That means the server provider will coordinate and administer a set of 'rules' within IFC communication.

At the moment (after my experience) any coordination of such data inevitably lands on a desk of architects (being a project coordinator). This experience makes all BIM collaboration really painful as we have to look after several models at the same time and secondly when we are importing any consultant’s model we are getting lots of 'rubbish' with it too. That should be 'filtered' by the IFC server coordinator or whatever we will call them.