the defenestration of superfluous architectural accoutrements

47
IBM Research © 2009 IBM Corporation Grady Booch Free Radical The Defenestration of Superfluous Architectural Accoutrements

Upload: kato

Post on 12-Jan-2016

28 views

Category:

Documents


4 download

DESCRIPTION

The Defenestration of Superfluous Architectural Accoutrements. Grady Booch Free Radical. Defenestration. The act of throwing a person or an object out of a window. The Defenestration of Prague (1618). Superfluous. Exceeding what is sufficient or necessary; marked by wastefulness. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Grady BoochFree Radical

The Defenestration of Superfluous Architectural Accoutrements

Page 2: 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)

Page 3: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Superfluous

Exceeding what is sufficient or necessary; marked by wastefulness

Page 4: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Accoutrement

An accessory item of clothing or equipment

Page 5: The Defenestration of Superfluous Architectural Accoutrements

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

Page 6: The Defenestration of Superfluous Architectural Accoutrements

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

Page 7: The Defenestration of Superfluous Architectural Accoutrements

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

Page 8: The Defenestration of Superfluous Architectural Accoutrements

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

Page 9: The Defenestration of Superfluous Architectural Accoutrements

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

Page 10: The Defenestration of Superfluous Architectural Accoutrements

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

Page 11: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

From Complexity to Simplicity

McCloud in Understanding Comics

– Amplification through simplification

Page 12: The Defenestration of Superfluous Architectural Accoutrements

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

Page 13: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Points Of View

13

Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

Page 14: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Points Of View

14

Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

Page 15: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Points Of View

15

Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

Page 16: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Points Of View

16

Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

Page 17: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

From Control To Chaos

17

Page 18: The Defenestration of Superfluous Architectural Accoutrements

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

Page 19: The Defenestration of Superfluous Architectural Accoutrements

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

Page 20: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

From Complexity to Simplicity

Richten

– Simplify. Simplify. Simplify.

Booch

– Simplify

Page 21: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

On Finding Simplicity

Simplicity doesn’t just happen

– Despite the best intentions

– Many forces eat away

Page 22: The Defenestration of Superfluous Architectural Accoutrements

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

Page 23: The Defenestration of Superfluous Architectural Accoutrements

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

Page 24: The Defenestration of Superfluous Architectural Accoutrements

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.

Page 25: The Defenestration of Superfluous Architectural Accoutrements

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?

Page 26: The Defenestration of Superfluous Architectural Accoutrements

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

Page 27: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

What Might Attend To That Pain? Immediacy

– Aspirin

– Vitamins

– Tourniquet

Scope

– Local

– Product

– Enterprise

– Industry

Page 28: The Defenestration of Superfluous Architectural Accoutrements

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

Page 29: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

An Classic Analogy

Page 30: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

A Fresh Analogy (A Snapshot In Time)

Page 31: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

A Fresh Analogy (A Broader Expanse)

Page 32: The Defenestration of Superfluous Architectural Accoutrements

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.

Page 33: The Defenestration of Superfluous Architectural Accoutrements

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

Page 34: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

Focus over timeDiscovery Invention

Focus

Implementation

Bran Selic

Page 35: The Defenestration of Superfluous Architectural Accoutrements

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

Page 36: The Defenestration of Superfluous Architectural Accoutrements

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

Page 37: The Defenestration of Superfluous Architectural Accoutrements

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

Page 38: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

It’s Easy To Be Distracted By Shiny Objects

Page 39: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

And Thus It Requires Discipline

Ross et al, Enterprise Architecture as Strategy

Page 40: The Defenestration of Superfluous Architectural Accoutrements

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

Page 41: The Defenestration of Superfluous Architectural Accoutrements

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

Page 42: The Defenestration of Superfluous Architectural Accoutrements

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

Page 43: The Defenestration of Superfluous Architectural Accoutrements

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

Page 44: The Defenestration of Superfluous Architectural Accoutrements

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

Page 45: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

RiskRisk

Time

Risk resolution Controlled risk management

IterativeWaterfall

Risk

Architecture first

Page 46: The Defenestration of Superfluous Architectural Accoutrements

IBM Research

© 2009 IBM Corporation

The Seminal Role Of Architecture How we design the solution

How we design the organization

Page 47: The Defenestration of Superfluous Architectural Accoutrements

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