Best Practices in Software Architecture

1. Grady Booch Best Practices in Software Architecture

2. The Current State • The typical software-intensive system is • Continuously evolving • Connected, distributed, & concurrent • Multilingual & multiplatform • Secure & autonomic • Developed by geographically- temporally-distributed teams • Most systems are actually systems of systems • Services & other messaging mechanisms dominate • Such systems encompass both hardware & software

3. Growth Of Storage • The production of data is growing • Google processes 20 petabytes/day1 • The Internet handles over 627 petabytes/day2 • Storage densities are increasing • 200 gigabytes/inch2 are common today • Racetrack memory could increase storage density by two orders of magnitude (20,000 gigabytes/inch2)3 Opportunity 1http://www.niallkennedy.com/blog/2008/01/google-mapreduce-stats.html 2http://en.wikipedia.org/wiki/Petabyte 3http://www.almaden.ibm.com/spinaps/research/sd/?racetrack

4. Growth Of Computational Power • Computational power is abundant • A single BladeCenter can reach 7 teraflops • IBM Road Runner has reached one petaflop • Hardware costs are around 20 cents/gigaflop; operating costs are approximately 3 watts/gigaflop1 • The frequency scaling wars are ending • At 10 atoms/transistor, quantum effects & power dissipation become critical issues issues • Multicore processors are becoming the norm Opportunity 1http://en.wikipedia.org/wiki/FLOPS

5. Growth Of Connectivity • Bandwidth is increasing • Copper may reach 10 gigabytes/second • Wireless networks are becoming pervasive • Out of 3.7 billion IPv4 addresses1 • China 19.246 million • US 13.610 million • Germany 5.414 million • Italy 3.881 million • Indonesia 3.465 million • Taiwan 3.455 million Opportunity 1http://www.bgpexpert.com/addressespercountry.php

6. Future Software-Intensive Systems • Future systems will be just like contemporary ones except they will be • More massive • More pervasive • More transparent • More critical • Domain-specific platforms are growing in dominance

7. Agenda • Architecture defined and defended • Architecture best practices • Software archeology • Process and governance • Organizational patterns • Handbook and preservation Ⓒ 2008 Grady Booch

8. Architecture defined and defended Ⓒ 2008 Grady Booch

9. Fundamentals • All architecture is design; not all design is architecture. A system’s architecture is defined by its significant design decisions (where “significant” is measured by the cost of change). • Most architectures are accidental; some are intentional. • Every software-intensive system has an architecture, forged from the hundreds of thousands of small decisions made every day. • The code is the truth, but not the whole truth: most architectural information is preserved in tribal memory. Ⓒ 2008 Grady Booch

10. Air Traffic Control http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

11. ATM http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

12. Battlefield Management http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

13. Cargo Routing http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

14. Computational Chemistry http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

15. Enterprise http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

16. Games http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

17. Games http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

18. Google Ⓒ 2008 Grady Booch

19. Linux http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

20. MetLife http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

21. Mobile Phone http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

22. Mozilla http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

23. Pathfinder http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

24. Router http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

25. Speech Recognition http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

26. Washing Machine http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

27. Web Server http://www.booch.com/architecture/architecture.jsp?part=Gallery Ⓒ 2008 Grady Booch

28. From vision to execution http://www.gehrytechnologies.com/ Ⓒ 2008 Grady Booch

29. Movements on civil architecture • Egyptian/Babylonian, Assyrian, Persian • Classical Indian • Dynastic China • Grecian/Roman • Early Christian/Byzantine • Islamic • Romanesque • Gothic • Renaissance • Palladian • Neoclassical • Picturesque • Mannerism • Baroque • Engineering/Rational/National/Romantic • Art Noveau • Modernism Progress - Imitation of previous efforts - Learning from failure - Integration of other forces - Experimentation Architects - Imhotep - Vitruvius - Michelangelo - Palladio - Wright - Wren - LeCorbusier - Geary - Libeskind Cole, The Grammar of Architecture Ⓒ 2008 Grady Booch

30. Movements in web-centric architectures • Simple documents • Colorful clients • Simple scripting • Rise of middleware • Rise of simple frameworks • Emergence of dynamic frameworks • Semantic web Ⓒ 2008 Grady Booch

31. Load Load Compression Tension Forces in civil architecture Kinds of loads - Dead loads - Live loads - Dynamic loads Avoiding failure - Safety factors - Redundancy - Equilibrium Any time you depart from established practice, make ten times the effort, ten times the investigation. Especially on a very large project. - LeMessuier Ⓒ 2008 Grady Booch

32. Forces in software Ⓒ 2008 Grady Booch

33. Patterns in physical systems • Calloway and Cromley's The Elements of Style • Alexander's The Nature of Order • The Phaidon Atlas of Contemporary World Architecture • Perry's Chemical Engineers' Handbook • Sclater and Chironis' Mechanism and Mechanical Devices Sourcebook • Christiansen's Electrical Engineers' Handbook • ICRF Handbook of Genome Analysis Ⓒ 2008 Grady Booch

