0 7 4 0 - 7 4 5 9 / 0 6 / $ 2 0 . 0 0 © 2 0 0 6 I E E E M a y / J u n e 2 0 0 6 I E E E S O F T W A R E 9

on architecture

Every interesting software-intensive sys-tem has an architecture. While some ofthese architectures are intentional, mostappear to be accidental.

Since accidental is an emotionally ex-plosive word, let’s tease apart the ele-

ments of my statement. First, the terms inter-esting and software-intensive. For my purposes,an interesting system is one that has significant

economic value; a software-intensive system is one that in-volves some degree of soft-ware/hardware interplay, suchas that found not only in largedistributed systems but also insmaller embedded systems oreven captive uniprocessor ormulticore systems. Second,the term architecture itself.Here, I’m not so much con-

cerned about the definition (the terminology inIEEE Standard 1471 is quite sufficient for myneeds) but rather the naming of particular ar-chitectural patterns. I’ll say more about thislater, but the fact that we cannot yet meaning-fully enumerate a comprehensive set of archi-tectural patterns or styles across domains is agap in our understanding of software archi-tecture. (Filling that gap is one desired out-come of my Handbook project.) Finally, theterms intentional and accidental. An intentionalarchitecture is explicitly identified and then im-plemented; an accidental architecture emergesfrom the multitude of individual design deci-

sions that occur during development, only afterwhich can we name that architecture.

Philippe Kruchten has observed that “thelife of a software architect is a long and rapidsuccession of suboptimal design decisionstaken partly in the dark.” The journey be-tween vision and ultimate executable systemis complex. For every interesting software-intensive system, that path is marked by myr-iad decisions, some large and some small,some of which advance progress while othersrepresent vestigial dead ends or trigger pointsfor scrap and rework. As Philippe also ob-serves, the architecture of classical systemscomes primarily from theft, whereas the archi-tecture of unprecedented systems comeslargely from intuition carried out in the con-text of a controlled exploratory process. Thefact that this is so for software-intensive sys-tems shouldn’t come as a surprise, for as HenryPetroski explains in his book To Engineer IsHuman (Vintage, 1992), all sound engineeringdisciplines advance by building on past suc-cesses while simultaneously mitigating causesof observable failure.

Thus, having an accidental architecture isnot necessarily a bad thing, as long as

■ the decisions that make up that architectureare made manifest and

■ the essential ones are made visible as soonas they are instituted and then are allowedto remain visible throughout the meaning-ful life of that system.

The Accidental Architecture

Grady Booch

E d i t o r : G r a d y B o o c h ■ I B M ■ a r c h i t e c t u r e @ b o o c h . c o m

1 0 I E E E S O F T W A R E w w w. c o m p u t e r. o r g / s o f t w a r e

ON ARCHITECTURE

Insofar as we can then name these ar-chitectures after they’re formed, we canuse these names and their associatedsemantics to communicate decisionsusing a common language, just as wecan do now with design patterns, andperhaps even reuse these architecturalpatterns in future systems. In otherwords, by naming these accidental ar-chitectures, we again raise the level ofabstraction by which we can describeand reason about a system.

Architectural patternsIn her book The Grammar of Architec-

ture (Bulfinch, 2002), Emily Cole enumer-ates a set of 18 distinct architecturalstyles in civil engineering, ranging fromBabylonian to Grecian and Islamic toBaroque, then on to Neoclassical and Pic-turesque. Her set isn’t exactly complete orof suitable granularity—one could arguethat Victorian, Craftsman, or evenGehrian are equally valid styles—but thefact that such things are even nameablereflects that field’s maturity.

Gehrian? Well, therein lies a conun-drum. The contemporary architect FrankGehry, just like Daniel Libeskind, I.M.Pei, and many others, has a uniquelyidentifiable style that we don’t quiteknow how to classify and thus name. In-deed, if you consider all the styles fromCole’s book, you’ll realize we can namethem and distinguish one from anotheronly because of the distance of time,having had the opportunity to reflectback on numerous instances of specificarchitectures and harvest their reoccur-ring patterns. The problem of namingsoftware architectural patterns, there-fore, is that we don’t have a similarluxury of time or of as many identifi-able reoccurring instances from whichto harvest.

As part of my software archeologi-cal digs, I collect of lot of metadata, in-cluding the history of the system understudy. In every case (taking into ac-count that my work is self-selecting, forI’m only studying successful systems),I’ve uncovered a steady growth of archi-tectural maturity within each domain.This maturity is represented by whatevolutionists would call a punctuatedrhythm consisting of architectural dis-

