CHAPTER 7

Architecture with a Capital “A”

Technologies get obsolete within 1 year, applications are replaced in 10 years, but the strong visions would survive more than 100 years.

—HIROSHI ISHII

Throughout this book we have invoked the notion of Architecture with a capital “A”; the idea being that, unlike architecture, which refers to the design and construction of buildings, Architecture refers to the organizational principles of a collection of objects, a concept or a system, which give it a basis for order, structure, change, or growth (Figure 7.1). Architecture, in this sense, is one of the essential qualities of design on Trillions Mountain. For a film on Architecture, see http://trillions.maya.com/Architecture.

Figure 7.1 “What makes a cup a cup?” Even a basic object like a cup has an underlying architecture that defines its “cupness.”

ARCHITECTURE AS ORGANIC PRINCIPLES

Frank Lloyd Wright labeled his philosophy “organic architecture,” which has been described as an attempt to be “more natural than nature itself.” What could such a boast possibly mean? Many people assume that Wright’s choice of the term organic was meant to imply an imitation of, or at least compatibility with the natural world—hills, trees, animals. Such an interpretation misses the point. Wright believed that his work reflected not idiosyncratic genius, but a genius based on an understanding of deep principles—the very principles manifest in nature’s patterns. Amplified by human reason, such principles, he hoped, could guide the creation of a rational, humane, and deeply beautiful built world.

When Wright used the term organic architecture, he meant the discipline of designing buildings with an intrinsic integrity that stems from Architecture with a capital “A.” Buildings (or any other designed objects) that are informed by such a conception of Architecture will harmonize not only with nature but also with each other.

Implicit in this way of thinking is the supposition that these rules are discovered, not invented. They are “out there,” existing a priori waiting to be found. This is to some extent a Platonic view of reality. It is a view that is out of fashion in many circles. But we have never been able to understand the alternative. It seems obvious to us that patterns of possibility exist implicitly in the laws of nature, whether we apprehend them or not. Can it really be said that the pattern representing, say, an overhand knot did not exist until some protohuman tied the first one?1 We think not. And if not, can we really say that the overhand knot was “invented” rather than discovered? If knots are out there waiting to be discovered, are there not larger, more complex, and more abstract patterns out there as well? We think so.

ARCHITECTURE AS MODEL

One of the less obvious uses of the process of abstraction implicit in the idea of Architecture is as a means of description. Specifically, Architectural thinking permits us to create abstract models of reality that are far more powerful than more literal descriptions. Consider the difference between traditional architectural drawings of a house and a computer-assisted design (CAD) model of the same house (Figure 7.2). In the old days, an architect would draw floor plans, reflected ceiling plans, various elevations and details. Each of these drawings was intended to represent the same house, of course, but each was executed as a separate drafting task. The idea was to produce a consistent set of pictures of the house in the designer’s head, with the goal of communicating the specifics of that house to a builder. But because the pictures were all independent, their consistency was completely dependent upon the skill and attention of the draftsperson. There is nothing about such a system that guarantees that the various pictures will comprise a consistent description of a realizable object. In point of fact, no such set of drawings of any complexity are ever completely consistent. This is not fundamentally due to the hypothetical nature of the house-in-the-head; the same problem would exist if the drawings were the result of reverse-engineering an actual house. It is a fundamental problem with a view-based medium, not just with the process.

Figure 7.2 Plans as pictures versus plans as models

Now consider a representation of the same building made with a modern 3-D CAD system. This is an entirely different situation. Though one may use such a system to produce exactly the kinds of views that were formerly done by a draftsperson, those views do not themselves constitute the fundamental representation of the building. Instead they are simply renderings of something deeper: an intrinsically self-consistent model of the house completely separated from any particular view of it. The model itself is not a picture. It is abstract, and makes no assumptions about viewpoint or presentation. Each detail of the house is derivable from the model and brought into play as different views require it. No contradictions are possible, since there is only one model. And since the pictures generated by the CAD system are derived via a consistent process from a self-consistent model, they, too, are guaranteed to be consistent with each other.

But there is another difference as well: CAD models are (or at least they can be) parametric. A parametric model is factored into constants and variables. Together they form a scaffolding on which all information about the model hangs. The constants are its essence, its Architecture with a capital “A,” the boundaries of its “design space.” The parameters (variables) are adjustable. They are like knobs we can turn, and in turning them we can produce an infinite number of particular house-variations, all manifestations of the same underlying Architecture (compare this to our “snack food matrix” from Chapter 4). In doing so, we not only get lots of different houses (which may or may not be good houses), but we also achieve a much deeper understanding of our own Architectural efforts. In the end, we will have attained a much deeper and more profound thing, all the way around.

