COBie is dead!!!

The moment COBie started having little “COBie’s”; it started to commit suicide. We all know an animal must reach a certain maturity before it can successfully reproduce. So why a BIM standard shouldn’t be expected to reach maturity also is beyond me. Yet people will argue COBie has been around for years it should be mature by now. I can quickly answer back, so has my teenager, yet I’ll take this opportunity to speak to why I feel, and many in the industry, that COBie is broken. Don’t get me wrong COBie isn’t all wrong it has a sound foundation. However, while the foundation is solid it is built on wet sand and seems to slide about a bit creating cracks. In the Whole Building Design Guide it talks about how a building is designed, costed, and constructed in terms of UniFormat and MasterFormat as the two most widely used classification systems available and in use. COBie wants you to use OmniClass; I know some of you are asking what COBie is first; then OmniClass who uses that? Now to throw another grenade out there COBie is only referenced in the Operations & Maintenance section of the guide, and get this: it isn’t even listed as a tool. Now a quick bulleted list of problems as I see them:

  1. COBie is a spreadsheet
  2. COBie uses OmniClass Table 23 “The current edition of "Table 23 - Products" covers almost 7000 products used in the construction and operation of buildings.”
  3. Organizations are demanding COBie but few actually know what they want from it.
  4. COBie has been developed in a silo
  5. COBie does not work with software firms to better integrate with their systems

Now let us take each of these bullets on one by one, granted in the Marine’s I was taught “One Shot, One Kill”, but I’ll play nice in the sandbox here.

COBie at the end of the day is a spreadsheet, words spoken from COBie’s father. Then why do so many think you can’t have BIM without COBie; or that you need BIM for COBie? Why in this day and age with intricate web interfaces and practically every firm using Microsoft Office do we rely on spreadsheets to handle data that should reside in a database? Pretty soon the new COBie will require us to have paper based ledgers to keep track of the model elements.  I should mention in here that COBie is actually an xml based information exchange but has been formatted as a spreadsheet for the general use of the AECO industry.  While it is a nice attempt at integration it unfortunately is letting people use the wrong tool for the job which actually makes it much harder to be successful.  Kind of like using a wrench to hammer a nail; you might get it to work but wouldn't a hammer make more sense?

Okay now to the OmniClass conundrum. First I'll say that I work in a Revit shop, I still haven't found the elusive Open BIM Authoring platform, and that is where my comments to this come from. Why do we need OmniClass table 23 in the design and construct phase? When designing in Revit a wall is an assembly made up of individual parts and components not a whole bunch of parts and components disassociated from it. In the O&M phase of a project will an owner possibly want to know the drywall and studs manufacture; maybe but in this case not a realistic item. Maybe COBie should look at how a building is designed, constructed, and modeled.  We should be using table 21.  Let’s face it; most owners don't care if a screw was made by xyz corporation or yzk corporation as long as it functions correctly. For unitized items this is useful, but not for system/assembly items.

Increasingly, organizations are demanding COBie for their projects. The first problem is that unless they are using an out of box CAFM or CMMS system with no customization; they will spend months’ worth of man-hours just harvesting the data. I doubt anyone told them that. Then, you have the VA BIM Guide. They want COBie and will tell you how you will build every square inch of your model, but they will VE COBie out the first chance they get. I have also seen where COBie was provided and it went on the virtual shelf because the facilities team said it took too long to implement it. Also anytime a guide needs instructions for the instructions something has failed. Then if the first COBie wasn't hard enough to get your head wrapped around, we have COBie lite, SPie, BIMSie, and now BAMie what’s next?  If we're not careful, we're going to wake up to a great big WHAMie one of these days.

COBie was born in (and lives in) a silo. I have seen little if any industry input or challenges with the exception of it being VE’d out of a project. (Wait people challenge COBie all the time, in fact you are challenging it now.) Yes, but was it developed with an industry consensus like other groups have done, USACE/BIM Advisory Committee, VA BIM Advisory Committee, and Penn State? Granted in an ever evolving world, perfection is elusive, yet by including industry, software, and academic experts we can get closer.

