Transcript presentation - CEE

Grady Booch
BEST PRACTICES IN SOFTWARE
ARCHITECTURE
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.html
2http://en.wikipedia.org/wiki/Petabyte
3http://www.almaden.ibm.com/spinaps/research/sd/?racetrack

Growth Of Computational
Power power is abundant
Computational
 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
Ⓒ 2008 Grady Booch
7/21/2015
7
Architecture defined and
defended
Ⓒ 2008 Grady Booch
7/21/2015
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.
Ⓒ 2008 Grady Booch
7/21/2015
9
Air Traffic Control
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
10
7/21/2015
ATM
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
11
7/21/2015
Battlefield Management
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
12
7/21/2015
Cargo Routing
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
13
7/21/2015
Computational Chemistry
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
14
7/21/2015
Enterprise
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
15
7/21/2015
Games
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
16
7/21/2015
Games
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
17
7/21/2015
Google
Ⓒ 2008 Grady Booch
18
7/21/2015
Linux
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
7/21/2015
19
MetLife
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
20
7/21/2015
Mobile Phone
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
21
7/21/2015
Mozilla
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
22
7/21/2015
Pathfinder
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
23
7/21/2015
Router
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
24
7/21/2015
Speech Recognition
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
25
7/21/2015
Washing Machine
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
26
7/21/2015
Web Server
http://www.booch.com/architecture/architecture.jsp?part=Gallery
Ⓒ 2008 Grady Booch
27
7/21/2015
From vision to execution
http://www.gehrytechnologies.com/
Ⓒ 2008 Grady Booch
28
7/21/2015
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
29
7/21/2015
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
30
7/21/2015
Forces in civil architecture
Load
Compression
Kinds of loads
- Dead loads
- Live loads
- Dynamic loads
Tension
Avoiding failure
- Safety factors
- Redundancy
- Equilibrium
Load
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
31
7/21/2015
Forces in software
Ⓒ 2008 Grady Booch
7/21/2015
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
Ⓒ 2008 Grady Booch
33
7/21/2015
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
34
7/21/2015
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
35
7/21/2015
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
36
7/21/2015
The limits of software









Fundamental
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
Human
37
7/21/2015
The entire history
of 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
38
7/21/2015
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
39
7/21/2015
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
40
7/21/2015
Architecture best practices
Ⓒ 2008 Grady Booch
7/21/2015
41
Fundamentals
 Crisp abstractions
 Clear separation of concerns
 Balanced distribution of responsibilities
 Simplicity
Ⓒ 2008 Grady Booch
42
7/21/2015
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
43
7/21/2015
Definitions

Architecture


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


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).
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
44
7/21/2015
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
7/21/2015
45
Representing software
architecture
Logical View
End-user
Functionality
Implementation View
Use Case View
Process View
Programmers
Configuration management
Deployment View
System integrators
Performance
Scalability
Throughput
Conceptual
System engineering
System topology
Communication
Provisioning
Physical
Kruchten, “The 4+1 Model View”
Ⓒ 2008 Grady Booch
7/21/2015
46
Architectural views

Use case view


Logical 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 physical place where a system is developed, used, or deployed.
Process 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.
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
47
7/21/2015
Architecture metamodel
Ⓒ 2008 Grady Booch
7/21/2015
48
Architecture metamodel
Ⓒ 2008 Grady Booch
7/21/2015
49
Architecture metamodel
Ⓒ 2008 Grady Booch
7/21/2015
50
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
Ⓒ 2008 Grady Booch
51
7/21/2015
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.
Ⓒ 2008 Grady Booch
52
7/21/2015
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
Kruchten
Ⓒ 2008 Grady Booch
53
7/21/2015
Sources of Architecture
Method
Theft
Method
Intuition
Classical System
Theft
Intuition
Unprecedented System
Kruchten
Ⓒ 2008 Grady Booch
54
7/21/2015
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 selforganization.”
 “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.”
Ⓒ 2008 Grady Booch
7/21/2015
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.”
Ⓒ 2008 Grady Booch
7/21/2015
56
Measuring architectural
complexity
 SLOC
 For each view
 Number of things
 Number of patterns
 Rate of change over time