By now it should be clear that the application of this approach is not limited to the description of physical objects. We can create parameterized abstract models of computing devices, of network topologies, of user interfaces, of social networks. And most importantly, we can create such models of patterns of information. The metaphor of a parametric CAD-style model for cyberspace can help us crystallize the fog of information.

ARCHITECTURE AS “STYLE”

Yet another way to conceptualize Architecture with a capital “A” is as a matter of style—style in the sense of Gothic, or Art Deco, or Postmodern. As Walter Dorwin Teague put it, “at those historical moments when a dominant style exists . . . a single character of design gets itself expressed in whatever is made at the time, and not a chair, a teapot, a necklace or a summerhouse comes into existence except in a form which harmonizes with everything else being made at that time. . . . The scene has unity, harmony, repose, and at least one irritant is absent from the social organism.” If one were to call a furniture store and—sight unseen—order a room full of, say, Mission Style furniture, the result might not merit coverage in Architectural Digest, but it would likely hang together pretty well.

Where do styles come from? Well, they don’t come from committees, and (at least in general) they don’t come from lone engineers. Rather, they emerge as rough shared consensus among communities of practice—more specifically among communities of designers.2 This is unfamiliar territory to many technology-oriented designers, but it’s a key point of this book. When designing at the scale demanded by pervasive computing, we will inevitably be forced to abandon our dreams of perfect rigor, and, when we do, the only remaining alternative to chaos is the loose but pervasive consensual shared agenda that we refer to as deep Architecture.

Style in this deep sense is not altogether absent from the computing scene. System architects have evolved a very definite style for the building of computers themselves. The packaging of logic in functionally specialized integrated circuits (ICs); putting main memory chips on little daughter boards; the use of application programming interfaces (APIs); object-orientation; and semi-standardized data types—all of these are elements of style within the engineering community. Similarly, within the human-computer interaction (HCI) community, the WIMP (windows, icons, menus, pointing device) paradigm represents a loose, evolving but near-universal style of user interface design for desktop PCs.

There is a danger: A dominant style can cause one to accept designs without examining their consequences. The modernist esthetic in architecture gave us countless sterile, windswept urban plazas built on a scale divorced from human experience and which militate against the possibility of social life in their spaces. At its best, however, style can bring unity, harmony, and a sense of familiarity to the new. In this way, style performs the legitimate—even vital—function of facilitating environmental coherence by admitting at least the possibility that an ensemble of products—designed, manufactured, and purchased independently in a competitive market—may be assembled into a collection that will look and operate together in an efficient and pleasing manner.

Architectural thinking should be particularly attractive to business leaders because it is the one true path to genuine and sustainable innovation. The infinite combinatorial possibilities that are implicit in a generative Architecture constitute the wellspring of design potential. To a design scientist, a specific innovation is never a one-off stunt, never the result of luck or hacking, but rather the tip of an architectural iceberg. The fast followers and knock-off artists may imitate the product you ship today, but they can copy only what they see. It didn’t take long for Apple’s competitors to produce shallow knock-offs of the iPod, but they couldn’t anticipate Jobs’s plans for the coming iPhone, much less the iPad. In a sense, Jobs couldn’t see them, either. But what he could see was a path forward. He had a plan; a plan in the form of an Architecture. For practitioners of Architecture (and their clients), there’s always more where that came from, and it doesn’t require starting over from scratch; the next innovation follows naturally from adjusting the parameters of the principles already put into play.

But the trillion-node network will require the emergence of another distinct kind of style, namely a style of information architecture (IA). Lying just above systems architecture (which deals with how the computing devices themselves are built) and just below user interfaces (which is about how systems communicate with users), IA deals with the design of the information itself (Figure 7.3). The trillion-node network implies a vast, heterogeneous worldwide dataflow of information. The only commonality across its vastness is information, and it is here that we must concentrate new design effort if we are to achieve a semblance of global integrity. For a film on information see http://trillions.maya.com/Information.

Figure 7.3 An information architecture is everything you can define about a system without specifying the underlying technology or the particular user interface that will be employed. This involves thinking about the architecture of how information is interrelated, how it flows, and how it fits within the user’s world.

Figure 7.4 We often confuse information with the form it takes, but information itself has no form.

INFORMATION ARCHITECTURE