So why is COBie foisted upon us all? Simple answer: It was the first carrot for owners to leverage BIM beyond visualization. Working in opposition to software providers, designers, and contractors who are actually putting work in place, and telling them this is what you have to do now is not a wise choice for adoption.

COBie puts on a challenge every year for software providers and developers to show how they can work with COBie. Problem is I have yet to hear software providers talking about how helpful the folks who brought you COBie are to work with. Instead I hear we have to change our software to work with COBie which is ever changing and evolving.  Where's the business proposition for the software providers?  They are being told they have to change on one side and being told that the thing they are changing to does not work on the other.  So do they change to something that is being pushed as what people will want or do they listen to the individuals using their product that say they don't want it?  So far it's really somewhere in between.

So is COBie really dead?  Not yet. But it needs to stop avoiding the issues of the industry if it does not want to be. Simple solutions can do wonders for COBie. We listed five problems so here are five possible answers:

  1. Create an open-source project database that users can link their models/data to that will properly communicate with owners CAFM/CMMS products.
  2. Construct the proper relationship in COBie between products and assemblies that use OmniClass Tables 21 and 23 accordingly.
  3. Spend more time educating the end users on what COBie is, how they can use it, how they can integrate it in their systems, and how they can require it. The industry does not get it yet. But the most important part here is altering it to fit the way the industry actually practices their work.
  4. Have consensus groups involved in the answer to #3.
  5. Give the software companies a business proposition. This part is actually getting closer but is part of a much larger problem. The war between open-BIM and software companies needs to be stopped. They are two sides that need each other to exist and move forward. But that is a post for another day.

