Categorized | Business

Debate: Should BIM Be Ingested Into IWMS

I recently ran across a wonderful post of Horatio McDowney on BIM and IWMS. McDowney’s post is a must-read for IWMS professionals. You will find his post below, however I would love to hear your opinion regarding ingestion of BIM into IWMS.

Therefore, today’s debate is:

Should BIM Be Ingested Into IWMS?

You can use the comment field below this article to submit your comments.


You can read the original post on:

Ice cream you scream, we all scream for ice scream. Do you like ice cream? You probably do in some flavor, but did you know that sweet easy to eat ice cream is hard for the body to digest? Why? Because, according to some, it is essentially all fat.

What does this have to do with BIM?

BIM is probably the “fattest” or richest spatial data modeling that has come about as yet. Since BIM objects can house perhaps 20 to 40 of attributes and properties each, not to mention the parametric relationships that are stored in the data model, in addition to the project or file information, drawings, sheets, cuts, schedules, and other database information — BIM, as a technology. . . well just a BIM file can be big. But you probably already know this.

BIM Integration

What is not as known is that IWMS vendors are creating systems that ingest BIM: Tririga touts their ability to do it, Archibus says that they have been doing it for years (no comment), FM:Systems has a Revit Overlay that will extricate certain types of data out of the BIM into their tool, Manhattan Centerstone (as of this writing) just mentioned that their next version would include the ability to ingest a BIM.

Yes, these vendors allow you to eat the ice cream, and soon we will all be screaming for this ability. But is there a down side to this sugary sweetness.

Let’s talk about Manhattan’s proposed abilities just a bit. The plan is for them to:

  1. Support Revit 2010 as the BIM platform of choice. A plug-in for Revit is in development that will be deployed with the next version of Manhattan Centerstone.
  2. The Plugin has an “import to Manhattan” button that will dismantle (export) the RVT file into the following:
    • Each individual floor will become a separate DWG that can import into Manhattan
    • A 3D DWF file representative of the BIM
    • A data file (of an undisclosed format or method) that will allow all of the assets, wall finishes, etc to be mapped to their correct location in the IWMS, templated (if necessary), and imported into the system
    • Updates to the BIM will be visible in Manhattan Centerstone after the import button is used.
    • The next version of Manhattan Centerstone will have both the Java Applet and a DWF viewer to enable viewing (and querying) the 3D building model. (For example: Searching for an asset will allow one to see that asset in the 3D model within the DWF.)

What’s wrong with this type of integration?

Well nothing. . . and everything.

Consider this: The BIM model from Revit is being ingested into a package that needs it to be processed before it can be used. What happens to the BIM while all of this processing is going on? For most users – nothing. For some users, everything.

Depending on how large your realty portfolio is, the size of your facilities, and the activity in those buildings, the BIM that is being ingested can literally be old news before it makes it into the system.

For instance, while I worked at the GSA many of the persons responsible for tenant accounts wondered why their tenants building rentable/usable factor changed frequently when the building was essentially the same footprint.

The reason: Rentable/Usable is not based on the footprint of the building – it is based on the relationship between the usable and common spaces inside of the building, which federal agencies change frequently.

What makes this particular issue worse is that just a decimal change in the usable area of a tenant will change the rentable/usable factor for all of the tenants in the building, using the BOMA system for measurement.

The point: ingested BIM will only give you a snapshot of the tenant area hence a snapshot of the bill. It can be orchestrated really well with good business practices, but it is not real time enough for me to say it’s really integration. More like import/export.


Another thing — the system is not simply importing the BIM it is getting a whole digestive process in line for a specific version of “BIM” in a specific format.

A problem?

Well think about it: What version of Revit will Manhattan’s tool support? What version is being released? Every release cycle will require a new release of the ingesting software. Soon a window of supported versions is created (ie. We support everything from 2010 to 20XX, nothing older than that.)

Does that present a problem?

Not for most of the population, but for the population that I am dealing with, I can almost guarantee it. This solution does not allow widespread BIM usage in facilities and maintenance management, just usage of a specific type of BIM — Revit.

Is Revit the best package for this?

Maybe from Manhattan’s business perspective, but what about the rest of the industry? (Not that Manhattan is responsible for the rest of us anyway.)


Can ingesting an IFC format file solve the problem?

Understand this: IFC is a flat file designed for transmission of some data. Trying to get a whole BIM with all of the data features mentioned above to transfer from one place to another is like attempting to send an air handler unit through a mailbox. (No offense to buildingSmart.)

IFC is to BIM what DXF was to DWG, it is a subset. (Don’t believe me? Take a complex BIM, save it to IFC and open it again in the same software package you saved it from. Notice any differences? This has been documented by radicals and the supporters.) IFC does not allow a BIM to be ingested or truly interoperable.

What is needed?

Unfortunately, the industry is not really ready to support BIM in a fluid and truly interoperable environment. Very interesting things have been done with (real) database BIMs, like Tekla and Onuma among the many.

BIM and IWMS Vendors