Don’t confuse information architecture with the more basic concept of Architecture with a capital “A.” IA is an application of “capital A” principles in a particular domain—the domain of information. Information architecture is the specification of abstract patterns governing the relationships among information objects. Of course, all information is itself abstract, so IA represents a second order of abstraction—patterns of patterns.

So, if the Industrial Revolution gave rise to industrial design, just so, information design is the natural outgrowth of the Information Revolution. That thought might prompt you to ask, “You can’t design information, can you? It’s immaterial; what is there to design about it?” True, information has no form. And if you think of design as only “look and feel,” then the idea of designing information makes no sense. Information doesn’t have a look and feel. You can’t see information. So what exactly would you “design” about it?

To the casual observer, design is about the skin. The design of a hardcover book means the appearance of the dust jacket. And if you exclude the jacket, you might hear, “What do you mean, the design of it? It’s a book.” But books have a great deal of design—much of it having nothing to do with appearance. When an author organizes topics into an outline, that is an act of design. The choice of voice and expository tone are design issues. None of these things are “content,” they are decisions that structure and organize the content.

But books don’t just have design; they also have Architecture. The outline and expository structure of a book are specific to that particular book; hence we call them “design.” But there are patterns that transcend the design of any single book. We structure books into chapters. We start them with prefaces and end them with epilogues. We put tables of contents in front and indexes in the back. These are decisions that float above not just the content, but also above the design. They are acts of information architecture.

These examples provide a concrete illustration of how the articulation of abstract patterns (like the idea of “chapters”) can permit us to bring coherence and familiarity to an open-ended set of books—even books that have not been written yet. But books are relatively simple things. How much more important is it to provide coherence and familiarity to the vast and burgeoning universe of data that is the Internet? If that universe still consists largely of chaotic collections of disconnected, independent data silos and safe but sterile walled gardens, it is the absence of virtually anything worthy of the name information architecture that we have to blame. If we have managed to make the web useful without such sophistication, credit is due to amazingly clever and subtle techniques of search engine design combined with virtually unlimited amounts of brute force computing power and storage. But these are stopgap measures. We can do much better, and we will. The trends that we have been exploring throughout this book will require it.

Personal Universal Controller

In 2001, with many new handheld digital devices beginning to flood the market—PDAs, MP3 players, GPS devices, and so on—we embarked on a collaborative research project with Carnegie Mellon University. The project was partially funded by a consortium of leading tech companies that included the likes of Sony and Casio. Our project was aimed at developing a general architecture for mobile devices as they begin to interact with the connected environments around them. We called the project “PUC” for Personal Universal Controller. The PUC was envisioned as a universal mobile interface through which the owner of a house or a worker in an office could communicate with and control any product that was at hand in the built environment—a phone, a CD player, a thermostat, an alarm clock, a refrigerator, a house, a copy machine, whatever.

The concept differed from the familiar “universal remote control” in a fundamental way: Rather than applying a thin veneer over the diverse user interfaces that such independently designed devices inevitably possess, the PUC took a different approach. The device implemented a complete and general user interface paradigm, and it communicated with the diverse controlled devices via an abstract, high-level protocol. Thus, for example, instead of sending manufacturer-specific “volume up” and “volume down” commands to a television set, it would send an abstract “set percentage value of a quantitative range.” Each controlled device would negotiate its requirements with the PUC when they first encounter each other, and these abstract parameters would be mapped onto the PUC’s single, uniform UI. In turn, the user can choose from among a library of UI styles and “skins” (highly realistic knobs and displays; minimalist; even, in principle, command line or Braille), and the preferred style would be used consistently for all devices. The bottom line was that the user interface decisions would be associated with the user, not with each device. Users could literally carry their UI preferences in their pockets. The relevance of this pattern to taming the chaos of the pervasive computing future is obvious.

The goal was not actual commercialization, but to provide a concrete product context that would require us to do some deep work about the Architecture of user interfaces at the intersection of information and atoms—to understand and describe data types (continuous, discrete, binary, etc.), decision sequences (to save, or autosave?), kinesthetic principles (point, push, slide, twist, etc.)—all the actions and feedback elements of user interfaces that we commonly encounter in a multitude of combinations and permutations.

We built a prototype PUC system to test what we had learned. Each device in our test environment was equipped with a wireless adaptor that could send and receive XML-coded descriptions of every way that it could be controlled and every kind of information it could provide. (In a practical implementation, such adaptors would provide a transitional technology until “PUC native” devices started to appear.)

