IBM Research
The Defenestration of Superfluous
Architectural Accoutrements
Grady Booch
Free Radical
© 2009 IBM Corporation
IBM Research
Defenestration
 The act of throwing a person or an object out of a window
The Defenestration of Prague (1618)
© 2009 IBM Corporation
IBM Research
Superfluous
 Exceeding what is sufficient or necessary; marked by
wastefulness
© 2009 IBM Corporation
IBM Research
Accoutrement
 An accessory item of clothing or equipment
© 2009 IBM Corporation
IBM Research
The Premise
 Simple architectures have conceptual integrity
 Architectures that are simple are better than those that are more
complex
 A process of continuous architectural refactoring helps to
converge a system to its practical and optimal simplicity
© 2009 IBM Corporation
IBM Research
On Measuring Architectural Complexity
 Mass (calculated in SLOC)
 Regularity (measured in patters/view)
 States
• Boulder: few states spread across geological time
• Software-intensive system: combinatorial explosion of states
• Real world: non-discrete, non-continuous
© 2009 IBM Corporation
IBM Research
On Measuring Architectural Simplicity
 Simon
– Complex systems are hierarchical
– Complex systems are nearly decomposable
 Brooks
– Conceptual integrity is the most important consideration in system
design
 Weinberg
– Unorganized complexity is the most wicked form of complexity
© 2009 IBM Corporation
IBM Research
Cross-Cutting Concerns
 For example
– Security
– Resource utilization
– Performance
 Cross-cutting concerns involve
– Scattering: code implementing one concern is scattered across
several classes
– Tangling: code implementing several concerns is tangled within the
same class or even the same method
© 2009 IBM Corporation
IBM Research
Attending to Simplicity
 The fundamentals
– Define crisp abstractions
– Employ a good separation of concerns
– Have a balanced distribution of responsibilities
 Insofar as a system embraces these fundamentals, it is simple;
when and where it strains these fundamentals, it is complex
© 2009 IBM Corporation
IBM Research
Identifying Complexity
 Kent Beck
– Code smells as a metaphor for identifying these points of stress
 Heinlein in The Moon is a Harsh Mistress
– How does one design an electric motor? Would you attach a
bathtub to it, simply because one was available? Would a bouquet
of flowers help? A heap of rocks? No, you would use just those
elements necessary to its purpose and make it no larger than
needed – and you would incorporate safety factors. Function
controls design.
 Simple architectures have conceptual integrity
© 2009 IBM Corporation
IBM Research
From Complexity to Simplicity
 McCloud in Understanding Comics
– Amplification through simplification
© 2009 IBM Corporation
IBM Research
Thinking Outside The Box
 Consider the sequence 1, 2, 3…
– 4 (natural integers)
– 5 (Fibonacci series)
– 2 (largest prime dividing n)
– 3 (number of prime divisors of n, n = 60)
– 1 (number of distinct primes dividing n, n = 63)
http://www.research.att.com/~njas/sequences/Seis.html
12
© 2009 IBM Corporation
IBM Research
Points Of View
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
13
© 2009 IBM Corporation
IBM Research
Points Of View
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
14
© 2009 IBM Corporation
IBM Research
Points Of View
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
15
© 2009 IBM Corporation
IBM Research
Points Of View
 Monologue
 Minimalist
 Subjective
 A Life
 Upstairs
 Evolution
 Voyeur
 Fixed Point In Space
 Retrograde
 One Horizon
 déjà vu
 No Pictures
 Manga
 Paranoid
 Fantasy
 Opposites
 Opposites
 Isometric
 Long Shots
 Reframing
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
16
© 2009 IBM Corporation
IBM Research
From Control To Chaos
17
© 2009 IBM Corporation
IBM Research
From Complexity to Simplicity
 Complexity masks the essential elements of a system
 Insofar as we have to expend energy to brush away the
surrounding crud that obscures that essence, we’ve lost
something in the message and we’ve hidden the
•
•
•
•
Underlying purpose
Uniqueness
Elegance
Beauty
© 2009 IBM Corporation
IBM Research
From Complexity to Simplicity
 Ross
