Tag: patterns

Talking with Duncan Wilson about architecture in the age of networked services

~ Jon Udell ~ 1 Comment

My guest for this week’s Innovators show is Duncan Wilson, an engineer with the global consulting firm Arup. We met at the 2010 Microsoft Research Social Computing Symposium, where the theme was city as platform. His presentation, and our follow-on conversation, prompted me to read a couple of books that had long been in my queue: Stewart Brand’s How Buildings Learn and Christopher Alexander’s A Pattern Language.

Reading both of those books, I felt an implicit connection between principles that I’ve learned in an IT context (e.g., separation of concerns, networks of loosely-coupled services), and principles that can inform the practice of architecture — at the scale of buildings, but also of whole cities. Duncan Wilson, and others lucky enough to be working at the forefront of 21st-century architecture, are making that connection explicit.

Consider, for example, the movement of goods in and out of a city. You’d like to consolidate that activity at the perimeter and reduce truck traffic in the core. That’s doable, but only if retailers and suppliers are willing to share information about what they’re shipping. That began to happen in the late 1990s, Duncan says, when retailers and suppliers began to share trucks. Doing the same kind of thing for a city, as Arup’s engineers envision, would entail both a physical arrangement of consolidation centers on the perimeter, and a virtual arrangement of shared data.

Information, Duncan says, is becoming another of the raw materials from which the built environment is made.

Here’s a different example of IT principles crossing over into other realms, from a podcast I listened to on yesterday’s hike:

When you offer multiple services using the same devices, through the same interfaces, you open up opportunities for creative thinking in the storage community.

If you’re talking about data storage, and the frame of reference is IT, that’s not a very compelling statement. We haven’t fully internalized this service-oriented and network-based way of thinking, but we’re getting there.

But that quote doesn’t refer to data storage, it refers to energy storage. The podcast was Stephen Lacey’s excellent Inside Renewable Energy. In this episode, innovators at Ice Energy and A123 describe business models that are deeply informed by the idea of networks of shared services.

Uses of pattern language in the urban century

~ Jon Udell ~ 11 Comments

I’ve long been familiar with the idea of software patterns. But I didn’t connect it to its roots in the architectural writings of Christopher Alexander until I recently listened to Kent Beck’s keynote at the 2008 Rails conference. Kent was deeply influenced by The Timeless Way of Building. That book wasn’t available in my local library. But the companion volume, A Pattern Language: Towns, Buildings, Construction, was. It’s been a revelation to read it for the first time, more than thirty years after it was published, through lenses formed by my experience with software and networks.

Here’s how A Pattern Language summarizes a pattern called FOUR-STORY LIMIT:

Therefore, in any urban area, no matter how dense, keep the majority of buildings four stories high or less.

And here’s how the Portland Pattern Repository summarizes the Singleton Pattern:

Therefore, let the class create and manage the single instance of itself, the Singleton. Wherever in the system you need access to this single instance, query the class.

The stylistic allusion shows a direct literary influence flowing from architectural pattern language to software pattern language. Alexander’s book, by the way, is a pre-Web hypertext. The pattern called FOUR-STORY LIMIT (21), for example, refers to NUMBER OF STORIES (96), DENSITY RINGS (29), BUILDING COMPLEX (95), HOUSING HILL (39), and HIGH PLACES (62). Each of these numbered patterns links to a set of related patterns, as does each page in the Portland Pattern Repository — which was also, of course, the Ur-wiki from which all things wiki are descended.

I suspect we’ve yet to fully elaborate the connections between software, architecture, and networks. Consider these pattern names from Alexander’s 1977 book:

THE DISTRIBUTION OF TOWNS
WEB OF PUBLIC TRANSPORTATION
NETWORK OF LEARNING
WEB OF SHOPPING
ACTIVITY NODES
NECKLACE OF COMMUNITY PROJECTS
CONNECTED PLAY
NETWORK OF PATHS AND CARS
CIRCULATION REALMS

These evocative names, and the sketches that accompany them, arise from a deeply network-oriented way of thinking. Many of the higher-level patterns express core values about connectivity and decentralization. And those values resonate more powerfully now, in our Net-aware world of 2010, than they might have in 1977.

Some of the prescriptions in A Pattern Language can seem absurd. For example, Alexander argues that an optimal urban core should serve a “catch basin” of about 300,000 people, that these cores should be widely distributed, and that each should specialize in some way that makes it world-class. Why?

The problem is clear. On the one hand people will only expend so much effort to get goods and services and attend cultural events, even the very best ones. On the other hand, real variety and choice can only occur where there is concentrated, centralized activity; and when the concentration and centralization becomes too great, then people are no longer willing to take the time to go to it.

Which is fine in theory, but we’ve already built megalopolises surrounded by suburbs. It’s not like we can do it over.

Except when we can. In America the most striking examples are in Michigan where I lived for many years. Detroit, once a city of two million, is being recreated as a city that may end up at less than a third that size. What will become of the rest? It just might be plowed into farmland. If so, a pattern called CITY COUNTRY FINGERS may turn out to be a useful guide.

Likewise there are plans afoot to gather the remaining population of Flint into a few viable neighborhoods and let the vacated land become parks and forests. If that happens, many of the ideas in A Pattern Language, about how to organize neighborhoods and their transportation networks, could come into play.

In Asia, meanwhile, entire new cities are being built from scratch. I recently met an engineer who works for the global consulting firm Arup. For one of their projects, he told me they’re using a simulation of wind flow as one of the constraints on the layout of streets and buildings. The layout is also informed by RING ROADS and LOCAL TRANSPORT AREAS, patterns that yield a tiered distribution network which optimizes the use of delivery trucks.

Networked software is highly malleable, and we take for granted that we can try out different design patterns. The built environment rarely affords the same opportunity. But in this century of urbanization, as circumstances force us to rethink our energy, transportation, and settlement networks, it may turn out to be softer than we suppose, and more open to the influence of pattern languages.