1 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 6 / $ 2 0 . 0 0 © 2 0 0 6 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

For centuries, Ptolemaic theory reflectedcivilization’s understanding of the earthand its place in the universe. To the pre-scientific mind, this geocentric view-point was just common sense: it wasconsistent with local observations and

generated no dissonance with contemporaryreligious beliefs.

Unfortunately, Ptolemy’s theory and most ofthe conclusions drawn from it were false.

It wasn’t until the early 1500s that Copernicusrediscovered the reality of the earth turning on its

axis daily and orbiting aroundthe sun yearly, observations hepublished in De RevolutionibusOrbium Coelestium in 1543.Galileo’s unabashed acceptanceof Copernican theory landedhim in trouble but, fortunatelyfor us, hard scientific evidencetends to prevail. Later that cen-tury, the gentleman-scientist Ty-cho Brahe assembled a detailed,

precise, and comprehensive catalog of the mo-tion of more than 1,000 stars and planets. AfterBrahe’s death, Johann Kepler studied this dataand then formulated his three laws of planetarymotion, which he explained in Astronomia Novaand Harmonices Mundi.

This story’s lesson is that classical scienceadvances via the marvelous dance betweenquantitative observation and theoretical con-struction, and, in turn, the engineering disci-plines apply those advances to creating newthings. In stark contrast to the classical sci-ences, software engineering and its subdisci-pline of software architecture are still in theirinfancy relative to observation and theory.

Software architecture’s growthTen years ago, IEEE Software celebrated

software architecture as an identifiable disci-pline, and the first International Software Ar-chitecture Workshop was held. Since then, thenumber of people who call themselves soft-ware architects has steadily increased (al-though few agree on what “software archi-tect” means or what skills and activities itentails). Similarly, organizations have increas-ingly placed value on treating a system’s soft-ware architecture as an artifact that they cancreate, grow, measure, and manage.

An engineering discipline shows signs ofmaturity when we can name, study, and applythe patterns relevant to that domain. In civilengineering, we can study the fundamental el-ements of architecture in works that exposeand compare common architectural styles.Similarly, in chemical engineering, mechanicalengineering, electrical engineering, and noweven genomic engineering, libraries of com-mon patterns have proven useful in practice.

