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.
3 comments:
This topic is a curious one similar to the one's that Robert Bess & I were making to Autodesk at last years AU. The GIS industry has had the same interoperability problem for years. The biggest problem is that an effective core engine for creating a model (i.e. Revit) may not be the most effective program for Analysis. When I did GIS we created multiple data translational paths with SAFESoft's FME that would provide seamless interoperability in a world that Autodesk had no clue on creating. We had taken Mapguide their product and through some programming skill from Manoj's crew at Websoft development created a GUI that could integrate PLM (Project Lifecycle Management) to They later created a product similar called Topobase never coming close to Infrastructure management. At AU last year with some FM Desktovelopers to discuss how they put the seamless presentation they did the first day showing AEC, GIS, FM and all levels of design seamlessly integrated. They said this was all DWF data. Anyways, you may wonder where I am. going with this, all modeling or drawing is just a Database. AutoCAD may call it a DWG, Revit a rvt, or Microstation a DGN. There is a given mapped structure the drawings have and how the objects / entities are handled. I was previously speaking with Raymond Kinser owner of CalCAD about SafeSoft creating a migratory solution for interoperabilty. The challenge comes to this If you create a BIM thatdoes everything well, the program becomes clunky and less efficient (i.e. ArchiCAD I Microstation). Also the product becomes to complex to train people to use. Thats why I useRevit.
Jeremiah
I appreciate your comment!
First I wasn't necessarily suggesting that the native file format be the means of analysis. Rather that the summation of information from other software tools feeds into the native software format fore reference during editing.
For example, how nice would it be if you could run a clash detection on your model in NavisWorks, import only the report back into your native file format and resolve the issues where you edit the files! I know right now coordinate mapping isn't a lot of fun...
Interesting stuff about the DWF file type and how interesting is it that the DWF file type is useable across the board? I'm with you though here. DWF is great because it's not a "heavy" file type but works pretty well. Problem is how can you bump it up to a "BIM" level file type without adding too much information to it.
While we are on the topic of Native formats, our BIM models should really be "written" in a buildings native format - "Building Language (B++)" (which is probably more like Construction Language).
The software that architects use to create their BIM in may read and communicate in A- (ArhiLanguage) but its native language and what it writes is the global B++.
That is to say that the BIM software for Architects is applying a series of translators and filters to allow Architects to design and model in our language but write data in Building Language.
A really basic example (I mean this is really dumbed down and I don't mean to imply that there aren't more rich ideas in Architecture):
Architects Language: Wall Type-F1 and Wall Type-D1
B++: A single row of vertically assembled 16 gage metal studs spaced at 16inch centers in a 10' long row. 5' of which has drywall on both sides (which makes this area Type-F1)the remaining 5' has plywood and drywall on both sides (Type-D1).
Now all of a sudden, the Structural Engineers BIM software can filter this into a format that works for them. The Contractors and Builders into a format that works for them, etc.
The key being that because the building ultimately must end up in B++ to get built or be a building we begin with that as the Native Format. Revit and ArchiCAD at least have started with the Architectural shorthand we developed we developed in order to document buildings on paper and are now trying to figure out how to translate and coordinate all disciplines through this language.
Post a Comment