14 Comments

  1. If we strip away BIM and COBie from this discussion and focus on the kind of information that one would assume to be a "best practice" regardless of the technology used, it would be reasonable to expect even in a hand drawn set of documents from the1980s:

    1. That rooms are uniquely named and numbered
    2. That schedules of doors and equipment are uniquely numbered and associated with rooms
    3. That attributes about rooms and equipment can be found and associated with the room and equipment. For example what is the floor finish of room 101 and where is AHU-2 and what are the characteristics of it.

    These are best practices that pre-date BIM or even CAD and are also the fundamental requirements of COBie.

    The discussion of what COBie is or is not and should it be a spreadsheet or a database is interesting but not relevant to the basic questions of the three elements above. If 1,2 or 3 are not true, you do not have COBie. It is very black and white and that is why it is great. There is no wiggle room and it focuses on the "i" of BIM.

    Once you have the above in place then other elements of COBie such as associations between the attributes of equipment and the equipment itself, the relationship between an instance of a piece of equipment and the type it is associated with, etc. etc.

    The basic rules of COBie are simple but interestingly enough a majority of BIMs do not usually meet those. There are examples out there that do, but the main test of does it pass 1,2 and 3 usually results in errors. These errors are easy to fix and should be as long as they are caught.

    The brilliance of COBie driven by Bill East and other stakeholders, is that it lets us focus first on these fundamental elements and then one can continue to get more and more detail layered in. The question of what type of detail and what is contracted to be put into BIM or COBie is a separate discussion as well. On the other hand an owner should expect to get the basic placement of spaces and equipment in order regardless of BIM or COBie, and now with BIM and COBie it should be easier to make it happen and go way beyond the status quo to deliver quality data throughout the project lifecycle.

    Owners also need to define what they need to manage throughout the lifecycle and make that part of the deliverable. This is needed for COBie but also existed before BIM or COBie. The standards let us create a place to park these requirements and check them. Software then takes the open standard and builds interfaces that makes all the complexity go away and the open standard becomes the common thread that allows this to happen.

    Great discussion here. John thanks for starting it.

  2. I will give one example, just for the sake of examples. Take 'grids'.

    I don't know why in the world anyone would ever want to internalize a grid into a central database. The first thing that should be floated out into the atmosphere never come back again, are grids. When you do that, you can assign whole teams to manage and monitor the grid – and what its interaction between itself and everything else. That is, if one wants or needs to assign responsibilities down to that level of granularity one can.

    Where I am coming from in all of this, is the hand over to the Owner, and the production of this COBie file I am always hearing about. One thing that one of the software engineers said was interesting. If COBie can work efficiently, then the Owner is not just a guy standing at the finishing line, but they can be brought right back into the actual process itself and work with the Commissioning team for the project, providing input. That is what 'objects' are wonderful at doing. Accepting input, doing something, and producing some output, which is useful to some one else.

    But I find it amusing to listen to those 'explorers' who have been on expeditions into the massive jungle of BIM, in search of the fruits that they require in order to make this meal that they refer to as COBie. I find it amusing. Because they come back looking and sounding like the walking dead, like they have been on some month long 'slash and burn' exercise. And what astonishes me, is that some people still think that having this huge, singular central jungle and building this road into that jungle to deliver the COBie, is the right approach. I find that amusing.

    There should be no going into any jungle, and the jungle should not exist. It goes back to 'layers' all over again. That was a jungle if ever there was one. One had to hire this special Michael Douglas kind of character, a bit dodgy, a bit reckless to attempt to negotiate the jungle of layers.

    Satellites. Satellites, are a good analogy. Sputnik. I would have my grid information in my project file, launched out as soon as possible and allow it to orbit. Allow everyone down in the jungle to look up at the orbit path, and know that Sputnik was passing over their heads. Take them out of the mentality of being in a jungle, where it is all about slashing and burning to try and get by. But the BIM guys seem to think it is all about jungle maintenance, and the COBie guys think it is all about building highways into the jungle. What we really need in all of this are Russians (circa 1950s).

  3. We have geometry, and we have data. A lot of people believe, that we need both of those, and that we need more of the later. Geometry was always robust enough, that it could be allowed to float freely in space. Because as human beings, one of our capabilities is pattern recognition, and we know is less than seconds, how to pick up on something that is pattern related.

    But it's different with metadata, data about data. Computers are better there, and yes, by all means lets have a central database for that. But the mistake that BIM makes is trying to keep the geometry alongside the data. And then the COBie guys have to figure out how to run into the jungle the gather the data, distributed around inside that mass of geometry. It is pre-agricultural stuff.

    I don't see geometry as geometry, I see geometry as data, intelligent, fluid and meaningful. It is important for people who only see geometry as geometry to change their way of thinking. What some do not seem to acknowledge, is what they refer as data, is not raw 'data' at all. It is only data about data. I'm all for keeping the 'metadata' that people refer to centralized. Software engineers do understand the possibilities inherent in being able to work on metadata in a central sand box. But equally, the software engineers do not seem to understand how geometry needs to operate.

    I know that it is important to make geometry in the form of distributable objects, which are not central to any native application file. On the other hand, where metadata is concerned, the SPEED and efficiency comes from working in the one sand box. I learned a little about metadata recently, because I was able to work with some of the systems that cost planners and estimators use. Those cost estimation tools are all data about data, and all about single, native application files. They are quite cool actually, when one gets to know them. When one understands them a bit, it is amazing what they can do, without ANY geometry whatsoever, used only (meta-)data.

    Yes, the trend nowadays is for cost control systems to be able 'to see' geometry. It the past they may have been accused of being deaf and blind as far as geometry was concerned. But the modern cost control systems, do assume that the geometry is remote from the application file. Cost control systems therefore, remain satellites themselves, and do not have to become huge standalone databases. They do amass a considerable amount of metadata, but they don't become overweight. The cost control and estimation databases, are like objects itself within the greater environment.

    Why can't COBie be more like that?

    BIM applications should have a capability of launching satellites into orbit on a regular basis. They should also have strong communications antennae, that is internal and allows them to receive back stuff in return. All BIM applications should constantly be sending things out, that become independent in themselves. The native file should only be data about data, and annotation as far as possible. Geometry should be out there doing its own thing. The case for having any proprietary geometric format, or combined geometric and metadata format in 2013, with the pretence that it leads to some efficiency is just not true.

  4. Without getting too deep in the physiology and a lifespan of a concept, I find myself in a position where I am compelled to defend a standard that is characterized by its lack of sex appeal an for the sake of clarity I will stick only to those statements that are defining the very foundation of this discourse.
    a) Spreadsheet concept.
    a. On this one I would completely disagree, as COBie deliverable format can be anything that an end user wants it to be. The spreadsheet idea has the purpose of the lowest common denominator in the same way that one could argue that Masterformat is a flat text file with not direct linkage to object based concepts of BIM. How the standard is being delivered is far less important than the type and the quality of information it intends to capture. Focusing on the collection technology, is not helping us when the actual validity of an idea is to be paired with the problem that needs the resolution. That would be as same as saying that reading a hardcover is not an acceptable option, or that alphabet needs to change due to ever increasing use of instant messaging.
    b) Omniclass confusion.
    a. Maybe after looking for too long at the way we (read Contractors) bastardize both Masterformat and Uniformat in our respective organizations, and how ill-informed professionals are when it comes to intended use of those two respective standards, I am not surprised that bringing an overarching umbrella to something that is poorly implemented, particularly within BIM domain, causes some grief. However, having said that, the BIM world and the profession overall would be better served if we actually spend some time trying to understand the need for Omniclass table structure that provides quite a bit of leverage to handle BIM related concepts, such as spatial organization, resources, components, work and assemblies. So in my humble understanding, a primary focus of COBie is to provide an optimized access to relevant data which is required for further integration into any number of CMMS systems, and by doing so the information needs to have the capability to be defined at both the element and the system level. By doing so, it just makes sense to link COBie fields to a standard that establishes this relationship on multitude of levels that are not only COBie related, but play nice with one’s desire to integrate cost codes with estimating process and scheduling activities as they can all be obtained by tapping into Omniclass potential.

  5. I have been leading the integration of BIM data into IBM CAFM and IWMS offerings for the last 4 years. I am supporting COBie as a primary integration mechanism. Why? Because it defines a workable model of the BIM data required by the owner operator, and it provides a very easy integration that for not much more complexity than uploading a picture to Facebook give an owner a well-structured and function facility in our Maximo CAFM system. Yes, we easily support highly customized CAFM systems, but more importantly we strive to reduce the needs for such customization by providing an automatically generated data model derived from COBie that reflects best practices.
    That said I’d like to address some of the points John raised:
    What is COBie?
    COBie is a data model it can be described as a formal Entity Relationship Diagram (ERD). It doesn’t matter whether it is represented as a spreadsheet, or in IFC. Even if I move to a modern fully linked and federated cloud base environment, I still need a standard data model for information interchange. COBie is a reasonable candidate for that standard.
    COBie is a contact specification. A way for an owner to communicate to their AEC partners what data they need to successfully operate their building. It imposes a transform on the model that converts it from an AEC view to an O&M view. Owners don’t want to look at how buildings are designed. They want the AEC industry to understand how buildings are operated and maintained.
    COBie is a tool to facilitate changes in business processes and relationships. If we move beyond a single COBie deliverable at handover to a series of deliverable starting at bid with dynamic updates to the CAFM system during construction, the owner gains visibility into the construction phase and can become a partner in the commissioning process. Handover becomes a shared process between builder and owner, not a point in time event.
    How can COBie improve?
    The data model needs to be more rigorously defined. This is particular true of the attributes that are simply a pass through of the unstructured attributes used in the design phase. The exact syntax and semantics of most fields is still poorly defined. One of the largest challenges I faced in integration COBie into Maximo was harmonizing the varying semantics I’ve seen across the large number of customer models I’ve worked with. The more rigorous the definition of the COBie data model becomes the easier it will be for the owners to gain real value from the data. They need to have a consistent and well defined data model that supports automated processes and reporting, and they need consistency across the portfolio of building they manage.

  6. I’ll present this here:

    Is not the purpose of an information exchange to negate the need for multiple software’s? Shouldn’t an information exchange allow the Authoring software to talk to the CAFM/CMMS system because it is acting as a translator? Why if I am using and information exchange do I need to take it from the authoring software, convert it to IFC, and then use another tool to get the information into my CAFM/CMMS system.

    If open BIM is really free then I shouldn’t have to train my personnel on it correct; they should just get it because it is so intuitive.

    These points and the one’s brought about in the article are made to get you to think. Knee jerk reactions will never solve anything proper dialogue and discourse will.

  7. What a negative article.

    Author in BIM software > output as ifc > use free tools to generate COBie drop.

    Not simple but very doable, remember you're the one saying there is no BIM easy button.

    The most useful comment I have heard about the purpose of COBie is that it is an accessible common format that allows data capture commensurate with what we are putting into BIMs but don't want to lock into a software developers format while the industry gets up to speed on an open tranfer of richer data than 'just spreadsheets'.

    The biggest issue is the the world of FM is just coming to BIM and like all industry sectors they are throwing toys out of their pram because reform of FM means understanding and managing data in an sector that has a terrible record of doing that. The fact that this is a convenient way out for consultants and contractors who don't put information into their models yet is pretty self evident in the sudden affinity between the voices of the two.

  8. Paul, I completely agree. We have to take responsibility to understand and ensure the type of deliverables we need to maximize our benefit.
    (I've also got that book on my amazon wishlist and will be checking it out when I've got time.)

  9. Recently IFMA published a book titled BIM for FM (for which I was the editor and part author) that has case studies that show how and why owners are using data collected during the design and construction process for the systems that they use for supporting FM. Not all of these owners knew about or were using consultants who were competent COBie users, but some were and found that COBie was a good way to collect and communicate the data they needed. Using COBie or not was not the major issue, knowing what they wanted for FM and then specifying how this was to be achieved and what naming standards to use proved to be difficult. Most owners do not have this knowledge. Fortunately, there are software vendors and consultants that do. But owners need to take more responsibility for this process and, of course, for the proper use of the data needed for good FM performance.

  10. The problems of this article are well addressed in the LinkedIn COBie group. I decided to provide this comment here since I realized that John published the link to this article in several LinkedIn groups.

  11. Hi, Dennis… I'm an owner and I use my models.

    Just a clarification of what types of 'owners' there are, and how they might each benefit from BIM:
    http://mistressofthedorkness.blogspot.com/2012/09/what-does-owner-want-with-bim.html

    I'm always disappointed, too, when I see an exciting case study, and I contact owner to talk to them about it, and they're not continuing to make use of the model post-occupancy, but, just be assured that we're not all like that.

  12. Grady's at it again.

    Spot on and well said!

  13. John – Not afraid to poke the bear

    I would like to make a comment on #3 of problems;

    Recently, I spoke at an event where I asked all the owners in room to raise there hands. I got a quick count of 14 that went up including one of my co-panelist. I asked them how many have received a BIM and/or COBie deliverable, about 10 hands stayed up. Then posed the question of how many are using the information they received… Not a single one stayed up. I know this is a small sample and I probably only have regular contact with about 30-35 owners, but something to learn from that.

  14. Great post. Very thought provoking and timely since we are in the process of having to figure out how to incorporate all of this Cobie data on a larger project. I look forward to seeing others response to the topic.

Leave a reply