1. Grady Booch Free Radical Everything You Know Is Wrong

2. Grady Booch Free Radical Everything, You Know, Is Wrong

3. Any future we envision relies on software- intensive systems...that have not yet been written 3

4. 4

6. 6 http://www.computerworld.com.au/article/250514/a-z_programming_languages_c_/s.jpg Our civilization runs on software

7. 7 The function of good software is to make the complex appear to be simple.

8. What Pain Do You Feel?  How do we attend to new requirements without being saddled by our legacy (but at the same time not compromising that legacy?)  How do we integrate new technology into our existing code base?  How do we integrate our existing systems to extract greater value from the whole?  How do we increase our agility in response to the market while simultaneously improving efficiency and quality yet also reducing costs?  How do we attend to assets introduced through acquisition?  How do use software to improve market efficiency through the creation of dominant product lines?  How do we 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 we continue to innovate?

9. Fundamental Challenges Of Discrete Systems  Presence of essential complexity [Brooks]  Non-continuous behavior of discrete systems  Combinatorial explosion of states  Corruption from unexpected external events  Lack of mathematical tools and intellectual capacity to model the behavior of large discrete systems

10. Complexity  Classical –Computational complexity –Kolmogorov complexity  From my experience –Software mass –The enumeration of things per view –The enumeration of connections per view –The presence of patterns per view –The number of possible states

11. Triggers Of Complexity  Significant interactions  High number of parts and degrees of freedom  Nonlinearity  Broken symmetry  Nonholonomic constraints –Localized transient anarchy –Time-triggered vs state machines Flood, Dealing With Complexity

12. The Limits of Computing  The laws of physics  The laws of software  The challenge of algorithms  The difficulty of distribution  The problems of design  The importance of organization  The impact of economics  The influence of politics  The limits of human imagination Fundamental Human

13. Points Of Friction  Cost of start up and on-going working space organization  Inefficient work product collaboration  Maintaining effective group communication, including knowledge and experience, project status, and project memory  Time starvation across multiple tasks  Stakeholder negotiation  Stuff that doesn’t work  High semantic density artifacts

14. 14 Developing complex software-intensive systems has been, is, and will continue to be fundamentally hard.

15. What Not To Do  Over-constrain your process.  Under-constrain your process.  Treat developing software-intensive systems as a cost center.

16. What To Do  Develop in anger (with measurable continuous deliverables in mind).  Listen to your customers (but not too much).  Listen to your code warriors (but with a light touch).

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

18. Why Architecture? –Making manifest a system’s architecture facilitates understanding, reasoning about, and transforming that system with intention. –Syndicating a system’s architecture helps preserve and extend the development organization’s tribal memory. –Governing a system’s architecture makes it possible to grow that system efficiently and effectively through refactoring, by creating a stable platform for innovation, and by establishing a managed product line (all the while keeping the original system running).

19. What Is Architecture? –The code is the truth (but not the whole truth). –All architecture is design, but not all design is architecture. –Architecture represents the set of significant design decisions that shape a system, as seen from the perspective of multiple points of view.

20. What Is Architecture? –Architecture as essence. Architecture is the fundamental conception of a system in its environment embodied in elements, their relationships to each other and to the environment, and principles guiding system design and evolution. –Architecture as blueprint. –Architecture as literature. –Architecture as language. –Architecture as decision. ISO/IEC WD4 42010 Architecture Description

21. Architectural Issues  Representation/documentation/manifestation  Patterns/styles  Process/transformation  Social organization

23. The Well-Structured Architecture  All well-structured systems are full of patterns  All well-structured systems embody –Crisp abstractions –A clear separation of concerns –A balanced distribution of responsibilities

24. Observations  Hierarchy is an illusion  There is no top  Characterization as an input-output mapping is naïve  Multiple simultaneously interlocking views are necessary

25. 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  Patterns help you manage software complexity [Buschmann]  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. [Kerievsky]

26. Developers (for the most part) don’t draw diagrams because they (the diagrams, that is) (rarely) offer any fundamental value that advances their (the developers, that is) essential work

27. Why Don’t Developers Draw Diagrams?  Our primary product is raw, running, naked code, not diagrams  Diagrams and code have an uneasy relationship that quickly drifts into oblivion and usually ends in tears

28. Some Basic Principles  Edward Tuftee –He abhors eye candy, and values meaning over presentation –“The minimum we should hope for with any display technology is that it should do no harm” – Any representation should not obscure, bias, or obfuscate reality –He warned against gratuitous representations “without realizing the cost to the content and the audience in the process” –Representations must simplify, not contribute to, complexity –“The point is that analytical designs are not to be decided on their convenience to the user or necessarily their readability or what physiologists or decorators think about them; rather, design architectures should be decided on how the architecture assists analytical thinking about evidence.”  Scott McCloud –Amplification through simplification  Carl Sagan –“The brain has its own language for testing the structure and consistency of the world”

29. What Modeling Is  Abstraction of reality  Abstractions are not reality

30. What Modeling Should Be  Abstraction with freedom but without ambiguity  Abstraction with focus  Artifacts at a moment in time  Artifacts across time and space  Artifacts for many stakeholders  Artifacts made manifest

31. Why We Model  To abstract  To reason about  To document  To transform

32. Describing A System’s Architecture ISO/IEC WD4 42010 Architecture Description

35. Kruchten, “The 4+1 View Model of Software Architecture” Booch, The Handbook of Software Architecture

38. 38 Representing software architecture Kruchten, “The 4+1 Model View” Logical View End-user Functionality Implementation View Programmers Configuration management Process View Performance Scalability Throughput System integrators Deployment View System topology Communication Provisioning System engineering ConceptualPhysical Use Case View 10/2/2015 Ⓒ 2008 Grady Booch

39. Google 39 Ⓒ 2008 Grady Booch 10/2/2015

40. Games 40 Ⓒ 2008 Grady Booch 10/2/2015

41. Pathfinder 41 Ⓒ 2008 Grady Booch 10/2/2015

42. Watson

43. Fundamentals  Development takes place at two levels: architecture and implementation. –Both are ongoing, and they interact with each other strongly. New implementations suggest architectural changes. Architectural changes usually require radical changes to the implementation. Coplien, Organizational Patterns of Agile Development, p. 332

44. Coplien, Organizational Patterns of Agile Development

45. Focus over time DiscoveryInvention Focus Implementation Bran Selic

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

47. Process Best Practices  Not one lifecycle, but many Different stages of execution, maturation, and quality Harmony, resonance, and cacophony  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 47

48. How Much Process Is Necessary? 48 Department of Defense Chaos (no process) Amount of Process Necessary Small Team MediumStart-up When is More Appropriate? Distributed teams Large projects (25, 125, 625) Complex projects Externally imposed constraints Standards Contractual requirements Legal requirements When is Less Appropriate? Co-located teams Smaller projects (less than 25) Straightforward projects Internally imposed constraints

49. The Agile Lifecycle Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration ElaborationConstructionTransitionInception  Inception Understand what to build  Elaboration Understand how to build it  Construction Build the product  Transition Deliver and adapt the solution

50. Process Best Practices  Attack major risks early and continuously or else they will attack you  Ensure that you deliver value to your customer  Have a maniacal focus on working software  Accommodate change early in the project  Baseline an executable architecture early on  Build your system with components  Work closely together as one team  Make quality a way of life, not an afterthought 50 Walker Royce

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

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

53. Any future we envision relies on software- intensive systems...that have not yet been written53