scispace - formally typeset
Search or ask a question

Showing papers by "Grady Booch published in 2006"


Book
01 Sep 2006

52 citations


Journal ArticleDOI
Grady Booch1
TL;DR: Having an accidental architecture is not necessarily a bad thing, as long as the decisions that make up that architecture are made manifest and the essential ones are made visible as soon as they are instituted and then allowed to remain visible throughout the meaningful life of that system.
Abstract: Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental. Philippe Kruchten has observed that "the life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark." The journey between vision and ultimate executable system is complex, and for every interesting software-intensive system that path is marked by myriad decisions, some large and some small, some of which advance progress while others represent vestigial dead ends or trigger points for scrap and rework. As Philippe also observes, the architecture of classical systems comes primarily from theft, whereas the architecture of unprecedented systems comes largely from intuition carried out in the context of a controlled exploratory process. The fact that this is so for software-intensive systems shouldn't come as a surprise, for as Henry Petroski explains in his book To Engineer Is Human (Vintage, 1992), all sound engineering disciplines advance by building on past successes while simultaneously mitigating causes of observable failure.Thus, having an accidental architecture is not necessarily a bad thing, as long as the decisions that make up that architecture are made manifest and the essential ones are made visible as soon as they are instituted and then allowed to remain visible throughout the meaningful life of that system. Insofar as we can then name these architectures after they're formed, we can use these names and their associated semantics to communicate decisions using a common language, just as we can do now with design patterns, and perhaps even reuse these architectural patterns in future systems. In other words, by naming these accidental architectures, we again raise the level of abstraction by which we can describe and reason about a system.

10 citations


Journal ArticleDOI
Grady Booch1
TL;DR: There's a goodness of fit with software architectures: for a given domain, even across the decades, forces are at play that are best resolved by a common architectural pattern that allows variants.
Abstract: It appears to be with software architectures: for a given domain, even across the decades, forces are at play that are best resolved by a common architectural pattern that allows variants. One architectural style might be deemed "better" than another for that domain because it better resolves those forces. In that sense, there's a goodness of fit - not necessarily a perfect fit, but good enough

6 citations