Grady Booch
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
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
1http://www.niallkennedy.com/blog/2008/01/google-mapreduce-stats.html2http://en.wikipedia.org/wiki/Petabyte3http://www.almaden.ibm.com/spinaps/research/sd/?racetrack
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
1http://en.wikipedia.org/wiki/FLOPS
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
1http://www.bgpexpert.com/addressespercountry.php
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
Agenda
Architecture defined and defended Architecture best practices Software archeology Process and governance Organizational patterns Handbook and preservation
04/21/23 Ⓒ 2008 Grady Booch 7
Architecture defined and defended
04/21/23 Ⓒ 2008 Grady Booch 8
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.
04/21/23 9 Ⓒ 2008 Grady Booch
Air Traffic Control
10 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
ATM
11 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Battlefield Management
12 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Cargo Routing
13 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Computational Chemistry
14 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Enterprise
15 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Games
16 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Games
17 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
18 Ⓒ 2008 Grady Booch 04/21/23
Linux
04/21/23 19 Ⓒ 2008 Grady Booch
http://www.booch.com/architecture/architecture.jsp?part=Gallery
MetLife
20 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Mobile Phone
21 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Mozilla
22 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Pathfinder
23 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Router
24 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Speech Recognition
25 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Washing Machine
26 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Web Server
27 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture/architecture.jsp?part=Gallery
From vision to execution
28 Ⓒ 2008 Grady Booch 04/21/23
http://www.gehrytechnologies.com/
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
29 Ⓒ 2008 Grady Booch 04/21/23
Progress - Imitation of previous efforts - Learning from failure - Integration of other forces - Experimentation
Cole, The Grammar of Architecture
Architects - Imhotep - Vitruvius - Michelangelo - Palladio - Wright - Wren - LeCorbusier - Geary - Libeskind
Movements in web-centric architectures Simple documents Colorful clients Simple scripting Rise of middleware Rise of simple frameworks Emergence of dynamic frameworks Semantic web
30 Ⓒ 2008 Grady Booch 04/21/23
31
Forces in civil architecture
Avoiding failure - Safety factors - Redundancy - Equilibrium
Compression
Load
Tension
Load
Kinds of loads - Dead loads - Live loads - Dynamic loads
Any time you depart from established practice, make ten times theeffort, ten times the investigation. Especially on a very large project. - LeMessuier
04/21/23 Ⓒ 2008 Grady Booch
Forces in software
04/21/23 Ⓒ 2008 Grady Booch 32
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
33 Ⓒ 2008 Grady Booch 04/21/23
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
34 Ⓒ 2008 Grady Booch 04/21/23
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
35 Ⓒ 2008 Grady Booch 04/21/23
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
36 Ⓒ 2008 Grady Booch 04/21/23
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
37 Ⓒ 2008 Grady Booch 04/21/23
Fundamental
Human
38
The entire historyof software engineeringis one of rising levels of abstraction
Assembly Fortran/COBOL Simula C++ JavaNaked HW BIOS OS Middleware Domain-specificWaterfall Spiral Iterative AgileProcedural Object Oriented Service Oriented Early tools CLE IDE XDE CDEIndividual Workgroup Organization
Languages:Platforms:Processes:
Architecture:Tools:
Enablement:
04/21/23 Ⓒ 2008 Grady Booch
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
39 Ⓒ 2008 Grady Booch 04/21/23
Source: Booch, Kruchten, Reitman, Bittner, and Shaw
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
40 Ⓒ 2008 Grady Booch 04/21/23
Architecture best practices
04/21/23 Ⓒ 2008 Grady Booch 41
Fundamentals
Crisp abstractions Clear separation of concerns Balanced distribution of
responsibilities Simplicity
42 Ⓒ 2008 Grady Booch 04/21/23
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
43 Ⓒ 2008 Grady Booch 04/21/23
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).
44 Ⓒ 2008 Grady Booch 04/21/23
Architectural frameworks
AGATE DoD Architecture Framework Federal Enterprise Architecture MoD Architecture Framework Reference Model of Open Distributed
Computing Open Group Architecture Framework Zachman Framework
04/21/23 Ⓒ 2008 Grady Booch 45
46
Representing software architecture
Kruchten, “The 4+1 Model View”
Logical View
End-user Functionality
Implementation View
Programmers Configuration management
Process View
PerformanceScalabilityThroughput
System integrators
Deployment View
System topologyCommunication
Provisioning
System engineering
Conceptual
Physical
Use Case View
04/21/23 Ⓒ 2008 Grady Booch
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.
47 Ⓒ 2008 Grady Booch 04/21/23
48
Architecture metamodel
04/21/23 Ⓒ 2008 Grady Booch
49
Architecture metamodel
04/21/23 Ⓒ 2008 Grady Booch
50
Architecture metamodel
04/21/23 Ⓒ 2008 Grady Booch
What We Are Fairly Certain We Know We are starting to develop a
profession of software architecture We are starting to see the
emergence of domain-specific software architectures
51 Ⓒ 2008 Grady Booch 04/21/23
What We Know We Don’t Know We still don’t have formal
architectural representations that scale
We don’t yet have a good understanding of the architectural patterns that are found among domains.
52 Ⓒ 2008 Grady Booch 04/21/23
Misconceptions About Architecture Architecture is just paper Architecture and design are the same things Architecture and infrastructure are the same things <my favorite technology> is the architecture A good architecture is the work of a single architect Architecture is simply structure Architecture can be represented in a single
blueprint System architecture precedes software architecture Architecture cannot be measured or validated Architecture is a science Architecture is an art
53 Ⓒ 2008 Grady Booch 04/21/23
Kruchten
Sources of Architecture
54 Ⓒ 2008 Grady Booch 04/21/23
Theft
Method
Intuition
Classical System Unprecedented System
Theft
Method
Intuition
Kruchten
Complex systems
From Complexity by Mitchell Waldrop “A great many independent agents are
interacting with each other in a great many ways.”
“The very richness of these interactions allows the system as a whole to undergo spontaneous self-organization.”
“These complex, self-organizing systems are adaptive.”
“All these complex systems have somehow acquired the ability to bring order and chaos into a special kind of balance.”
04/21/23 Ⓒ 2008 Grady Booch 55
Complex systems
From Sciences of the Artificialby Herbert Simon “Hierarchic systems are usually composed of
only a few different kinds of subsystems in various combinations and arrangements.”
“Hierarch systems are … often nearly decomposable. Hence only aggregative properties of their parts enter into the description of the interactions of those parts.”
“By appropriate ‘recoding’ the redundancy that is present but unobvious in the structure of a complex system can often be made patent.”
04/21/23 Ⓒ 2008 Grady Booch 56
Measuring architectural complexity SLOC For each view
Number of things Number of patterns Rate of change over time
04/21/23 Ⓒ 2008 Grady Booch 57
Economics of architecture first Architecture is an important artifact of
governance Focusing on a system’s architecture
provides a means of intentional simplification
Devising a sound software-intensive architecture is essential to building systems that are resilient to change
Well-architected systems make possible the creation of software product lines
Intentional architectures serve to preserve critical intellectual property and reduce the quantity of tribal memory
04/21/23 Ⓒ 2008 Grady Booch 58
Process and governance
04/21/23 Ⓒ 2008 Grady Booch 59
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
04/21/23 60 Ⓒ 2008 Grady Booch
Process
Grow a system’s architecture through the incremental and iterative release of testable executables Architecture as an artifact of governance Stepwise refinement Focus on code
04/21/23 Ⓒ 2008 Grady Booch 61
Governance
Attack risk Measure progress Encourage innovation Enable simplification
04/21/23 Ⓒ 2008 Grady Booch 62
Software archeology
04/21/23 Ⓒ 2008 Grady Booch 63
Software archeology
The recovery of essential details about an existing system sufficient to reason about, fix, adapt, modify, harvest, and use that system itself or its parts
64 Ⓒ 2008 Grady Booch 04/21/23
Why we dig
To reason about CAATS
To fix Y2K
To adapt Homeland Security
To modify JPL Mars Rovers
To harvest Patriot Missile System
To use AWACS Mid-term modernization
65 Ⓒ 2008 Grady Booch 04/21/23
Process of archeology
Study of the source code Reverse engineering Probing and other instrumentation Review of existing documents Interviews with tribal leaders
66 Ⓒ 2008 Grady Booch 04/21/23
Process of archeology
Most design information lives in tribal memory
Typically there exists very high level architectural views and very low level design views, but little in between
Reconstructing deployment and implementation views is easy
Reconstructing the use case view is possible
Reconstructing the logical and process views is hard
Harvesting patterns is harder still67 Ⓒ 2008 Grady Booch 04/21/23
Eclipse
www.eclipse.org Eclipse was started about 2 yrs go -
when IBM made a $40M contribution to the main code base – but is now an independent entity
The principal architects are John Wiegand, Dave Thomson, John Duimovich all part of the OTI team which jump-started Eclipse.
68 Ⓒ 2008 Grady Booch 04/21/23
Eclipse artifacts
Eclipse Platform Technical Overview How to use the Eclipse API Eclipse Overview More detailed information exists for
each of the subprojects.
69 Ⓒ 2008 Grady Booch 04/21/23
Eclipse architecture
70 Ⓒ 2008 Grady Booch 04/21/23
Eclipse use case view
Check In/Out Resource Close Perspective Close Window Display Help Invoke New Tool Open Perspective Open Window Refresh Workspace Shutdown Workbench Startup Workbench
71 Ⓒ 2008 Grady Booch 04/21/23
Eclipse implementation viewant.jarantrunner.jarantsupport.jarantsupportlib.jarappserver.jarboot.jarbootstrap.jarcatalina.jarcommons-logging.jarcompare.jarcvs.jardtcore.jardtui.jareditors.jarexternaltools.jarforms.jarhelp.jarhelpworkbench.jarhelpworkbenchwin32.jarjakarta-regexp-1.2.jarjasper-compiler.jarjasper-runtime.jarjdi.jarjdimodel.jarjdui.jarjdt.jarjdtCompilerAdapter.jar
jdtcore.jarjface.jarjfacetext.jarjsp.jarjunit.jarjunitsupport.jarlaunching.jarlaunchingsupport.jarlucene-1.2.jarnaming-common.jarnaming-factory.jarnaming-resources.jaroptional.jarparser.jarpde.jarpde-ant.jarpdebuild.jarpdebuild-ant.jarpdecore.jarpdert.jarpdeui.jarpdeuiant.jarresources.jarresources-ant.jarruntime.jarsearch.jarservlet.jar
servlets.jarservlets-common.jarservlets-default.jarservlets-invoker.jarservlets-manager.jarservlets-webdav.jarslimlauncher.jarsnippetsupport.jarstartup.jarswt.jarteam.jarteamcvsssh.jarteamcvsui.jartomcat-coyote.jartomcat-http11.jartomcat-util.jartomcatwrapper.jarui.jarupdatecore.jarupdate-servlets.jarupdateui.jarupdate32.jarversioncheck.jarviews.jarwebapp.jarworkbench.jarworkbenchwin32.jar
72
Eclipse logical view
Plugin Development Environment (PDE)
Workbench Team Debug Ant Help Java Development Tools (JDT)
73 Ⓒ 2008 Grady Booch 04/21/23
SWT
74 Ⓒ 2008 Grady Booch 04/21/23
JDT
75 Ⓒ 2008 Grady Booch 04/21/23
9 Things To Do With Old Software Abandon it Give it away Ignore it Put it on life support Rewrite it Harvest from it Wrap it up Transform it Preserve it
04/21/23 Ⓒ 2008 Grady Booch 76
Organizational patterns
04/21/23 Ⓒ 2008 Grady Booch 77
Patterns
Architect patterns Organizational patterns Architecture patterns
Not included in this study Architecture patterns are design
patterns writ large
04/21/23 78 Ⓒ 2008 Grady Booch
Architect patterns
04/21/23 79 Ⓒ 2008 Grady Booch
Coplien, Organizational Patterns of Agile Development04/21/23 80 Ⓒ 2008 Grady Booch
Coplien, Organizational Patterns of Agile Development
04/21/23 81 Ⓒ 2008 Grady Booch
Coplien, Organizational Patterns of Agile Development
04/21/23 82 Ⓒ 2008 Grady Booch
Developer controls process Make the developer the focal point of
process information.
Coplien, Organizational Patterns of Agile Development, p. 71
04/21/23 83 Ⓒ 2008 Grady Booch
Architect controls product Even though a product is designed
by many individuals, a project must strive to give the product elegance and cohesiveness. Create an architect role as an embodiment of the principles that define an architectural style for the project and of the broad domain expertise that legitimizes such a style
Coplien, Organizational Patterns of Agile Development, p. 239
04/21/23 84 Ⓒ 2008 Grady Booch
Architect also implements Going forward, the project needs the
necessary architectural breadth to cover its markets and to ensure smooth evolution, but it can’t be blindsided by pragmatic engineering and implementation concerns. Beyond advising and communicating with Developers, Architects should also participate in implementation.
Coplien, Organizational Patterns of Agile Development, pp. 254-255
04/21/23 85 Ⓒ 2008 Grady Booch
Architecture team
You need to create an architecture that is simple and cohesive, but that also accommodates a variety of constituencies. Create a small team of “resonating minds” to define the initial architecture in such a way that the team covers the expected partitioning of the system.
Coplien, Organizational Patterns of Agile Development, pp. 241-242
04/21/23 86 Ⓒ 2008 Grady Booch
Lock ‘em up together
A team of diverse people must come up with a single, coherent architecture. Gather domain experts together in the same room to work out the architecture (or other strategic issues).
Coplien, Organizational Patterns of Agile Development, p. 243
04/21/23 87 Ⓒ 2008 Grady Booch
Engage customers
Closely couple the Customer role with the Developer and Architect roles, not just with QA or marketing roles. In short, developers and architects must talk freely and often with customers. When possible, engage customers in their own environment rather than bringing them into your environment.
Coplien, Organizational Patterns of Agile Development, p. 113
04/21/23 88 Ⓒ 2008 Grady Booch
Stand up meeting
Hold short daily meetings with the entire team to exchange critical information, update status, and/or make assignments. The meetings should last no more than 15 minutes and generally should happen first thing in the morning. The focus of the meetings is on the technical progress in the architecture and in the work plan.Coplien, Organizational Patterns of Agile Development, p. 248
04/21/23 89 Ⓒ 2008 Grady Booch
Named stable bases
It is important to integrate software frequently enough so that the base doesn’t become stale, but not so frequently that you damage a shared understanding of what functionality is sound and trusted in an evolving software base. Stabilize systems interfaces – the architecture – about once a week. Give the stable system a name of some kind by which developers can identify their shared understanding of that version’s functionality.
Coplien, Organizational Patterns of Agile Development, p. 42
04/21/23 90 Ⓒ 2008 Grady Booch
Decouple stages
Development stages should be independent to reduce coupling and to promote the autonomy of teams and developers. For known and mature domains, serialize the steps.
Coplien, Organizational Patterns of Agile Development, p. 217
04/21/23 91 Ⓒ 2008 Grady Booch
Conway’s law
Make sure the organization is compatible with the product architecture.
Coplien, Organizational Patterns of Agile Development, p. 192
04/21/23 92 Ⓒ 2008 Grady Booch
Organization follows location The architectural partitioning should
reflect the geographic partitioning, and vice versa.
Coplien, Organizational Patterns of Agile Development, p. 195
04/21/23 93 Ⓒ 2008 Grady Booch
Subsystem by skill
Birds of a feather flock together. Separate subsystems by staff skills and skill requirements.
Coplien, Organizational Patterns of Agile Development, p. 153
04/21/23 94 Ⓒ 2008 Grady Booch
Feature assignment
For every nontrivial project, it is impossible to partition the work cleanly. Assign features to people for development. Feature development has a finite duration and is, therefore, an assignment, not a role.
Coplien, Organizational Patterns of Agile Development, p. 265
04/21/23 95 Ⓒ 2008 Grady Booch
Organizational patterns
Big dripping hairball Senior designer Chief architect Architecture team Architecture control board
04/21/23 96 Ⓒ 2008 Grady Booch
Big dripping hairball
Architecture is entirely accidental Appropriate for small systems with
short half-life Appropriate to new systems
requiring intense innovation In such cases, experience is often/should
be harvested from the initial system and then applied to a more structured process (with the original system thrown away)
04/21/23 97 Ⓒ 2008 Grady Booch
Senior designer
Architecture is incrementally more intentional, drawn from the experience of the senior designer
Appropriate for small to modest-sized systems with modest half-life
Appropriate to new systems requiring modest innovation
04/21/23 98 Ⓒ 2008 Grady Booch
Chief architect
The architecture is incrementally more intentional, because the risk is much higher
Appropriate for modest to large systems with modest to long half-life
Appropriate to brownfield systems requiring transformation
04/21/23 99 Ⓒ 2008 Grady Booch
Architecture team
The architecture is quite intentional Appropriate to large, complex
software-intensive systems with high risk
Appropriate to systems with many technical, contextual, business, and economic dimensions.
04/21/23 100
Ⓒ 2008 Grady Booch
Architecture control board Architecture is fully intentional Appropriate to very large systems-of-
systems with deep economic weight Appropriate to systems formed of
many systems, some new, many old, and all largely in flux
04/21/23 101
Ⓒ 2008 Grady Booch
Handbook and preservation
04/21/23 Ⓒ 2008 Grady Booch 102
Handbook of Software Architecture No architectural reference exists for
software-intensive systems Goals of the handbook
Codify the architecture of a large collection of interesting software-intensive systems
Study these architectural patterns in the context of the engineering forces that shaped them
Satisfy my curiosity103 Ⓒ 2008 Grady Booch 04/21/23
http://www.booch.com/architecture
104
Artificial Intelligence Asimo Avida Blondie24 CYC Swarm Trilogy
Commercial and Non-Profit Amazon eBay Home Depot LDS Library of Congress Sabre Starwood Ticketmaster
Communications 5ESS 911 Nokia
Content Authoring Avid Massive Microsoft Word Photoshop Renderman Wall Street Journal Yamaha
Development Eclipse emacs JIT
Devices Bernini Artista CocaCola Foveon camera General Electric Hamilton Automation Otis Suunto watch Triton
Entertainment and Sports Disney Hall of the Presiden
ts
Hong Kong Jockey Club NBC control room Olympics Spiderman Veri-Lite
Financial Fedline bond system Great Plains NYSE Visa Wells Fargo
Games Deep Blue Doom III StarCraft The Sims
04/21/23 Ⓒ 2008 Grady Booch
105
Industrial Dow Chemical NERTO Toyota
Legal Identix Lexis/Nexis Supreme Court
Medical Cogency Medtronics Philips Siemens
Utilities AOL Messenger Babblefish Google Groove sendmail
Military AEGIS AWACS Bendix Chyenne Mountain F16 Force XXI GPS Pathfinder Predator Space Command
Operating Systems Linux Palm OS Wind River OS Windows XP
Platforms .NET
J2EE
Scientific ABI Prism Earth Weather Simula Jason Mars Exploration Rover Mathematica Mona Loa observatory National Data Buoy Center National Ignition Facility NavTech Protein Data Bank SETI@home
Transportation BMW British Rail CAATS Evans and Sutherland Fedex Ford NuTech OOCL
04/21/23 Ⓒ 2008 Grady Booch
106
Preservation of Classic Software No comprehensive and intentional activity has yet been
undertaken to preserve software artifacts There are a number of reasons to act now
Many of the authors of seminal systems are still alive Many others may have the source code or design
documents for these systems collecting dust in their offices or garages
Time is our enemy: over time, these artifacts will become lost forever
04/21/23 Ⓒ 2008 Grady Booch
http://www.computerhistory.org
Questions
04/21/23 Ⓒ 2008 Grady Booch 107