The Future of Uninteroperability

There is no doubt in my mind that BIM is the future of engineering.  It is only going to get more advanced and more critical for students to become familiar with the process.  That being said, I cannot say the same advancements will be made toward interoperability. 

As I said in last weeks post about being familiar with the hassle of interoperability through a team project.  Out of the 40 hours we were supposed to spend on the project we spent at least half of that trying to figure out how to transfer data from one program to another, and we still don’t have a fast and easy method to use. 

Mike says it perfectly, “[Interoperability] will only persist and grow into more of a headache as new technology constantly keeps pushing [...].”  This statement sums up that the path towards interoperability will be a struggle.  I find that the solution that he comes up with is flawed, however. I don’t feel that a program that can take any file type and format it into another file type with minimum loss is the solution.  Is it a good idea that should be pursued, of course, because it is a step in the right direction.  I just don’t feel that it will solve all of our problems.  The BIM software is constantly updating, and therefore, this new software would constantly have to be updated in order to be sufficient.  That is just another license that companies need to buy and those licenses aren’t cheap.  Kayleigh voiced her doubts about multiple licenses last week in class.  On another note, software packages like AutoCAD and Revit already have file converters that can take a file and convert it into other workable file types.

I personally think that it would be easier in our field, Architectural and Civil Engineering, to be more communicative with the people that are going to be working on the project.  Then there could be standards set on a per project basis.  The architects would know what the structural engineers are going to use and vice versa.  I also think that companies should be more flexible in the software packages that they use.  I have had experience where certain architects (and I know engineers do it to) ONLY use said program.  A lot of the programs structured similarly.  They might have minor differences but for the most part they all do the same thing.  A prime example of standards being set on a per project basis, that Eric mentioned last week, would be that any project done for the Army Corp of Engineers requires a Revit Model.  That being said, everything needs to be done in Revit.  That way the transfer of files will have limited flaws.  

Of course having standards on a per project basis isn’t ideal either.  It also requires multiple licenses, a lot of computing power, which in turn requires a lot of money.  That is the opposite of what companies want to do.  We are working towards a solution to minimize the 15.6 billion dollars that the industry wastes on interoperability.  In conclusion, I do not think interoperability will make much advancement in 5, 10, or even 15 years.  I think methods will be made in order to work with it and possibly even cut those 15.6 billion dollars in half, but I think it will be a consistent problem.