34. Software patterns • Buschman, Pattern-Oriented Software Architecture • Dyson, Architecting Enterprise Solutions • Fowler, Patterns of Enterprise Application Architecture • Gamma et al, Design Patterns • Hohpe et al, Enterprise Integration Patterns • Kircher, Pattern-Oriented Software Architecture • Schmidt, Pattern-Oriented Software Architecture • Shaw/Garland Software Architecture • Towbridge et al, Integration Patterns Ⓒ 2008 Grady Booch

35. Physical systems • Mature physical systems have stable architectures • Aircraft, cars, and ships • Bridges and buildings • Such architectures have grown over long periods of time • Trial-and-error • Reuse and refinement of proven solutions • Quantitative evaluation with analytical methods • Mature domains are dominated by engineering efforts • Analytical engineering methods • New materials and manufacturing processes Ⓒ 2008 Grady Booch

36. Architecting software is different • No equivalent laws of physics • Transparency • Complexity • Combinatorial explosion of state space • Non-continuous behavior • Systemic issues • Requirement and technology churn • Low replication and distribution costs Ⓒ 2008 Grady Booch

37. Fundamental Human The limits of software • 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 Ⓒ 2008 Grady Booch

38. The entire historyof software engineering is one of rising levels of abstraction Languages: Platforms: Processes: Architecture: Tools: Enablement: Assembly  Fortran/COBOL  Simula  C++  Java Naked HW  BIOS  OS  Middleware  Domain-specific Waterfall  Spiral  Iterative  Agile Procedural  Object Oriented  Service Oriented Early tools  CLE  IDE  XDE  CDE Individual  Workgroup  Organization Ⓒ 2008 Grady Booch

39. Architecture defined • IEEE 1471-2000 • Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution • Software architecture encompasses the set of significant decisions about the organization of a software system • Selection of the structural elements and their interfaces by which a system is composed • Behavior as specified in collaborations among those elements • Composition of these structural and behavioral elements into larger subsystems • Architectural style that guides this organization Source: Booch, Kruchten, Reitman, Bittner, and Shaw Ⓒ 2008 Grady Booch

40. Why Architecture? • In hyper-productive projects • Process centers around growing an executable architecture • Well-structured systems are full of patterns • Why architecture? • Risk-confrontive • Simplicity • Resilience Ⓒ 2008 Grady Booch

41. Architecture best practices Ⓒ 2008 Grady Booch

42. Fundamentals • Crisp abstractions • Clear separation of concerns • Balanced distribution of responsibilities • Simplicity Ⓒ 2008 Grady Booch

43. What we know we know • Every software-intensive system has an architecture • We generally understand what software architecture is and what it is not • Different stakeholders have different concerns and therefore different viewpoints • All well-structured software-intensive systems are full of patterns Ⓒ 2008 Grady Booch

44. Definitions • Architecture • The fundamental organization of a system, embodied in its components, their relationships to each other, and the principles governing its design and evolution (IEEE Std 1471-2000, 2000, p. 3). • Stakeholder • An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system (IEEE Std 1741-2000, 2000, p. 3). • Concern • Those interests which pertain to the system's development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability (IEEE Std 1471-2000, 2000, p. 4). • View • A representation of a whole system from the perspective of a related set of concerns (IEEE Std 1471-2000, 2000, p. 3). Ⓒ 2008 Grady Booch

45. Architectural frameworks • AGATE • DoD Architecture Framework • Federal Enterprise Architecture • MoD Architecture Framework • Reference Model of Open Distributed Computing • Open Group Architecture Framework • Zachman Framework Ⓒ 2008 Grady Booch

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

47. Architectural views • Use case view • The view of a system's architecture that encompasses the use cases that described the behavior of the system as seen by its end users and other external stakeholders. • Logical view • The physical place where a system is developed, used, or deployed. • Process view • The view of a system's architecture that encompasses the threads and processes that form the system's concurrency and synchronization mechanisms; a process view addresses the performance, scalability, and throughput of the system. • Implementation view • The view of a system's architecture that encompasses the components used to assemble and release the physical system; an implementation view addresses the configuration management of the system's releases, made up of somewhat independent components that can be assembled in various well-structured ways to produce a running system. • Deployment view • The view of a system's architecture that encompassesthe nodes the form the system's hardware topology on which the system executes; a deployment view addresses the distribution, delivery, and installation of the parts that make up the physical system. Ⓒ 2008 Grady Booch

48. Architecture metamodel Ⓒ 2008 Grady Booch

49. Architecture metamodel Ⓒ 2008 Grady Booch

50. Architecture metamodel Ⓒ 2008 Grady Booch