Unfortunately, no such architectural refer-ence yet exists for software-intensive systems.Although the patterns community has pio-neered the vocabulary of design patternsthrough the work of the Hillside Group (http://hillside.net) and the Gang of Four (Design Pat-terns, Addison-Wesley, 1995), our industry hasno parallel to more mature design disciplines’handbooks (see the “Other Disciplines’ Hand-books” sidebar for some examples).

A handbook of software architectureFor the past two years, I’ve been working to

create a handbook of software architecture(www.booch.com/architecture). I don’t expect

On ArchitectureGrady Booch

M a r c h / A p r i l 2 0 0 6 I E E E S O F T W A R E 1 7

ON ARCHITECTURE

to complete a critical mass of this workfor another two to three years, simplybecause I’m collecting a broad set ofdata that’s largely locked up in certaindevelopers’ heads and in internal docu-ments that were rarely intended to seethe light of day. In this ongoing col-umn, I’ll share some of my experiencesas I continue my research.

The handbook’s primary goal is tofill this empirical void in software engi-neering by codifying the architecture of100 interesting software-intensive sys-tems, presenting them in a manner thatexposes their essential patterns and per-mits comparisons across domains andarchitectural styles. Second, the projectaims to study these architectural pat-terns in the context of the engineeringforces that shaped them in order to ex-pose a set of proven architectural pat-terns that developers can use to con-struct new systems or reason aboutlegacy ones. The third goal of this re-search is selfish—namely, to feed my in-satiable curiosity. Whenever I encounteran interesting or useful software-inten-sive system, I ask myself, how did theydo that? By studying their architecturalpatterns and thus exposing these sys-tems’ inner beauty, I hope to inspire de-velopers who want to build on the ex-perience of other well-engineeredsystems.

My motivation for this work comesfrom Bruce Anderson, who over adecade ago conducted a series of work-shops at OOPSLA (ACM SIGPLAN Inter-national Conference on Object-OrientedProgramming, Systems, Languages, andApplications) to create The CompleteHandbook of Object-Oriented Soft-ware Architecture & Designs in 1991.Since that time, the patterns commu-nity has grown quite vibrant, but mostof its work has focused on design pat-terns. As such, around three years ago,I began sketching out an approach tocontinue Bruce’s work, starting with abroad industry survey.

Software-intensive systems writtenseveral decades ago were complex intheir own time; the systems we buildtoday are equally complex. As intri-cacy has risen over the years, each newgeneration of developers has found

new ways to attack it. The nearly onetrillion lines of code created over thedecades provide a humbling reminderof our industry’s breadth, depth, andreach; this body of work is so large thatidentifying a representative set of inter-esting systems for architectural study isdifficult. Far more interesting systemsare worthy of study than any one per-son could cover in a lifetime.

One way to prune the problem is toconsider only contemporary systems,systems in production use at the timeof investigation. Thus, I decided toleave the study of classic software foranother project. (The Computer His-tory Museum is engaged in a major ef-fort to preserve a number of classicsoftware systems’ artifacts; www.com-puterhistory.org.) This still leaves anenormous number of systems to con-

sider, but I further pruned the problemby selecting a set of interesting systemsbalanced across different genres—specifically, artificial intelligence, com-mercial nonprofit, communications,content authoring, devices, entertain-ment and sports, financial, games, gov-ernment, industrial, legal, medical, mil-itary, operating systems, platforms,scientific, tools, transportation, andutilities.

Selecting specific systems was an-other problem, one that was guided bymy desire to present a set of interestingpatterns. What you might consider in-teresting is subjective, but only a fewunique architectural patterns appear toexist. For example, the basics of ac-counting have become reasonably sta-ble over the centuries, and althoughevery enterprise has its own set ofschemas, rules, and policies, the archi-tecture of such systems is remarkablysimilar. So, I’d like to present widelydiffering architectures across domains.Although practitioners in any given do-main might consider their architecturesobvious, few outside that domainwould find them obvious at all.

Selecting the final systems for studywithin each genre still required a some-what arbitrary and capricious decisionprocess. When faced with a family ofsystems with a common architecture, Iselected the one whose assets weremore easily available. In a few cases, Imade a specific selection simply be-cause of the beauty of its architecture orbecause it was the seminal exemplar ofits domain. Finally, I’ve intentionallybalanced my selection globally: clearly,software innovation isn’t constrainedby political or geographical boundaries.

By exposing thesesystems’ inner beauty,

I hope to inspiredevelopers who want

to build on the experience of other

well-engineeredsystems.

Other Disciplines’ Handbooks

■ Building Embedded Linux Systems, by Karim Yaghmour, O’Reilly, 2003■ The Elements of Style: A Practical Encyclopedia of Interior Architectural

Details from 1485 to the Present, Simon and Schuster, 1997■ The Phaidon Atlas of Contemporary World Architecture, Phaidon Press, 2004■ Perry’s Chemical Engineers’ Handbook, McGraw Hill, 1997■ Mechanism and Mechanical Devices Sourcebook, McGraw-Hill, 2001■ Electrical Engineers’ Handbook, McGraw-Hill, 1996

1 8 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

To frame my research and my datacollection, I’ve chosen to build onIEEE Standard 1471, RecommendedPractice for Architectural Descriptionof Software-Intensive Systems, alongwith Philippe Kruchten’s work (“The4+1 View Model of Architecture,”IEEE Software, Nov. 1995). Essen-tially, the data set for each system un-der study is one instance of the IEEEmetamodel augmented in three ways:by including information about

■ the environment in which the sys-tem lives;

■ the development team, tools, andprocesses; and

■ a specific set of views.

T he handbook is a work in progress.In some ways, there’s no end be-cause new systems worthy of study

constantly emerge. As I said earlier, Iplan to force closure to the present ef-fort in two to three years.

Perhaps the most fascinating ele-ment of this research is that I’m ex-pecting the unexpected: it’s too early todraw conclusions about the common-ality of patterns that I might findacross such a wide set of domains. Ihope you’ll enjoy encountering the un-expected in my future columns.

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

EDITORIALCALENDAR

JANUARY/FEBRUARYAspect-Oriented Programming

MARCH/APRILPast, Present, and Future of Software Architecture

MAY/JUNERequirements Engineering

Update: Best Papers of IEEE RE ‘05

JULY/AUGUSTSoftware Testing

SEPTEMBER/OCTOBERGlobal Software Development

NOVEMBER/DECEMBERSoftware Engineering

Curriculum Development

2006

www.computer.org/softwareVISIT US AT