IBM Research
© 2009 IBM Corporation
Grady BoochFree Radical
The Defenestration of Superfluous Architectural Accoutrements
IBM Research
© 2009 IBM Corporation
Defenestration
The act of throwing a person or an object out of a window
The Defenestration of Prague (1618)
IBM Research
© 2009 IBM Corporation
Superfluous
Exceeding what is sufficient or necessary; marked by wastefulness
IBM Research
© 2009 IBM Corporation
Accoutrement
An accessory item of clothing or equipment
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
From Complexity to Simplicity
McCloud in Understanding Comics
– Amplification through simplification
IBM Research
© 2009 IBM Corporation
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)
12
http://www.research.att.com/~njas/sequences/Seis.html
IBM Research
© 2009 IBM Corporation
Points Of View
13
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
IBM Research
© 2009 IBM Corporation
Points Of View
14
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
IBM Research
© 2009 IBM Corporation
Points Of View
15
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
IBM Research
© 2009 IBM Corporation
Points Of View
16
Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.
IBM Research
© 2009 IBM Corporation
From Control To Chaos
17
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
From Complexity to Simplicity
Ross
– Growing complexity in companies’ systems can fossilize operations
Complexity
– Creates inertia to change
– Fights against understandability
– Introduces fragility
IBM Research
© 2009 IBM Corporation
From Complexity to Simplicity
Richten
– Simplify. Simplify. Simplify.
Booch
– Simplify
IBM Research
© 2009 IBM Corporation
On Finding Simplicity
Simplicity doesn’t just happen
– Despite the best intentions
– Many forces eat away
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
On Architectural Failure
A thousand cuts
– Collapse happens because of the accumulated weight of well-intentioned 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
IBM Research
© 2009 IBM Corporation
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.
IBM Research
© 2009 IBM Corporation
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?
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
What Might Attend To That Pain? Immediacy
– Aspirin
– Vitamins
– Tourniquet
Scope
– Local
– Product
– Enterprise
– Industry
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
An Classic Analogy
IBM Research
© 2009 IBM Corporation
A Fresh Analogy (A Snapshot In Time)
IBM Research
© 2009 IBM Corporation
A Fresh Analogy (A Broader Expanse)
IBM Research
© 2009 IBM Corporation
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.
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
Focus over timeDiscovery Invention
Focus
Implementation
Bran Selic
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
It’s Easy To Be Distracted By Shiny Objects
IBM Research
© 2009 IBM Corporation
And Thus It Requires Discipline
Ross et al, Enterprise Architecture as Strategy
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
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 ResearchHall, J. and Johnson, E. “When Should a Process Be Art, Not Science?” Harvard Business Review
IBM Research
© 2009 IBM Corporation
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
IBM Research
© 2009 IBM Corporation
The development lifecycle
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Elaboration Construction TransitionInception
Inception– Understand what to build
Elaboration– Understand how to build it
Construction– Build the product
Transition– Deliver and adapt the solution
IBM Research
© 2009 IBM Corporation
Iterative and incremental development
100%
Project Schedule
WaterfallProject Profile
ModernProject Profile
Deve
lopm
ent P
rogr
ess
(% C
oded
)
Walker Royce, IBM Rational
IBM Research
© 2009 IBM Corporation
RiskRisk
Time
Risk resolution Controlled risk management
IterativeWaterfall
Risk
Architecture first
IBM Research
© 2009 IBM Corporation
The Seminal Role Of Architecture How we design the solution
How we design the organization
IBM Research
© 2009 IBM Corporation
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