Ⓒ 2008 Grady Booch
7/21/2015
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
Ⓒ 2008 Grady Booch
7/21/2015
58
Process and governance
Ⓒ 2008 Grady Booch
7/21/2015
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
Ⓒ 2008 Grady Booch
7/21/2015
60
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
Ⓒ 2008 Grady Booch
7/21/2015
61
Governance
 Attack risk
 Measure progress
 Encourage innovation
 Enable simplification
Ⓒ 2008 Grady Booch
7/21/2015
62
Software archeology
Ⓒ 2008 Grady Booch
7/21/2015
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
Ⓒ 2008 Grady Booch
64
7/21/2015
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
Ⓒ 2008 Grady Booch
65
7/21/2015
Process of archeology
 Study of the source code
 Reverse engineering
 Probing and other instrumentation
 Review of existing documents
 Interviews with tribal leaders
Ⓒ 2008 Grady Booch
66
7/21/2015
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 still
Ⓒ 2008 Grady Booch
67
7/21/2015
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.
Ⓒ 2008 Grady Booch
68
7/21/2015
Eclipse artifacts
 Eclipse Platform Technical Overview
 How to use the Eclipse API
 Eclipse Overview
 More detailed information exists for each of
the subprojects.
Ⓒ 2008 Grady Booch
69
7/21/2015
Eclipse architecture
Ⓒ 2008 Grady Booch
70
7/21/2015
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
Ⓒ 2008 Grady Booch
71
7/21/2015
Eclipse implementation view
ant.jar
antrunner.jar
antsupport.jar
antsupportlib.jar
appserver.jar
boot.jar
bootstrap.jar
catalina.jar
commons-logging.jar
compare.jar
cvs.jar
dtcore.jar
dtui.jar
editors.jar
externaltools.jar
forms.jar
help.jar
helpworkbench.jar
helpworkbenchwin32.jar
jakarta-regexp-1.2.jar
jasper-compiler.jar
jasper-runtime.jar
jdi.jar
jdimodel.jar
jdui.jar
jdt.jar
jdtCompilerAdapter.jar
jdtcore.jar
jface.jar
jfacetext.jar
jsp.jar
junit.jar
junitsupport.jar
launching.jar
launchingsupport.jar
lucene-1.2.jar
naming-common.jar
naming-factory.jar
naming-resources.jar
optional.jar
parser.jar
pde.jar
pde-ant.jar
pdebuild.jar
pdebuild-ant.jar
pdecore.jar
pdert.jar
pdeui.jar
pdeuiant.jar
resources.jar
resources-ant.jar
runtime.jar
search.jar
servlet.jar
servlets.jar
servlets-common.jar
servlets-default.jar
servlets-invoker.jar
servlets-manager.jar
servlets-webdav.jar
slimlauncher.jar
snippetsupport.jar
startup.jar
swt.jar
team.jar
teamcvsssh.jar
teamcvsui.jar
tomcat-coyote.jar
tomcat-http11.jar
tomcat-util.jar
tomcatwrapper.jar
ui.jar
updatecore.jar
update-servlets.jar
updateui.jar
update32.jar
versioncheck.jar
views.jar
webapp.jar
workbench.jar
workbenchwin32.jar
72
Eclipse logical view
 Plugin Development Environment (PDE)
 Workbench
 Team
 Debug
 Ant
 Help
 Java Development Tools (JDT)
Ⓒ 2008 Grady Booch
73
7/21/2015
SWT
Ⓒ 2008 Grady Booch
74
7/21/2015
JDT
Ⓒ 2008 Grady Booch
75
7/21/2015
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
Ⓒ 2008 Grady Booch
7/21/2015
76
Organizational patterns
Ⓒ 2008 Grady Booch
7/21/2015
77
Patterns
 Architect patterns
 Organizational patterns
 Architecture patterns
 Not included in this study
 Architecture patterns are design patterns writ
large
Ⓒ 2008 Grady Booch
7/21/2015
78
Architect patterns
Ⓒ 2008 Grady Booch
7/21/2015
79
Coplien, Organizational Patterns of Agile Development
Ⓒ 2008 Grady Booch
7/21/2015
80
Coplien, Organizational Patterns of Agile Development
Ⓒ 2008 Grady Booch
7/21/2015
81
Coplien, Organizational Patterns of Agile Development
Ⓒ 2008 Grady Booch
7/21/2015
82
Developer controls process
 Make the developer the focal point of process
