2 6 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 7 / $ 2 5 . 0 0 © 2 0 0 7 I E E E

on architectureE 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

The comparison between building archi-tecture and software architecture is wellworn and perhaps even a bit tired, sobear with me for a few paragraphswhile I try to tease out a few more use-ful observations.

Architecting in real lifeI’ve had the privilege of designing and build-

ing my last two homes. The experience gave mea deep appreciation for the var-ious roles and the intricatedance among my project man-ager, architect, structural engi-neer, and different tradesper-sons. Those of you who haveheard me lecture or who haveread my blog (www.booch.com/architecture/blog.jsp) might re-call my stories of some of the in-tentional complexity therein—

manifested, for example, in there being a fewmiles of CAT5 wire in the walls (but with the sideeffect that, in the initial deployment, my doorbellwould crash occasionally, requiring me to rebootthe home from time to time).

For my current home, the visioning processtook several months and involved looking atraw land, studying numerous examples of ex-isting homes (both in books and in the wild),and sketching rough ideas. Over time, I se-lected a lot (along a lake), chose a building style(French country), and began to see my rawsketches transformed into floor plans. Whilemy architect drew the floor plans formally (andby hand, I might add, but that’s another story),I simultaneously modeled the entire building ina 3D program so that I could walk through theplans and reason about living there.

I can’t understate the importance of that

reasoning process. By modeling the homesaround me, I was able to shift windows andmove walls so that—with one or two well-placed trees—I wouldn’t be able to see anyneighbors from inside the house. It may soundterribly geeky, but I also applied use cases todrive and to validate my design. By consideringseveral classes of scenarios (working, entertain-ing, cooking, and so forth), I was able to walkthrough the home before the foundations werelaid to ensure that the home “lived” and thatdetails such as the placement of light switchesand other utilities were well reasoned. One ex-pects change orders during a complex projectsuch as this, but one also wants to avoid scrapand rework, which can be minimized by earlyarchitectural analysis and trade-off.

Over time, those sketches, floor plans, andmodels became stable, making it possible tomove on to derivative views such as elevations,HVAC, power, lighting, plumbing, and net-work. Each view added new layers of detailsand forced modest adjustments to the coreplan, and each view was rendered in its ownway, according to the needs of the specializedstakeholders. Although the basic floor plansconstrained each of these derivative views,each view also had degrees of freedom for in-novation, with the overall architectural stylepresent to preserve intellectual integrity.

Once these plans were signed off, detailedstructural planning could proceed. In thisphase, my codesign of the 3D models in paral-lel with my architect’s traditional plans provedto be a useful check-and-balance. I would up-date my models from the formal plans, and inturn I’d feed back modifications to the archi-tect. Quickly I discovered in my models thatthe structural engineering had erred in onespecific place, where the entryway’s ceiling en-

Artifacts and ProcessGrady Booch

croached on the floor of the bedroomabove. After pointing this out to a veryembarrassed engineer, necessary changeswere made even before breakingground.

Once the ground was broken andthe home erected, these blueprints werethe primary guide to construction foreach trade. Of course, these blueprintsweren’t, by their very nature, compre-hensive. Each tradesperson proceededon the basis of standard industry prac-tice, so details such as switch height orstair tread size were givens, except in afew places where specific design con-straints applied. In the end, after thehome was completed, the blueprints re-mained—updated along the way as tothe essential design changes, to guidefuture modification to the home.

Observations for softwarearchitecture

We can conclude from this processseveral things that are germane to soft-ware architecture.

First, the building/software architec-ture analogy falls apart at significantpoints. In building a home, you canmake general cost estimates on the basisof historical cost-per-square-foot valuesin the area, and you can make preciseestimates when the plans are beingsigned off (in my case, we were on bud-get and only slightly over schedule). Insoftware, cost estimation is extremelyimmature, and we can get more accu-rate estimates only with each iteration.In building, there’s an obvious inertiabecause we’re dealing with physical ob-jects; software, on the other hand, is farmore fluid, although change incurs verytangible costs.

Second, there are areas of modestcongruence between the two. For ex-ample, building involves professionaldivisions of labor, institutionalized bylicensing practices. In software, somedivision of skills exists, manifested pri-marily by different degrees of specificknowledge—but for the most part,programmers bring to the table a wideset of skills. Additionally, the degreesof formality and informality are simi-lar, although building tends to skew to-ward formality in its blueprints and in-

formality in construction, whereas insoftware you’ll find only pockets offormality but systemic informality inconstruction.

Third, building and software havesome essential commonalities.

■ Views are important. In both do-mains, no one view is sufficient tofully express an architecture. Fur-thermore, some views are primary,while others are derivative. Also, inboth domains, it’s important to real-ize that the system’s architecture isthe primary artifact (in addition tothe manifest system itself, of course)and that creating each view isn’t anend unto itself but rather a journeythat contributes to the architecture’sspecification.

■ Use cases really do work in both dri-ving the process and validating thedesign. Reasoning about a system’sarchitecture is an important exerciseearly in the life cycle—otherwise,considerable scrap and rework willresult.

■ The design process for both build-ings and software is inherently in-cremental and iterative. Historicalprecedence helps to accelerate both(and you’ll find design patterns inboth), but for novel systems, thereal process is cyclic.

■ Style is an essential metadesign deci-sion. Choosing a particular style is

generative, in that it naturally leadsto a common succession of subse-quent design decisions. Adhering tothat style throughout the process isessential to maintaining intellectualintegrity and, in the end, a sense ofbeauty and simplicity.

■ At some point, you cross a thresh-old from architecture to design. Be-yond that point, architectural deci-sions are increasingly expensive tochange, yet at the same time, theyprovide necessary guidance to theconcerns of detailed design.

■ In the end, the finished product—theactual building, the raw, naked run-ning software—is the ultimate truth.However, it’s not the whole truth.Design patterns and rationale can besometimes be inferred from the fin-ished product, but for the most part,these things remain in tribal mem-ory, which tends to fade over time.So, it’s important to preserve some—but not all—of the essential archi-tectural artifacts, without which it’scostly, if not impossible, to integrate,modify, understand, and adapt theinstantiated product.

O ne final observation comes to mind:the software industry has a longway to go to achieve the building

industry’s level of predictability, relia-bility, and quality. Granted, software islargely a phenomenon of this genera-tion and building has its roots overmillennia, but that’s not a meaningfulexcuse, just an observed reality. Ourdomain—software—is hyperdriven byneeds for innovation, and that oftenhappens at the expense of these funda-mental “-ilities.”

Grady Booch is an IBM Fellow and one of the UML’s orig-inal authors. He also developed the Booch method of softwaredevelopment (Object-Oriented Analysis and Design, Addison-Wesley, 1993). He’s working on a handbook of architecturalpatterns, available at www.booch.com/architecture. Contact himat architecture@booch.com.

N o v e m b e r / D e c e m b e r 2 0 0 7 I E E E S O F T W A R E 2 7

ON ARCHITECTURE

In software, cost estimation

is extremely immature,and we can get more

accurate estimates onlywith each iteration.

ON ARCHITECTURE