Interoperability – Week-5 Discussions

Once again you produced an interesting, generally well-written, set of discussion posts that showed even more awareness of what your colleagues had written.

• VistaBB shows me the number of posts that each person has visited (and probably read).  This week the lowest was 4, the highest (several) was 47, and many had read 10-15.  Several of you replied to multiple entries.

What follows are my reactions to a number of issues that you raised, not offered as “the answer”, but observations based on a reasonable amount of experience.

The Importance of Interoperability

• Most of you agreed that interoperability was a ‘good thing’ if it meant that one couldn’t be locked into a single vendor – as has happened in prior computer situations.
• A number of you were appropriately skeptical that the interoperability solutions addressed in this chapter were panaceas – for multiple reasons:
• Vendor greed – wanting exclusiveness to lock clients in
• Inherent technical difficulties with different (valid) approaches to the same problem
• The inevitable lag in producing a standard that can be adopted by all
• She sheer complexity of all the elements of a building – would it ever be possible to address them all
• My answer is “yes”, with mechanisms for addressing exceptions.
• Overblown claims of interoperability by vendors leading to errors and rejection by customers.
• This cries out for checking systems built into the transfer software mechanisms.  The software industry is quite good at this.
• My own suspicion is that someone is going to come up with a web-based system that provides the repository function.

The Variety of Customer Needs

• The chapter addresses, but few of you mentioned, the fact that there does not need to be full two-way data exchange in many situations.
• Technical consultants who can directly affect the structure of a building often do need two-way data exchange to allow the iterative design process you described quite well.
• Many other players, however, need only to be able to view the data and not to send it back directly.  That’s an easier problem that Eastman et. al. show has good tools available.

A Few Clarifications

• DXF is explicitly intended for data exchange.  It was developed by Autodesk (who has played games with it), but it’s well defined and has very successfully been used by others.  Characterizing it as proprietary is only 1/4 right I’d say.
• “File Exchange” is a fuzzy term.  Except where there is direct communication between programs (via the API usually), almost all data is exchanged via files.  The problems that many of you identified lie in the fact that there may be many versions of files, with conflicting information in them.  The goal of a repository system or a master-file is that there is one agreed-upon place that’s regarded as having the latest full information.
• A refinement of that, an important one, is that it’s desirable to keep track of alternates, old versions etc.  That too is possible with both these approaches.

Jim Mitchell