The January 19, 1998 release of "Wag the Dog"—a film about perception and reality in communication media—warned against the tail wagging the dog, or the medium determining the message. While not as momentous as national interests satirized in the movie, the risks posed to the AEC community by then-new communication technologies raised similar concerns: was the Internet “tail” indeed wagging the design and construction “dog”? Five years on, with the intervening "dot-com" bubble inflated and burst, how are the AEC, FM, plant/process and infrastructure industries faring in the communications revolution?

The Internet promised to simplify every preexisting form of LAN, WAN, remote access, messaging, document management, and database through the universal interface of virtually free browser software. That was good. What was not so good was that fulfilling this promise spawned a new complexity of Intranets, Extranets, Project Specific Web Sites, Virtual Private Networks (VPNs), Active Server Pages, and Java applets. Firms that were not networked at all a few years before now had to supplement their all-purpose file servers with multiple dedicated servers. They had to reorganize and republish their applications and data according to the type of “Net” they were on (Inter/Intra/Extra), rather than the needs of users or the logic of content. The tail started to wag the dog.

Rushing to "Web-enable" every aspect of AEC communications, some folks forgot that AEC businesses revolve around people and projects, not programs and protocols. When you or I dial the phone we don’t care whether the connection is routed through an in-house PBX, the local telco’s CENTREX service, a branch office tie line, or a geosynchronous satellite. Similarly, architects and builders don’t “want” Project Extranets or VPNs, they want effective, economical, and secure means of rapidly sharing appropriate information with appropriate team members.

While reiterating my long-held view that we must radically reengineer the AEC industry through multi-enterprise workflow, I also believe that we must simplify and streamline our technologies to make them more usable and useful. Although this goal can best be achieved through the universal interface afforded by Internet technology, the hard problems are not technological but “social”—not electronic protocols but “human protocols.” To revisit the canine metaphor, what steps will make this puppy wag its tail rather than the other way ‘round?

First, I suggest a return to basics. Instead of defining communications by type of server or location inside/outside the firewall, reexamine the sender/channel/receiver core of every communication. Identify source, content, and audience. Then, and only then, choose appropriate storage and transmission media, protocols, access interface, etc.

Second, sort communications by type of activity and timeliness of content. Gathering information and disseminating it are not mere mirror images. Interactive communication is more than just the sum of sending and receiving. Publishing or subscribing to reference data is very different from updating information, which is different still from news.

Next, distinguish project related from non-project related content. For example, non-project information gathering of news about competitors is an entirely different communications process—source, content, and audience—from disseminating project-related update information about drawings or specs.

Finally, remember that—just as with initial adoption of computerized financial management or early generations of CAD—every step of each existing AEC communication process must be analyzed, documented, and formalized for a smooth transition to new modes of Web-enabled management. Only by classifying the full spectra of sources and audiences for each type of communication is it possible to assign AEC business tasks to the proper sorts of servers or networks.

As in prior waves of AEC automation, anticipate that the custom solutions developed in-house by large-firm early adopters will be overtaken by shrink-wrapped product as the market expands. Mid-market project site rental solutions risk the fate of service bureaus—few economies of scale and few barriers to entry by cutthroat competitors. Historically, generic solutions, like the earliest AutoCAD, gradually expand up-market, through enhanced internal functionality and third-party “vertical” add-ons that offer AEC-specific bells and whistles. Also from an historical perspective, users will shift from renting to owning mission-critical tools as the underlying technology matures. Finally, what we now know as "last-mover advantage" may come into play—later entrants to a market can learn from and improve upon the pioneering efforts of "first movers" and ultimately dominate the market.

Rather than struggle with the complexities of piecemeal solutions, the time is at hand for AEC firms to simplify project and practice management with integrated solutions. Reverting to the canine metaphor, maybe the old dog can be taught some new tricks. Whether you're a user or a vendor, let me know what you think.

Editor and Publisher, The LaiserinLetter^™
Analysis, Strategy and Opinion for Technology Leaders in Design Business

NOTE: Portions of this article originally appeared in the Winter 1998 issue of the now-defunct A/E/C Systems, the Magazine of Computer Solutions.

< back