It starts...interoperability and singular modeling

So here's some exciting stuff...INTEROPERABILITY!

Recently had a great meeting with some of A-desk's software development task force and found that there is light at the end of the tunnel....hopefully.

So here was in essence the discussion we had.

The first topic of discussion was interoperability. The question came up how important is it? Where we see it being effective and why?

Umm...where to start? Does this meeting involve beer? If not why not?

Moving on.

Interoperability affects all of our professions. Currently, it cripples a lot of the day to day tasks that should be a LOT simpler than what they are. As any BIM Manager or Virtual Construction manager worth their salt will tell you there's always a solution. It just might take half the day to get it there.

During this discussion, I brought up an epiphany I had after talking with a buddy of mine who is a programmer for Apple, Joseph. Joseph is a super smart guy and I revere the fact that he has started up two very successful software companies sold them and continues to work for Apple because he likes the "environment". (I personally prefer the environment in Cancun, but to each their own) So I thought I would throw this issue of interoperability at him.

After asking the question, Joseph thought it was hilarious for some reason! I asked him what was so funny and he said because they faced the same issues in his industry years ago. Apparently Windows' take on interoperability between systems was that they had the "best" solution for PCs out there and that they didn't need to conform to any of the Apple software protocols.

So Apple made their existing systems not only interoperable with Windows but every other "highly used" system available. This included both Unix and Windows software, web interfaces and so on down to the printers and the Ipod. He went on to say that Apple took the stance of change the industry, by example and as a result (sans current economic downturn) saw a revenue growth of almost 200%! With the mantra of, "Plug it in and it has to work. No matter who made it."

Joe also went on to talk about how the answer (in dumbed down terms for me) was filters. He said computers should do the work, humans should make the decisions. Taking data and pushing it through an analysis filter such as (his words) NavisWord, (Joe if you're reading this I have to give you a hard time!) and viewing the results directly in the native format.

Whoa...I thought. Native format huh? He said "Yeah you know whatever you created the file in is inherently where the most data and toolsets reside otherwise you wouldn't have been capable of creating it. He said the key is the same base language otherwise you end up with a Tower of babel situation. In programming if the language is C++ than the entire team knows how to work with it. This doesn't mean that designers have to use the same software that database programmers use or that interface programmers use. What we're talking about here is use the tool that makes it easiest for you, so long as you can get the information in the end to C++. It's not rocket science man....everything needs to talk the same language. In the end after you push it through these filters, fix it, test it, filter it, fix it, test it for about 30 times you end up with a useable product."

Now I'm just a lowly BIM guy, but it seems to me that there are some direct parallels here. The fact is that BIM as a deliverable needs to remain in the native file format. (Revit, Bentley, ArchiCAD) however, filters such as clash detection, energy analysis, estimating bring value to the table as they accomplish testing tasks that the native software isn't capable of. Lastly, exporting the product in the form of animations, stills and graphics are a snapshot in time and shouldn't be relied on other than visualizataion and better communication of the idea.

In the end, the Autodesk boys were sitting there, with that aha look on their face. Hopefully they go back to the rest of the team and expand upon Apple's model that interoperability isn't "optional" it's a way to be more profitable! Of course, we are talking about the software industry and sometimes that takes a while....

Also I wanted to thank Joe for his take on the interoperability issue.

Brads Take on Parallel Modeling

Recently I was asked why I try so hard to keep a singular model in Revit using the architects', MEP and structural information when I could just as easily create my own.

Great question.

My answer was, "Because there is only one google."

Needless to say this slightly confused the person asking the question who couldn't seem to draw the parallel I was trying to make.

I further elaborated on this concept and point.

BIM is not CAD.

BIM will not and should not be forced to function in the same way we have been using CAD for the past couple of decades. The old CAD way had us managing hundreds or thousands of CAD drawings that were somewhat organized in a format we pray can be managed later in the project when due to schedule constraints the project manager throws thirteen new and strange people to draft on the project. Where more often than not they are inputting loads of information that is incorrect, contradicts other drawings or the specs and then wonder why document quality stinks.

CAD is a series of information silos. No I don't care about xreferenced drawings.

BIM is not an information silo.

So to get back to my point. There is only one google.

Google is a great example of one source of user entry, input and extraction that streamlines and manages the information for the user in a useful way. Currently valued at over 158 billion dollars, even in a time of recession, (people need information now more than ever..) there is something to be said for the value this tool creates. That said there is no separate site for any of the following:

- Google for Engineers
- Google for Architects
- Google for Construction Managers
- Google for Subcontractors
- Google for Field Personnel
- Google for Estimators
- Google for Owners
- Google for Code Compliance
- Google for Sustainability
- Google for Facility Managers
lastly...

No specific Google for BIM Managers, Virtual Construction Managers....either

The real value and appeal of Google is a single source of information.

A fundamental screw up in the way our industry is heading is not working together to begin building an actual honest to god usable tool. It's easy for us general contractors to get in a rush, think we're more important than the rest of the team and fail to understand the value of educating the team above to create BIM's correctly as opposed to wasting a lot of time and resources of the course of the next 111 projects with the same team or same members.

Conversely, GC's need to gain an understanding of what is important to the team members to see from us (GC's). Turns out no one on the team knows it all and the better we can facilitate answers for the team the better results.

....just like Google.

BIM and Project Modeling

So I had an interview with Ed Goldberg from Boston about BIM and how construction companies are currently utilizing their BIM's and how they are interfacing both with the software they have and with the project team as a whole. I was kind of shocked to learn that fully "collaborative modeling" like our shop has set up isn't that common, in fact, it's rare.

I've been asked a couple of times why we do it differently, why we choose to do single / same model coordination. The reasons are simple, but ultimately BIM in and of itself is really only part of the greater pie.

With technology advancing (finally) in the AEC industries, I don't think we are about to see a slow down in the amount of information and coordination that affects the teams decisions and coordination. Ultimately, I think that by setting up the flow and management of information correctly now we won't have to reinvent the flow of processes the next time.

Secondly, I know the opportunity for improved communication and growth is a real need. The opportunity in using a singular BIM forces the issue of communication and coordination. Just as your "forced" to model walls to exact dimensions, BIM pushes the team to collaborate and define, just where are those construction joints? how is this panel going to be constructed? what is the necessary aesthetic for a space? what is the owners program and can we design those spaces first?

What we've started to see, is yes it's the "harder way" to construct a BIM. And that's the point. The point is to make sure that everyone involved has access to input and share the same information regardless of the others undertanding of what that teammate might need.

When we start to see overlap and questions pop up of "Well how are we going to get the ductwork through that? etc..." is when we know we are in some way creating savings.