Best Practices in Software Architecture

1
Best Practices in Software Architecture

• Grady Booch

2
The Current State

• The typical software-intensive system is
• Continuously evolving
• Connected, distributed, concurrent
• Multilingual multiplatform
• Secure autonomic
• Developed by geographically- temporally-distribute
  d 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-m
apreduce-stats.html 2http//en.wikipedia.org/wiki/
Petabyte 3http//www.almaden.ibm.com/spinaps/resea
rch/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.ph
p
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

8
Architecture defined and defended
9
Fundamentals

• All architecture is design not all design is
  architecture. A systems 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.

10
Air Traffic Control
http//www.booch.com/architecture/architecture.jsp
?partGallery
11
ATM
http//www.booch.com/architecture/architecture.jsp
?partGallery
12
Battlefield Management
http//www.booch.com/architecture/architecture.jsp
?partGallery
13
Cargo Routing
http//www.booch.com/architecture/architecture.jsp
?partGallery
14
Computational Chemistry
http//www.booch.com/architecture/architecture.jsp
?partGallery
15
Enterprise
http//www.booch.com/architecture/architecture.jsp
?partGallery
16
Games
http//www.booch.com/architecture/architecture.jsp
?partGallery
17
Games
http//www.booch.com/architecture/architecture.jsp
?partGallery
18
Google
19
Linux
http//www.booch.com/architecture/architecture.jsp
?partGallery
20
MetLife
http//www.booch.com/architecture/architecture.jsp
?partGallery
21
Mobile Phone
http//www.booch.com/architecture/architecture.jsp
?partGallery
22
Mozilla
http//www.booch.com/architecture/architecture.jsp
?partGallery
23
Pathfinder
http//www.booch.com/architecture/architecture.jsp
?partGallery
24
Router
http//www.booch.com/architecture/architecture.jsp
?partGallery
25
Speech Recognition
http//www.booch.com/architecture/architecture.jsp
?partGallery
26
Washing Machine
http//www.booch.com/architecture/architecture.jsp
?partGallery
27
Web Server
http//www.booch.com/architecture/architecture.jsp
?partGallery
28
From vision to execution
http//www.gehrytechnologies.com/
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
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

31
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
32
Forces in software
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

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

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

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

37
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

38
The entire historyof software engineering is one
of rising levels of abstraction
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
Languages Platforms Processes Architecture Too
ls Enablement
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
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

41
Architecture best practices
42
Fundamentals

• Crisp abstractions
• Clear separation of concerns
• Balanced distribution of responsibilities
• Simplicity

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

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

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

46
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 41 Model View
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.

48
Architecture metamodel
49
Architecture metamodel
50
Architecture metamodel
51
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

52
What We Know We Dont Know

• We still dont have formal architectural
  representations that scale
• We dont yet have a good understanding of the
  architectural patterns that are found among
  domains.

53
Misconceptions About Architecture

• Architecture is just paper
• Architecture and design are the same things
• Architecture and infrastructure are the same
  things
• ltmy favorite technologygt 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
54
Sources of Architecture
Method
Method
Theft
Intuition
Theft
Intuition
Classical System
Unprecedented System
Kruchten
55
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.

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

57
Measuring architectural complexity

• SLOC
• For each view
• Number of things
• Number of patterns
• Rate of change over time

58
Economics of architecture first

• Architecture is an important artifact of
  governance
• Focusing on a systems 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

59
Process and governance
60
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
61
Process

• Grow a systems architecture through the
  incremental and iterative release of testable
  executables
• Architecture as an artifact of governance
• Stepwise refinement
• Focus on code

62
Governance

• Attack risk
• Measure progress
• Encourage innovation
• Enable simplification

63
Software archeology
64
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

65
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

66
Process of archeology

• Study of the source code
• Reverse engineering
• Probing and other instrumentation
• Review of existing documents
• Interviews with tribal leaders

67
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

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

69
Eclipse artifacts

• Eclipse Platform Technical Overview
• How to use the Eclipse API
• Eclipse Overview
• More detailed information exists for each of the
  subprojects.

70
Eclipse architecture
71
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

72
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
73
Eclipse logical view

• Plugin Development Environment (PDE)
• Workbench
• Team
• Debug
• Ant
• Help
• Java Development Tools (JDT)

74
SWT
75
JDT
76
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

77
Organizational patterns
78
Patterns

• Architect patterns
• Organizational patterns
• Architecture patterns
• Not included in this study
• Architecture patterns are design patterns writ
  large

79
Architect patterns
80
Coplien, Organizational Patterns of Agile
Development
81
Coplien, Organizational Patterns of Agile
Development
82
Coplien, Organizational Patterns of Agile
Development
83
Developer controls process

• Make the developer the focal point of process
  information.

Coplien, Organizational Patterns of Agile
Development, p. 71
84
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
85
Architect also implements

• Going forward, the project needs the necessary
  architectural breadth to cover its markets and to
  ensure smooth evolution, but it cant 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
86
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
87
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
88
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
89
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
90
Named stable bases

• It is important to integrate software frequently
  enough so that the base doesnt 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 versions
  functionality.

Coplien, Organizational Patterns of Agile
Development, p. 42
91
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
92
Conways law

• Make sure the organization is compatible with the
  product architecture.

Coplien, Organizational Patterns of Agile
Development, p. 192
93
Organization follows location

• The architectural partitioning should reflect the
  geographic partitioning, and vice versa.

Coplien, Organizational Patterns of Agile
Development, p. 195
94
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
95
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
96
Organizational patterns

• Big dripping hairball
• Senior designer
• Chief architect
• Architecture team
• Architecture control board

97
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)

98
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

99
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

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

101
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

102
Handbook and preservation
103
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
104

• Entertainment and Sports
• Disney Hall of the Presidents
• 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

• 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

• 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

105

• 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_at_home
• Transportation
• BMW
• British Rail
• CAATS
• Evans and Sutherland
• Fedex
• Ford

• 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

• Industrial
• Dow Chemical
• NERTO
• Toyota
•  Legal
• Identix
• Lexis/Nexis
• Supreme Court
• Medical
• Cogency
• Medtronics
• Philips
• Siemens
• Utilities
• AOL Messenger
• Babblefish
• Google
• Groove
• sendmail

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

http//www.computerhistory.org
107
Questions