covery, architectural stability, architec-tural collapse, and then a repeated cycleinitiated by a harvesting of architecturalpatterns that survived the collapse. Inother words, accidental architecturesemerge but then become intentionalonly after they’ve proven themselvesthrough time.

Web-centric architecturalpatterns

As an example, every contemporarydot-com system I’ve studied—particu-larly those that survived the near-deathexperience of the late 1990s dot-bombera—have gone through several distinctarchitectural periods, periods that trackthe history of the Web itself. Many oth-ers have documented the Web’s social,economic, and business history (andwriting a history of something that’sonly 38 years old is disturbing enough,given that I’m only 614 months old my-self), so I’ve taken a stab at naming thevarious technical generations of Web-centric systems.

In the beginning, simple documentsdominated the Web. You can easilyidentify sites of this era: they were styl-istically distinct, consisting primarily ofmodestly formatted text, basic hyper-links, and a few crudely placed staticgraphics, reflecting the simplicity of theHTML standards of the time. In thenext identifiable movement, we saw therise of colorful clients. The first genera-tion of Web-centric systems had suffi-

cient value that they attracted graphicdesigners (many from the print media)as well as serious developers. However,many of the designers who could buildattractive sites couldn’t create goodsoftware, and many of the developerswho could build great software couldn’tcreate approachable user experiences. Inthis generation, we saw the rise of eyecandy (and the now-amusing but thethen-ever-annoying HTML <blink>tag) but also more precise formattingand more engaging content.

It took a period of time coupledwith natural market forces, but bestpractices began to emerge that yieldeda balance of power between the stake-holders responsible for presentation andinfrastructure. This led to a third gener-ation focused on simple scripting. Therise of scripting languages began, andthus Perl, PHP, and others started totake hold. In this generation, we sawthe first great schism surrounding thetheology of dynamic HTML, with Mi-crosoft’s Active Server Pages on oneside and, well, not Microsoft (includ-ing Java Server Pages) on the other.

Consistent with this model of punc-tuated equilibrium, the fourth genera-tion was best identified by the rise ofmiddleware, which continued the previ-ous schism (leading to Microsoft’s .NETand the alternative products supportingJ2EE) and which represented the codifi-cation of many of the mechanisms com-monly found in such systems.

In the fifth generation, the focus ofinnovation turned back again to theclient layer above this middleware.With by-then-considerable experiencein scripting languages and with the still-oscillating pendulum swinging betweenpure Web thin clients and traditionalthick clients, the mark of this genera-tion was the rise of simple frameworks(such as Struts). These served to codifybest practices at the client layer, such asreflected in the Model-View-Controllerpattern.

And here we areIn the sixth (and contemporary) gen-

eration, an interesting bifurcation hastaken place. On the edges of Web-centricsystems are considerable demand pull

Accidental architectures emerge

but then becomeintentional only

after they’ve proventhemselves

through time.

M a y / J u n e 2 0 0 6 I E E E S O F T W A R E 1 1

ON ARCHITECTURE

and technology push toward rich clients,so technologies such as Ajax have gainedtraction. At the core of Web-centric sys-tems, service-oriented architectures havetaken hold because they provide a solu-tion to the problem of building systemsof systems. This is particularly true whensome (but not necessarily all) of thosesystems are already wrapped up in thecollateral implications of their Webifica-tion (namely, investment in the infra-structure elements of security, universalaccessibility, and transparent location).

Were you to take a snapshot of aninteresting Web-centric system duringany one of these generations, you’d finda distinctly unique architectural style atplay. Each generation was complex inits time, but the technology available atthat time shaped the accidental archi-tectures that emerged. Only now—inreflection of that time—can we begin toattempt to name and thus make inten-tional these architectural patterns.

A final point I need to make is that,depending on where you’re looking,one person’s system is another’s subsys-tem. Thus, you might see the use of in-tentional architectures at some levels(only because we know how to buildthem and have built them before) but

then accidental on others (because we’restriking out on new ground or are as-sembling systems of systems in novel,heretofore untried ways).

A ccidental architectures are not evilthings; indeed, they are inevitable inthe growth of systems. It’s only when

we begin to turn these accidental archi-

tectures into intentional ones that weadvance our understanding of softwarearchitecture.

Grady Booch is an IBM Fellow. He’s one of the UnifiedModeling Language’s original authors. He also developed the Booch method of software development, which he pre-sents in Object Oriented Analysis and Design. Contact him at architecture@booch.com.

www.computer.org/software

UPCOMING ISSUES:Software Testing

Global Software DevelopmentSoftware Engineering

Curriculum Development

VISIT US AT