Responding to IssueNineteen's LLemma—Wag the Dog, Michael Hogan of Chicago's Ideate LLC, writes:
> "Your tail-wagging lemma struck a chord with me. Of course, tail wagging is not limited to 'hot' technologies. All the software bits and pieces of a working infrastructure that are intentionally marketed to non-technical management can be included.

"How many firms bother to make product selections based upon a valid needs analysis and financial cost-benefit projections rather than going with the well-marketed Microsoft/Autodesk solutions? When technology selections made by those without wide technology experience are based solely upon market share and ad placement in business journals and architecture rags (and by the ‘hot topic’ articles in those sources), we all suffer.

"Indeed, how many firms feel the need to break the law by using illegal copies of these arguably overpriced solutions just to be on those particular bandwagons rather than finding the sometimes more correct, more stable, better supported and fully legal solutions they can afford?

"First, the right people need to be asked to recommend a solution based upon the firm’s needs. These people must be experienced architects and widely experienced technologists. To do otherwise is like asking your marketing department to select a roofing system for the next project—where’s the expertise?

"Second, those doing the evaluations need to differentiate between fads and trends (usually easy to do with experience and an honest needs analysis).

"Let’s hope that software and operating systems will become selected based upon a professional assessment of need, costs and stability and are properly and legally licensed. Perhaps we’ll find that prices will reduce, stability will increase, and licensing terms will become more balanced as a result.

"Thanks for your newsletter—and for the provocation to write."
Michael

> Thank you for the kind words, Michael. I agree absolutely that too many technology acquisition/implementation decisions by AEC firms are based on superficial factors that have little to do with the appropriateness of the tools to the underlying business/practice. It's also true that experienced AEC technologists can add significant value to the platform/application selection process—after all, Michael, this is a process we go through many times each year, while our AEC client companies only make such choices at two, five, even seven year intervals. Finally, there can be no excuse for "using illegal copies" of software—it is theft, pure and simple. Reasonable people can debate the merits of recent USA extensions of copyright duration, as well as digital media preemption of traditional user rights such as "fair use," but the answer can never be to steal copyrighted property—whether software, written works or architectural designs.

Jonathan Cohen, the renowned Berkeley, California architect-planner, educator and author, joins our ever-expanding debate on Building Information Modeling (BIM) as the superset/successor to "CAD":
> "I’ve been following with interest the discussion about BIM, and whether or not the adoption of a new term will move the industry toward what everyone agrees must be a new approach to managing building information. More important than the adopted acronym, I believe, is some agreement about exactly what it means. The danger is that the marketing folks will jump on this new term and use it to dress up an old product in new clothes. Some will claim that they have been offering BIM all along! Remember "object-oriented CAD"? What the heck did that mean, exactly?

"It’s clear to me that BIM must be the repository of all kinds of project information, not just the geometric, spatial and material information that is most interesting to architects, but also the costing, scheduling, fabrication, phasing, maintenance, energy, and life-cycle information that comprises a complete building project. If this is true, there is no existing example of BIM in use today. Even a parametric modeler like Revit or Archicad is limited to a small subset of the overall project information.

"The term model as used here is a bit misleading, because we are talking about more than the computerized version of a physical model but really a kind of database that encompasses all the physical characteristics of a building and much more. When architects think of a model, they imagine those wonderfully seductive miniature buildings that are so effective in presenting their designs. My understanding of BIM is that it is an entirely new paradigm for describing buildings that embodies three-dimensional geometric information, but also information about the attributes of the components being modeled, such as what they are made of, who makes them, what they cost, how long they last, and how many worker-hours are needed to install them.

"I would like to see an agreed, detailed, definition of BIM, or whatever we finally decide to call it. Better yet would be some kind of independent certification process that would tell the end user whether or not a product really is BIM. Is BIM a single software product, a suite of products, or the ability to interoperate between disconnected information sources? And once we decide all that, let’s talk about the really interesting stuff, like who owns it, who pays for it, and how you reconcile the idea of a single building model with the individual intellectual property rights of the dozens of people who contributed to it."

> Well, Jonathan, the answer is "yes" . Yes, BIM needs a rigorous definition, and you've posed many of the key questions that would steer this debate toward such a definition. Yes, none of the commercially available "BIM" products is a 100% complete solution in its present form.

> Yes, in a market economy there will always be some risk that an errant competitor or two will choose to compete on the basis of vaporware sloganeering instead of software engineering. In this regard, one advantage of BIM as a label is that it describes stuff that is use-oriented and user-observable—compared to discredited labels such as "parametric" and "object-oriented," which addressed technical characteristics of software design that were not observable by users.

> Shifting gears, I'll give a "no" to "some kind of independent certification process." Certification requires standards, and premature standards can stifle innovation, rather than encourage it. If anything, we should first look at what you rightly call "the really interesting stuff, like who owns it, who pays for it, and how you reconcile the idea of a single building model with the individual intellectual property rights of the dozens of people who contributed to it." The concept and principles of BIM date back at least to 1975, and the obstacles to adoption have never been primarily technological nor a function of marketing or mis-marketing.
JL

< back