Jerry Laiserin, FAIA

Coding for Behavior

As Internet technologies mature, they become more differentiated, akin to the division of labor first observed by classical economist Adam Smith. Overall operations yield significant increases in productivity if individual operations are specialized, with each unit or operand-whether a person, a machine or a software program-optimized for a relatively narrow, specific sub-task within the overall activity. Where there is specialization there also will be competitive advantage, as the talents of individuals, the functions of machines or the architecture of software make some operands better suited for some operations than for others.

For example, the profit motive helps educational and social systems channel people into suitable career choices. A visit to any well-staffed startup company reveals the result: soft-spoken directors of programming who rarely gesture, expansive vice presidents of marketing who are virtual windmills of expressiveness, optimistic but driven CEOs to whom having the corner office really does matter. Similarly, we're taught from childhood to use the right tool for the job; we don't hammer screws or use screwdrivers to pound nails.

Yet when it comes to software, we constantly stretch a program's designed-in functionality, its architecture, to cover operations that may never have been intended by the program's developers. Some folks use Microsoft Word tables and Excel spreadsheets almost interchangeably, ignoring the specialized features that differentiate them from each other. Both tables and spreadsheets are pressed into service far too often when the problem at hand really requires a database-management system (DBMS), such as Microsoft Access or Filemaker Pro. Designers may attempt to "paint" in a CAD application or do photo editing in an illustration program. Managers seem unable to resist torturing a financial-management package into performing project-management functions and vice versa.

For single users running stand-alone applications, such mismatches only incur a cost in individual productivity. However, in collaborative environments, with multiple users sharing the same information, whether concurrently or successively, the performance of the entire team may be handicapped if each individual task is not done in the most appropriate manner-in much the same way that an Olympic swimming relay team would suffer if a freestyler swam the backstroke leg of a race.

The Right Tool

Online collaborations place an even greater premium on applying the right tool for the job. The nature of collaboration via the Internet-who gets what access to which information when-depends on the underlying structure, or architecture, or code in ways so deeply embedded in the logic of the Net (and in our perception of that logic) that we often have difficulty teasing out what the differences are and how the options can be manipulated. One of the best guides for understanding this deep structure of Internet code and its relationship to and regulation of behavior is Code and Other Laws of Cyberspace by legal scholar Lawrence Lessig. Unlike cyberlibertarians who insist information wants to be free, Lessig argues that the Internet has no inherent nature, but is the result of policy decisions embodied in code, which determine behavior. For example, a Web without cookies would render most subscription- or transaction-based behavior cumbersome to the point of impracticality (cookies are small identifying files placed by a Web site on your hard drive to identify you to the site on your next visit). Commercial transactions require many kinds and levels of identification, authentication, certification and so forth if any two or more parties to a transaction or project are to collaborate with a degree of trust comparable to non-Internet commerce.

If Internet architecture is policy, as Lessig maintains, then desired policies and behaviors must be designed into the underlying structure of successful online systems. By extension, those seeking to successfully Internet-enable existing commercial behavior, such as project collaboration, will seek out Internet architectures appropriately coded to support the desired behavior. Unfortunately, many providers of collaborative Internet solutions rushed into architectures that do not necessarily provide optimal support for the expected behavior of the intended market.