– Growing complexity in companies’ systems can fossilize operations
 Complexity
– Creates inertia to change
– Fights against understandability
– Introduces fragility
© 2009 IBM Corporation
IBM Research
From Complexity to Simplicity
 Richten
– Simplify. Simplify. Simplify.
 Booch
– Simplify
© 2009 IBM Corporation
IBM Research
On Finding Simplicity
 Simplicity doesn’t just happen
– Despite the best intentions
– Many forces eat away
© 2009 IBM Corporation
IBM Research
On Architectural Failure
 Sometimes, systems fail because their architects have chosen a
fundamentally wrong architecture
 Most of the time, projects
– Die the death of a thousand cuts
– Are nibbled to death by ducks
© 2009 IBM Corporation
IBM Research
On Architectural Failure
 A thousand cuts
– Collapse happens because of the accumulated weight of wellintentioned and reasonable local decisions that assemble over time
at the expense of global optimization and simplicity
 Nibble to death by ducks
– You rarely see the end coming, until some factor pushes your
fragile, complex system over the edge into collapse
© 2009 IBM Corporation
IBM Research
From Complexity to Simplicity
 Simplicity can only be found by adding energy
– That energy is best applied in a process of continuous architectural
refactoring
– The power of patterns
 Buschmann
– Patterns help you manage software complexity
 Kerievsky
– While we refactor code for many reasons, the following motivations
are among the most common: make it easier to add new code;
improve the design of existing code; gain a better understanding of
code; make coding less annoying.
© 2009 IBM Corporation
IBM Research
What Pain Do You Feel?
 How do you attend to new requirements without being saddled by legacy
(but at the same time not compromising that legacy?)
 How do you integrate new technology into your existing code base?
 How do you integrate your existing systems to extract greater value from the
whole?
 How do you increase your agility in response to the market while
simultaneously improving efficiency and quality yet also reducing costs?
 How do you attend to assets introduced through acquisition?
 How do you use software to improve market efficiency through the creation
of dominant product lines?
 How do you attend to a continuously refreshed stakeholder community, a
globally and temporally distributed development team, and inevitable
leakage/loss of institutional memory?
 While doing all this, how do you continue to innovate?
© 2009 IBM Corporation
IBM Research
9 Things You Can Do With Old Software
 Give it away
 Ignore it
 Put it on life support
 Rewrite it
 Harvest from it
 Wrap it up
 Transform it
 Preserve it
© 2009 IBM Corporation
IBM Research
What Might Attend To That Pain?
 Immediacy
– Aspirin
– Vitamins
– Tourniquet
 Scope
– Local
– Product
– Enterprise
– Industry
© 2009 IBM Corporation
IBM Research
An Observation
 While these points of pain are legion, a common thread that
weaves though them is that of architecture
– Every software-intensive system has one
– Most are accidental, a few are intentional
– A considerable amount of architectural knowledge lies in tribal
memory
 The presence of a reasonably well understood, syndicated, and
governed architecture has a positive impact upon each of these
points of pain
© 2009 IBM Corporation
IBM Research
An Classic Analogy
© 2009 IBM Corporation
IBM Research
A Fresh Analogy (A Snapshot In Time)
© 2009 IBM Corporation
IBM Research
A Fresh Analogy (A Broader Expanse)
© 2009 IBM Corporation
IBM Research
Therefore
 The architecture of an enterprise’s software intensive systems is
akin to the instantaneous structure and behavior of a river
 The lifecycle of that architecture is akin to the intentional and
accidental morphing of those instantaneous architctures over a
region of time.
© 2009 IBM Corporation
IBM Research
The Enterprise Architecture
 If the enterprise is a river and the mission of that enterprise is
represented by the boats traveling along it, then
– The enterprise’s architecture is the collection of engineering
decisions and artifacts that make manifest a solution that resolves
the forces
 Some important subtleties