The Army Corps of Engineer’s COBie and COBie2 initiative have been instrumental in enabling BIM data to be used in a maintenance context. However, I’m afraid that what the IWMS vendors are doing seems to be the shortest route to usable BIM information on the facilities and maintenance end of matters. This primarily serves their own interests, and may hurt the industry more than it helps.


Because the industry needs better solutions to the interoperability problem, starting in the planning phase of the facility lifecycle.

The vendors are helping themselves (as we would expect them to.) People may begin to think that the interoperability problem is solved. It isn’t. The solution could be an interim BIM format. A simplified, database driven, queriable (with SQL or some simple language) BIM format that all of the players must comply with, stays in sync with the original model, and allows the user to have all of the complexity they need in the model.

The Onuma system comes close to this, and indeed allows one to access the BIM with web services to traditional applications.

BIM is just too much for us to ingest. As with ice-cream if you are going to ingest it, be careful. Some may have a compelling need to ingest it. But our expectations should be realistic for the long term. BIM may do better remaining in environments that it is intended to be managed and manipulated. We need an interoperability solution that allows that.


You can read the original post on:

15 Responses to “Debate: Should BIM Be Ingested Into IWMS”

  1. DeanStanberry says:

    In the earliest days of personal computing there was a saying that is still true today; “software (and data) will grow to consume all available space”. No one could imagine what they would do with a full 64Kb (yes, Kb) of memory. Well, we figured out what to do with it – and then some…

    While BIM creates large files, by our current definitions, and many object relationship (attributes), it is only a matter of time before hardware, storage, and software optimization resolve these limitations. Today, you may need systems that push the envelope of performance to take advantage of what BIM has to offer. Five years from now, these same systems will seem archaic.

    I agree that all of the listed “problems” must be overcome, but it’s nothing that hasn’t been done before. I would suggest taking advantage of what BIM has to offer today, as the information models and software tools will catch up soon enough.

  2. Steven Hanks says:


    I totally agree with you that all of the listed problems must be overcome, however these will be overcome by the rapid development of models and software tools.

    Yours Sincerely,


  3. Chris Keller says:

    When I presented the concept of BIM to a group of Architects, Facility Managers and A/E/C/FM consultants several years ago, I heard the same arguments and push back that I did when presenting CAD to Architects back in the 80’s and early 90’s. Hardware isn’t good enough, training is too expensive, who is going to pay for it, how can we make a profit from it, the client isn’t demanding it, etc.

    In a few years, BIM will be standard practice as BIM will follow the same adoption path as CAD. But full adoption will be more difficult than it was for CAD. The benefit from CAD was optimized primarily from within the firm (A/E/C) with its approach in adopting the technology and new processes. The benefit from BIM has more to do with collaborative efforts between the entire team (A/E/C/FM/Owner). Data, standards, processes, technology have to be interoperable between all team members to realize optimal value. Oh yea, and don’t forget the lawyers. The contracts between all team members will have to change as well.

  4. While BIM does create large complex files, it is possible to use only specific data as required for a given application. For instance, you could ingest the building schema and just parse the data needed for your application. The data connection to the model allows changes to be propagated to other systems within the model. The key is to maintain the model as the system of record for all data, then allow other applications to leverage that data. Moves, adds and changes are entered in the BIM system, then the updates are pushed to the other applications. With our system, we can use the building schema to build our database tables for the physical infrastructure, then we use our integration modules to collect and relate disparate systems data to the model. The end goal is to take the BIM equipment models and tie them to live data through integration with the systems that control them. Buildings are fast becoming large data stores and you’ll need computer systems to associate the data across multiple systems in order to truly understand the buildings performance.

    • @Mr. Keller – I agree and face the same push back even today. I think that some believe that this article was an argument against the adoption of BIM when it is actually highlighting where we are with interoperability today, with IWMS and BIM. The industry is still developing the standards necessary for real interoperability and we could possibly develop new tools for such in the long run. The question is, Are IWMS vendors supporting the development of standards for BIM interoperability or are they developing (or allowing the user to develop) their own version of them?

      @Mr. Greenwell – This is a very interesting post. IWMS systems seem to typically facilitate data usage through several business lines: HR, IT, Security, Realty, etc. Just to be clear: It seems as though you storing the BIM in a database server (i.e. Oracle or SQL Server) and then integrating the data from a database level, which is certainly a viable way to use the BIM data (one that I have endorsed as well).But, due to my history in the CAFM/IWMS market, in looking for a long term solution, I felt the question had to be raised as to how IWMS is contributing to the goal of BIM integration.

      • Steven Hanks says:


        what do you think of the commment of Dianne Davis below?


        • I agree with Diane 100%. It seems as though she is making the same point from a few different perspectives. In harmony with what was stated, I think that it will become more important in the future to support standards that allow integration easily from different technological standpoints. The vendors that can simplify integration (as in making it easier) of the data we need when we need it will shine above the others.

  5. John Bates says:

    Steven – thanks for posting a link to this article.

    My background is in FM using CAD/CAFM mainly for space management……I’m interested in finding out more about BIM, since I’m sure it will have a growing impact on FM in the coming years. So the posts above – have been very useful.

    I recently attended an excellent seminar on BIM in the UK. The presentation slides are available on @

    To put the event into context: it was sponsored by several UK organisations representing architects, engineers and contractors. Most of the focus was on BIM during design and construction, whilst the benefits to FM was only briefly touched on, possibly because of where BIM is at, with regards to its development.

    • Steven Hanks says:

      Hi John,

      thank you so much for posting the presentation slides. I know for sure that this information is very relevant for many of our readers! Keep up the good work and thanks for your participation.

      Yours Sincerely,

      Steven Hanks

    • John,

      I think the issue there is that it was put on by architects, engineers and contractors. They aren’t really in the position to think past more than their current project.
      I’ve been working in FM for 13 years now, and have had to be very vocal to get acknowledgement of real world use of even CAD data post-construction, let alone BIM. So long as FM people aren’t speaking up, you’ll have marketing people saying Navisworks can be used as an FM tool, and have other people believing it (I’m not saying it will never work, but, I’m saying it won’t work often).

      I’ve had architects suggest they could manage our models on an ongoing basis, and I feel cruel pointing out that 90% of the architects who’ve worked on my hospital are either out of business or deceased. We can’t leave something as important as our operational archives to the hands of an outside firm who can’t possibly possess the same long-term vision as someone actually operating a facility. Now, I say that as a 100 year old medical facility, it would be a different story working on a shorter-term and less complex campus like a block of office buildings or something.

      Of course, the most important thing is information exchange. Between the different players who touch models at various times in the lifecycle and between the different software packages. It’s all part and parcel.

      Great topic, great discussion… the more, the better! I’m completely on board with what Dianne said. There are a lot of players that need to be brought to the table, and they all use different tools.

  6. Dianne Davis, CSI says:

    It isn’t that IWMS should consume the whole BIM, rather let’s look at data’s authoratative sources and access the data from that source to support a specific use case that is dash-boarded in IWMS.

    Building Lifecycle Management is a team sport from a data and technology viewpoint. But what the plays are and who holds the ball vs. who kicks it are the use cases in building lifecycle management that we work on.

    IWMS does not have the technological capability to ingest BIM, but it can suck-out what is necessary. However, IWMS will have to become 3D supporting- and no more drawing overlays to create intelligence or linkage. You need to pull in the existing intelligence out of the discipline systems.

    Finally, add the other team members to the mix. We are currently working with the USCG. The mix is BIM/GIS/CAFM/CMMS/IWMS.
    IWMS has a wonderful opportunity to support data views for decision support, but only if it is willing to play its role and not try to rule the universe.

    Interoperability of data will be a mix of IFC-xml, , web-services, SQL, OmniClass for semantic interoperability, etc. The use cases will define the responsibilities, formats, views, data-sets and outcomes.

    • Steven Hanks says:


      Thank you for your interesting comment. I do agree with you that IWMS shouldn’t consume the whole BIM, but will predominantly focus on retrieving necessary information from BIM. What I do believe is that we will witness significant BIM developments in IWMS product offerings over the next couple of years.

      Yours Sincerely,

      Steven Hanks

  7. Massi Coe says:

    There are some very insightful posts on this topic, and I’ve enjoyed reading them all. Everyone makes great points here, and the thing to remember is that BIM is still fairly in its infancy. We’ve seen much quicker adoption of this from the early adopters simply because of what people expect from technology these days, that is will solve all problems. However it doesn’t right off the bat (if ever) and I’ve already seen a great deal of progress in the collaboration between vendors on this subject.
    As for the IWMS solutions out there, they are trying to utilize the information that is being created with BIM so that the users/owners we deal with don’t have to recreate this data, and can use it to help operate their business, even if in the slightest of ways. Even if they are able to extract a small portion of it, having some of the data is better than sitting on their hands, saying they don’t have a solution, and offering no value. It is still evolving and conversations like these will do a great deal to drive the progress in the right direction forward.

    • @Mr. Coe and @Ms. Perry, I’m shocked this article is still getting attention after so long. Ms. Perry I really appreciate your perspective with a very old facility and architect’s promises, classic :-)

      @Mr. Coe I really appreciate your balanced perspective, and I agree, the IWMS vendors would want to serve their customers best by giving them something that can be used under their current technological and business requirements. Just to add a bit more to my perspective on the issue, being an IWMS integrator since the late 90’s and working with folks who have several changes in buildings over the course of time, I would feel it a bit misleading not to provide a bit of guidance to my clients as to the value that they are really getting from BIM ingestion — especially if they do not have business workflows that allow this to be continuous. As a one-off solution, once a building is built or remodeled the IWMS solutions would almost be ideal. However if you add the words ‘continuous integration’ to the mix or ‘always up-to-date’ then I think we need to be able to set expectations. This problem becomes increasingly more complex with a large building inventory. Additionally, over the years, I have come to be more and more of the opinion that there are very few BIM software vendors that are really playing nice with those attempting to address the interoperability conundrum — and I don’t think that the industry is doing much to hold them their stated or implied commitments. Back to your point, IWMS vendors are simply doing what they have been doing for years with their customers in the BIM arena, with greater or lesser degrees of success.

      All the best,