The Defenestration of Superfluous Architectural Accoutrements

1. The Defenestration of Superfluous Architectural Accoutrements Grady Booch Free Radical

2. Defenestration • The act of throwing a person or an object out of a window The Defenestration of Prague (1618)

3. Superfluous • Exceeding what is sufficient or necessary; marked by wastefulness

4. Accoutrement • An accessory item of clothing or equipment

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. From Complexity to Simplicity • McCloud in Understanding Comics • Amplification through simplification

12. 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

13. Points Of View Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

14. Points Of View Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

15. Points Of View Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

16. Points Of View • Monologue • Subjective • Upstairs • Voyeur • Retrograde • déjà vu • Manga • Fantasy • Opposites • Long Shots • Minimalist • A Life • Evolution • Fixed Point In Space • One Horizon • No Pictures • Paranoid • Opposites • Isometric • Reframing Madden, M. 99 Ways To Tell A Story. London: Random House, 2005.

17. From Control To Chaos

18. 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

19. From Complexity to Simplicity • Ross • Growing complexity in companies’ systems can fossilize operations • Complexity • Creates inertia to change • Fights against understandability • Introduces fragility

20. From Complexity to Simplicity • Richten • Simplify. Simplify. Simplify. • Booch • Simplify

21. On Finding Simplicity • Simplicity doesn’t just happen • Despite the best intentions • Many forces eat away

22. 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

23. 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

24. 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.

25. 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?

26. 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

27. What Might Attend To That Pain? • Immediacy • Aspirin • Vitamins • Tourniquet • Scope • Local • Product • Enterprise • Industry

28. 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

29. An Classic Analogy

30. A Fresh Analogy (A Snapshot In Time)

31. A Fresh Analogy (A Broader Expanse)

32. 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.

33. 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

34. Focus over time Discovery Invention Implementation Focus Bran Selic

35. 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

36. 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

37. 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

38. It’s Easy To Be Distracted By Shiny Objects

39. And Thus It Requires Discipline Ross et al, Enterprise Architecture as Strategy

40. 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

41. 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

42. 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

43. Inception Elaboration Construction Transition Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration The development lifecycle • Inception • Understand what to build • Elaboration • Understand how to build it • Construction • Build the product • Transition • Deliver and adapt the solution

44. WaterfallProject Profile Iterative and incremental development 100% ModernProject Profile Development Progress(% Coded) Project Schedule Walker Royce, IBM Rational

45. Architecture first Controlled risk management Risk resolution Waterfall Iterative Risk Risk Time

46. The Seminal Role Of Architecture • How we design the solution • How we design the organization

47. 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