IEEE SOFTWARE Published by the IEEE Computer Society - PDF document

IEEE SOFTWARE ago, I saw my colleague Dave Ricestatement, ÒWe shouldnÕt interviewphrase, because we usually introduce Dave asphrenia is the fact that, even by ourindustryÕs standards, ÒarchitectÓoverloaded words. For many, theet even in firms that have thethereÕs a vital role for the technical(Addison-Wesley, 2002), everyone who re-in the title. Yet we all felt uncomfortable defin-ing the word. Because it was my book, I feltcompelled to take a stab at defining it.as a word we useto puff it up to make it sound important. (Yes,chitect.) However, as so often occurs, insidethe blighted cynicism is a pinch of truth. Un-ming mailing list. ItÕs so good IÕll quote it all. The RUP, working off the IEEE definition, definesinteracting through interfaces, those componentsbeing composed of successively smaller compo-nents and interfaces.ÓI was a reviewer on the IEEE standard that usedthat, and I argued uselessly that this was clearlya completely bogus definition. There is no high-different concept than developers. Customers donot care at all about the structure of significantcomponents. So, perhaps an architecture is thehighest level concept that developers have of asystem in its environment. LetÕs forget the devel-opers who just understand their little piece. Ar-chitecture is the highest level concept of the ex-pert developers. What makes a componentsignificant? It is significant because the expertSo, a better definition would be ÒIn most successfulsoftware projects, the expert developers workingon that project have a shared understanding of theMartin FowlerThoughtWorks IEEE SOFTWARE system design. This shared understandingincludes how the system is divided intocomponents and how the components in-teract through interfaces. These compo-components, but the architecture only in-cludes the components and interfaces thatit makes clear that architecture is a so-cial construct (well, software is too, butarchitecture is even more so) because itdoesnÕt just depend on the software, buton what part of the software is consid-ered important by group consensus.get them right than any other.Anyway, by this second definition, pro-gramming language would be part ofthe architecture for most projects. By thefirst, it wouldnÕt be.Whether something is part of the architec-ture is entirely based on whether the de-velopers think it is important. People whobuild Òenterprise applicationsÓ tend tothink that persistence is crucial. When theystart to draw their architecture, they startwith three layers. They will mention Òandwe use Oracle for our database and haveonto it.Ó But a medical imaging applica-tion might include Oracle without it beingconsidered part of the architecture. That isbecause most of the complication is in an-alyzing the images, not in storing them.Fetching and storing images is done byone little part of the application and mostSo, this makes it hard to tell people howto describe their architecture. ÒTell uswhat is important.Ó Architecture is aboutthe important stuff. Whatever that is.stuff, then the architect is the person (orpeople) who worries about the impor-Matrix Reloadedspecies of architectand the style that Dave Rice exemplifies.The architect does this because a singlemind is needed to ensure a systemÕs con-ceptual integrity, and perhaps becausethe architect doesnÕt think that the teamthose decisions. Often, such decisionsmust be made early on so that everyoneelse has a plan to follow. kind of animal (if you canÕt guess, trywww.nd.edu/~archives/latgramm.htm).aware of whatÕs going on in the project,like this, the most noticeable part of thedeveloper, trying to harvest some com-In many ways, the most importantactivity of mentor the development team, to raisedevelopment teamÕs ability gives an ar-tural bottleneck. This leads to the satis-fying rule of thumb that an architectÕsvalue is inversely proportional to theAt a recent ThoughtWorks retreat,about the issue of architects. I found itis too com-chitect,Ó and itÕs based on a flawedmetaphor (see http://martinfowler.com/bliki/BuildingArchitect.html). Mike Twothe best, like this one, have an impor-tant meaning thatÕs not immediately ob-vious. Remember JohnsonÕs secondaryin a project.Ó Why do people feel theneed to get some things right early in theproject? The answer, of course, is be-to change. So you might end up definingarchitecture as Òthings that people per-ceive as hard to change.Ó ItÕs commonly believed that if youearly on because itÕs hard to change thejects, the database administrator,martinfowler.com/articles/evodb.html). What makes acomponent significant? It is significant because the expert developers say so. IEEE SOFTWAREhttp://computer.org/software By doing this, he made it so that theconference (http://martinfowler.com/of complexity. He saw agile methods, intectÕs most important tasks is to removeHereÕs Johnson again, this time inOne of the differences between buildingare hard to change. It is hard to go backThere is no theoretical reason that any-thing is hard to change about software.If you pick any one aspect of softwarethen you can make it easy to change,but we donÕt know how to make every-thing easy to change. Making somethingeasy to change makes the overall systema little more complex, and makingeverythingeasy to change makes the en-tire system very complex. Complexity iswhat makes software hard to change.My reservation of Aspect-Oriented Pro-gramming is that we already have fairlyof programs, and we donÕt use them. IdonÕt think the real problem will beseparating aspects. We donÕt know whatshould be the aspects that need separat-ing, and we donÕt know when it is worthseparating them and when it is not.Software is not limited by physics, likeshort, it is limited by properties of peo-ple, not by properties of the world. ÒWehave met the enemy, and he is us.Óis the chief scientist for ThoughtWorks, and In-ternet systems delivery and consulting company. Contact him at