• Fleets, not just single boats
• Dynamic forces, not just instantaneous ones
• Forces that are beyond our control, as well as indirect forces of
our own doing
© 2009 IBM Corporation
IBM Research
Focus over time
Discovery
Invention
Implementation
Focus
Bran Selic
© 2009 IBM Corporation
IBM Research
The Enterprise Architecture Lifecycle
 In my experience
– All hyperproductive organizations tend to have a lifecycle that
involves the growth of a system’s architecture through the
incremental and iterative release of testable executables.
 Not one lifecycle, but many
– Different stages of execution, maturation, and quality
– Harmony, resonance, and cacophony
© 2009 IBM Corporation
IBM Research
Best Practices For Software-Intensive Systems
 Architecture-as-artifact is a manifestation of technical intellectual property and thus
serves as an artifact of control involving
– Active yet flexible budgeting of resources
– Checks and balances for the co-evolution of architecture and implementation
– Accountability for technical decisions
– Hedges for the future
– Diversification for the future
– Appropriate measurements and incentives
– Cost controls
– Economics of scale via patterns
– Actively attacking risk
© 2009 IBM Corporation
IBM Research
Best Practices For Fiscal Concerns
 Any robust enterprise will have institutionalized best practices for its fiscal concerns
– Active yet flexible budgeting
– Checks and balances
– Accountability
– Hedges for unforeseen circumstances
– Diversification
– Appropriate measurements and incentives
– Cost controls
– Economics of scale
– Predictive financial analysis
© 2009 IBM Corporation
IBM Research
It’s Easy To Be Distracted By Shiny Objects
© 2009 IBM Corporation
IBM Research
And Thus It Requires Discipline
Ross et al, Enterprise Architecture as Strategy
© 2009 IBM Corporation
IBM Research
It’s Tempting to Over-control
 We often see people pursuing efforts to make software
production "factory-like” believing that will solve some problem
usually related to cost and schedule control
– Hitachi Software Works (’60s)
– Automatic programming (’70s)
– Process programming (’80s)
– Software factories (‘90s – present)
Clay Williams, IBM Research
© 2009 IBM Corporation
IBM Research
But One Needs Freedom For Innovation
 As Williams notes, for all but routine software development and
deployment (which may indeed be a cost center), this is a Really,
Really Bad Idea
– A misguided but tempting view
– Often co-arises with a cost center perspective on software
– “If we can figure out the ideal process to construct software, we can
manage software creation (and hence its cost and schedule)
tightly.”
Clay Williams, IBM Research
Hall, J. and Johnson, E. “When Should a Process Be Art, Not Science?” Harvard Business Review
© 2009 IBM Corporation
IBM Research
Process best practices
 Grow the architecture of a system through the incremental and
iterative release of testable executables
– Focus on executables
– Incremental and iterative progress
– Architecture as artifact
© 2009 IBM Corporation
IBM Research
The development lifecycle
Inception Elaboration
Preliminary Architect.
Iteration
Iteration
Construction
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Devel.
Iteration
Transition
Iteration
Transition
Iteration
 Inception
– Understand what to build
 Elaboration
– Understand how to build it
 Construction
– Build the product
 Transition
– Deliver and adapt the solution
© 2009 IBM Corporation
IBM Research
Iterative and incremental development
100%
Development Progress
(% Coded)
Modern
Project Profile
Waterfall
Project Profile
Project Schedule
Walker Royce, IBM Rational
© 2009 IBM Corporation
IBM Research
Architecture first
Risk resolution Controlled risk management
Risk
Waterfall
Iterative
Risk
Time
© 2009 IBM Corporation
IBM Research
The Seminal Role Of Architecture
 How we design the solution
 How we design the organization
© 2009 IBM Corporation
IBM Research
On Simplicity
 The accouterments of an architecture are the elements that
contribute to its complexity
 To the degree that these trappings are superfluous or irregular
or inconsistent or scattered or tangled, simplicity suffers
 Continuous architectural refactoring is the means by which we
throw out the bits that smell and leave in only those that
optimally, efficiently and elegantly resolve the forces that weigh
upon the system as a whole
© 2009 IBM Corporation