One test was to find out if users could walk up and use never-before-seen devices, and if so, whether they could learn how to use these devices in record time. For the test we configured a PUC controller device so that it requested the control description from any PUC-aware system within wireless range and dynamically assembled a user interface to control these devices. If it found a stereo system, it dynamically laid out an interface to control it, if it found a multifunction alarm clock, it did the same. By removing the whims of a given physical or UI design from the equation, and instead developing interfaces that dynamically optimized the whole environment, we found dramatic improvements in both the time to learn a task as well as the number of errors made. In our tests, users completed tasks with many fewer errors, and in half the time.

The test consisted of timing users—who were not familiar with any of the systems in the environment—as they learned to perform tasks directly on the actual products versus doing so via the PUC. The improvement in performance with the PUC may be due in part to just good interface design. But the improvement across product types demonstrates the extra benefit an Architectural approach brings to an experience.

The concept was simple. If you always used that volume dial on the side of the PUC to turn things up or down, all devices in your environment could be turned up or down with that dial. If you always had the on/off button in the upper left corner, all systems in the physical world could be turned on or off by looking at the upper left corner of the display.

It is noteworthy that even nonvisual interfaces benefited from this approach. The CMU researchers were working on natural language processing, so they built a wireless microphone and speaker system that could query the devices within the environment using a consistent language and grammar. The potential of this technology for the improvement of interfaces for the visually impaired is clear.

Consider what happens when a user is given the ability to learn one interface paradigm and employ it across different products or applications, even if built by different manufacturers during different design eras. This approach naturally brings a measure of future proofing and customer satisfaction to diverse product lines—including future products that have not yet been conceived. But more importantly, the evolution of the interface can benefit from the community of users and evolve in the wild into something that could never have been conceived by a single manufacturer.

The power of this approach is clear, and we believe that something very much like it will prove to be in the critical path of our climb up Trillions Mountain.

PUC Testing Results: PUC usability exceeded that of the actual appliances in time to completion, help requests and missteps.

---

We should caution the reader that although we are prepared to defend our usage of the term information architecture in the specific sense that we have defined, such usage is not universal. People talk about the IA of a website or of a visualization. But such usages often refer, not to an architecture at all, but to relatively superficial (or at least case-specific) decisions concerning the stylistic features and look-and-feel characteristics of ensembles of coordinated designs. We have no quibble with this kind of design; it is productive and important. It is just that it isn’t Architecture. To be worthy of that term, a pattern must transcend a single project and a single designer. Designs belong to individual designers; Architecture belongs to communities of practice.

We earlier posed the question “How does one design an emergent property?” We are now prepared to offer an answer. It involves two steps: First, develop and perfect an architecture. Second, subject your architecture to market forces. This recipe, of course, is flippant. But it captures an essential point. Architecture and evolutionary processes are the Yin and the Yang of complexity design. We believe that this is how Nature works, and that it is the only tractable approach to designing any system whose aggregate complexity vastly exceeds the bounds of human cognition.

Information architecture transcends almost every other issue in the field. By its use, one can give information an essential structure that permits it to flow and recombine freely, much as the structure of the genetic code provides a corresponding liquidity for the information of life. Getting it right is vitally important because the result will be an incalculable increase in the value of all the world’s information as we move onto Trillions Mountain.

ARCHITECTURE AND DESIGN SCIENCE

Before we leave the topic of Architecture, we would like to make one final point. It concerns the relationship between Architecture and the idea of design science. All true sciences have two facets: the observational and the theoretical. What distinguishes science from its “natural philosophy” antecedents is less in the observational than in theoretical. Prescientific data collection was often both comprehensive and thorough. Its practitioners were prodigious producers and collectors of data. What was lacking were the techniques of abstraction and mathematical generalization that permit us to make simple statements about vast swatches of information. Isaac Newton is rightly known as the father of modern science precisely because he showed the world how a few lines of equations can capture fundamental truths with more precision and to far greater useful effect than any mere list of observational facts, no matter how voluminous or carefully collected.

If design science is going to be more than mere pretension, it must develop work products that exhibit the same powers of abstraction and generalization as do the differential equations of the physicist and the periodic table of the chemist. As we hope we have made clear, capital “A” Architecture is the medium for such generalization. It is by definition transcendent of particular instances and thus intrinsically abstractive. And generalization goes hand in hand with generativity. As we face the task of sculpting a future of unprecedented complexity, Architectural principle will sketch the outlines and market forces will fill in the innumerable details.

1 Or until some windblown vine was tied into one by chance?

2 We’re using this word broadly, to mean “creator of artificial structures,” not in the narrow senses of “graphic designer” or “industrial designer.”

3 The resemblance of these character sketches to the user “personas” frequently developed by interaction designers is not coincidental.