In-Depth

Improving Systems: Forget Architecture -- Look at the Buildings

If successful buildings can learn and improve, shouldn’t the same be possible for systems?

• By Jim McGee
• 02/15/2005

Analogies between large-scale systems development and conventional architecture have been around since the dawn of systems development. These analogies emerged from similarities between systems development methods and the layers of progressively more-detailed design documentation (from early sketches to blueprints that characterize large scale construction).

There is an important flaw in these analogies, however, that exists in both worlds--buildings and systems. Focusing on the process of getting the initial building or system built, each ignores the relation between design and the end product in use.

Ten years ago, Stewart Brand, creator of the Whole Earth Catalog and founder of the Global Business Network, asked a provocative question--how did buildings learn over time? Were there some aspects of design or construction that led to buildings with long and fruitful lives? Both Brand's questions—and his answers—hold lessons for enterprise systems.

Brand's first and most fundamental question: what made a building good to live in? There is a curious paradox about buildings that also applies to systems. Buildings are designed with the expectation that they will not change, yet their useful life stretches beyond the needs that brought them into being. Fundamentally, what determines whether a building works are the people inside. They ignore the furniture police and the cubicle cops and do what's necessary to get the job done.

Brand found two answers to his question. Buildings that are highly adaptable to new occupants and new uses succeed. At the opposite extreme, buildings carefully matched to a single purpose—think Wrigley Field or Fenway Park—also thrive.

Adaptability generally implies simplicity and transparency. Users create necessary complexity in how they go about using simple structures. The more visible and transparent those structures are, the more easily users can understand and adapt them to their evolving needs.

A second set of questions Brand raised address the interplay between architects, owners, and occupants. For many buildings, and systems, this distinction doesn’t exist. Owner, occupant, and architect are one and the same. In the case of buildings, Brand argues that this often leads to buildings whose future owner/occupants find them as adaptable and successful as their creators.

As buildings and systems become more complex, however, these roles become more specialized and separate. Alan Kay, inventor of SmallTalk and now a Fellow at Hewlett Packard, argues that as complexity increases, design comes to dominate materials. You can build a dog house out of whatever scrap lumber is lying around. A stick-built house needs basic blueprints and a skyscraper needs blueprints, engineering analysis, and structural steel. Specialization is essential and design becomes the necessary skill for integrating all the specialty inputs into a single, coherent result.

Two sets of problems arise from this complexity. The first is understanding and addressing the inevitable conflicts among the key roles of architect, owner, builder, and user. The second revolves around reconciling design with evolution and learning.

The most pertinent issue of role conflicts, for both buildings and systems, is that those who foot the bill tend to be more enamored of how things look on Day 1 than with how livable things are once the architects and builders are gone. We’ve all seen buildings that make excellent sculptures yet remain essentially unlivable. We’ve also seen too many systems that demo but essentially can't be implemented.. In either case, the most effective antidote is to ensure that there is real conversation between the designer and the actual users.

Assuming that the parties involved commit to the necessary dialog between the right participants, we are still left with the challenge of making that dialog a productive one. That depends on understanding how to better bridge from design to evolution and learning.

One characteristic of both architects and systems designers, not shared by ordinary users, is the ability to imagine spaces that do not yet exist. This makes it difficult for them to empathize with the typical user who operates in a much more concrete world. The challenge is helping people do their imagining in more effective ways, without taking them through the same years of training and experience. For designers, the solution is to "go native" and spend substantial time living in the operational world of the users to develop the necessary empathy.

From the user perspective, one particularly useful "imagining" tool is the use of scenarios. They create a more concrete way for users to experience and articulate how living in a new building/system will feel. Here, Brand offers an intriguing piece of advice that “scenarios shine because it is their job to seek out and celebrate future perversity.”

With better data in hand, designers can then focus on a delivering a new system that is not the end point in the design process so much as it is a good starting point for the inevitable learning process that will follow.