Figure 1a. Both "enterprise" project hosting and project-specific extranet hosting	Figure 1b. have centralized software architectures best suited to centralized project behavior. (Courtesy of ProjectVillage

Many project-specific Web site (PSWS) or extranet solutions are structured on the enterprise model: an organization internally hosts all its own projects, providing document repository, message clearinghouse and transactional database functions for suppliers, customers and business partners (Figure 1a). This central site, to which all documents and data are posted, also could be outsourced as a third-party hosted application, as shown in Figure 1b. Either way, it is an architecture that hard codes a one-to-many model of behavior. Some collaborative businesses are well suited to either of these post-and-host models. For example, concurrent engineering, product development and collaborative product commerce-the sorts of things done by the Global 2000 manufacturers and their suppliers-are well supported by this centralized approach. It matters little, in the code/behavior sense, whether the posting and hosting is "in here" or "out there." What does matter is that the behavior being supported/regulated by this architecture transpires among a relatively small, stable set of partners typically dominated by one or a few central players. This is true for many (but not all) MCAD-related collaborations and for facilities management (FM) collaborations consisting of an owner-operator and its MRO (maintenance, repair and operations) suppliers.

Figure 2. Software architectures coded for one-to-many behavior, such as conventional extranets (left), may not be the best fit for projects with many-to-many behavior (right). (Courtesy of ProjectVillage)

Figure 3. The Enterprise Community model of ProjectVillage.com attempts to combine the best features of server-based and peer-to-peer sofware architectures for project collaberation. (Courtessy of ProjectVilliage)

Thus, enterprise solutions such as Framework Technologies' ActiveProject (http://www.frametech.com/) have gained their greatest traction in markets such as collaborative product commerce and large-scale, corporatewide FM-in other words, spaces in which the enterprise/hosted product/service architecture matches and supports the intended/desired one-to-many behavior (see also Online Collaboration, "e-Suitable for c-Framing" CADENCE, January 2000, pp. 51-53). Most AEC collaborations, however, are characterized by many-to-many interactions among large, ad hoc groups of designers, constructors and owners. Behaviors and workflows tend to be less centralized than MCAD or FM, as shown in Figure 2.

Matching Code to Behavior

As I have written before, and likely will do so again, the single scarcest and most valuable resource in any project-centric organization is the time and attention of experienced project personnel. One way for Internet collaborations to maximize this resource is to provide a uniform interface across all of an organization's projects. For organizations dominating their own stable business ecosystems, such as automobile manufacturers or international hotel chains, this behavior is easily accomplished through the architecture or code of a post-and-host enterprise system for collaboration. For the many thousands of building architects, consulting engineers, general and specialty contractors in AEC, there are too many mix-and-match project possibilities to fit into any one enterprise/hosted solution.

Bidcom, BlueLineOnline (aka Cephren), Cubus and eBricks all tried shoehorning AEC behavior into the post-and-host model. With these four one-time industry leaders now rolled up into Citadon (http://www.citadon.com/), there are persistent reports that the new company is shifting its market emphasis towards larger projects ($10-million or more), more select customers (such as Bechtel and Flour Daniel-large, dominant customers who also are investors) and strategic facility-focused accounts (such as hotel chains, Real Estate Investment Trusts [REITs] and the like). Citadon's future would thus seem to depend on seeking out those markets and behaviors that can best utilize the access features of its coded architecture.

Buzzsaw (http://www.buzzsaw.com/) and Bricsnet (http://www.bricsnet.com/) also have enterprise/hosted project-collaboration architectures, but attempt to reach out to their architect-engineer (A/E) constituency by integrating their collaborative software architecture into broader, design-centric solutions that support a fuller cross-section of A/E behavior (rather than just construction administration). Edgewater Service's ProjectEdge (http://www.projectedge.com/) has quietly built a following by targeting its project-collaboration architecture toward users whose behavior likely includes integration with sibling product FacilityEdge.

Others have differentiated themselves by inching away from the pure PSWS, enterprise/hosted model. Constructw@re (http://www.constructware.com/) was among the first to offer a single-login architecture across multiple projects and a pricing structure per user for unlimited projects (rather than the typical post-and-host, per-project pricing). This architecture more accurately reflects the behavior of AEC project participants. Recently, ProjectVillage (http://www.projectvillage.com/), a spin-off of Bostleman Corp., a privately-held, $90-million construction company, announced a new project-collaboration architecture that even more closely models the real-world behavior of AEC participants. To quote ProjectVillage's announcement, "the application is built on the patent pending Enterprise Community architecture in which any organization, having its own account in the application, can share project information with other organizations that have their own accounts. Using this model, each organization can have and control its own information on each project it works on, while still collaborating with other organizations from within its own account."

Effectively, ProjectVillage's Enterprise Community accomplishes the paradoxical feat of hosting peer-to-peer (P2P) behavior, as shown in Figure 3. It's a profound achievement and a significant advance toward matching software logic to user behavior in AEC collaboration. But, does it go far enough? Or, does ProjectVillage portend a shift to a true P2P architecture, one that would be even more ideally suited at the code level to AEC's many-to-many behavior? Will existing P2P file-sharing architectures, such as Ray Ozzie's Groove (http://www.groove.net/) or Charlie White's eZ (http://www.ezmeeting.com/), be extensible into true AEC collaboration? Or, will new-from-the-ground-up collaborative tools emerge for AEC P2P? Time will tell, but the signs are clear that those who succeed in the long run will be those who understand the interplay of software code and user behavior.

CADENCE Contributing Editor Jerry Laiserin, FAIA, provides strategic consulting services to AEC businesses and their technology providers. He also is a contributing editor to and monthly columnist for Architectural Record and a frequent contributor to many other AEC and technology publications. Reach him at jerry@laiserin.com.