information.
Coplien, Organizational Patterns of Agile Development, p. 71
Ⓒ 2008 Grady Booch
7/21/2015
83
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
Ⓒ 2008 Grady Booch
7/21/2015
84
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
Ⓒ 2008 Grady Booch
7/21/2015
85
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
Ⓒ 2008 Grady Booch
7/21/2015
86
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
Ⓒ 2008 Grady Booch
7/21/2015
87
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
Ⓒ 2008 Grady Booch
7/21/2015
88
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
Ⓒ 2008 Grady Booch
7/21/2015
89
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
Ⓒ 2008 Grady Booch
7/21/2015
90
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
Ⓒ 2008 Grady Booch
7/21/2015
91
Conway’s law
 Make sure the organization is compatible
with the product architecture.
Coplien, Organizational Patterns of Agile Development, p. 192
Ⓒ 2008 Grady Booch
7/21/2015
92
Organization follows
location
 The architectural partitioning should reflect
the geographic partitioning, and vice versa.
Coplien, Organizational Patterns of Agile Development, p. 195
Ⓒ 2008 Grady Booch
7/21/2015
93
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
Ⓒ 2008 Grady Booch
7/21/2015
94
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
Ⓒ 2008 Grady Booch
7/21/2015
95
Organizational patterns
 Big dripping hairball
 Senior designer
 Chief architect
 Architecture team
 Architecture control board
Ⓒ 2008 Grady Booch
7/21/2015
96
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)
Ⓒ 2008 Grady Booch
7/21/2015
97
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
Ⓒ 2008 Grady Booch
7/21/2015
98
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
Ⓒ 2008 Grady Booch
7/21/2015
99
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.
Ⓒ 2008 Grady Booch
7/21/2015
100
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
Ⓒ 2008 Grady Booch
7/21/2015
101
Handbook and preservation
Ⓒ 2008 Grady Booch
7/21/2015
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 curiosity
http://www.booch.com/architecture
Ⓒ 2008 Grady Booch
103
7/21/2015

Artificial Intelligence







Commercial and Non-Profit









Asimo
Avida
Blondie24
CYC
Swarm
Trilogy
Amazon
eBay
Home Depot
LDS
Library of Congress
Sabre
Starwood
Ticketmaster
Communications



5ESS
911
Nokia
 Content Authoring
 Entertainment and Sports
 Avid
 Disney Hall of the Presidents
 Massive
 Hong Kong Jockey Club
 Microsoft Word
 NBC control room
 Photoshop
 Olympics
 Renderman
 Spiderman
 Wall Street Journal
 Veri-Lite
 Yamaha
 Development
 Financial
 Fedline bond system
 Eclipse
 Great Plains
 emacs
 NYSE
 JIT
 Visa
 Devices
 Bernini Artista
 Wells Fargo
 Games
 CocaCola
 Deep Blue
 Foveon camera
 Doom III
 General Electric
 StarCraft
 Hamilton Automation
 The Sims
 Otis
 Suunto watch
 Triton
Ⓒ 2008 Grady Booch
7/21/2015
104

Industrial




Legal




Identix
Lexis/Nexis
Supreme Court
Medical





Dow Chemical
NERTO
Toyota
Cogency
Medtronics
Philips
Siemens
Utilities





AOL Messenger
Babblefish
Google
Groove
sendmail
 Military
 Scientific
 AEGIS
 ABI Prism
 AWACS
 Earth Weather Simula
 Bendix
 Jason
 Chyenne Mountain
 Mars Exploration Rover
 F16
 Mathematica
 Force XXI
 Mona Loa observatory
 GPS
 National Data Buoy Center
 Pathfinder
 National Ignition Facility
 Predator
 NavTech
 Space Command
 Protein Data Bank
 Operating Systems
 Linux
 SETI@home
 Transportation
 Palm OS
 BMW
 Wind River OS
 British Rail
 Windows XP
 CAATS
 Platforms
 .NET
 J2EE
 Evans and Sutherland
 Fedex
 Ford
 NuTech
 OOCL
Ⓒ 2008 Grady Booch
7/21/2015
105
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
http://www.computerhistory.org
Ⓒ 2008 Grady Booch
7/21/2015
106
Questions
Ⓒ 2008 Grady Booch
7/21/2015
107