grady booch l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Best Practices in Software Architecture PowerPoint Presentation
Download Presentation
Best Practices in Software Architecture

Loading in 2 Seconds...

play fullscreen
1 / 107

Best Practices in Software Architecture - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Best Practices in Software Architecture' - bell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the current state
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
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

growth of computational power
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

growth of connectivity
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

future software intensive systems
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
Agenda
  • Architecture defined and defended
  • Architecture best practices
  • Software archeology
  • Process and governance
  • Organizational patterns
  • Handbook and preservation

Ⓒ 2008 Grady Booch

fundamentals
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

air traffic control
Air Traffic Control

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

slide11
ATM

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

battlefield management
Battlefield Management

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

cargo routing
Cargo Routing

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

computational chemistry
Computational Chemistry

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

enterprise
Enterprise

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

games
Games

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

games17
Games

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

google
Google

Ⓒ 2008 Grady Booch

linux
Linux

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

metlife
MetLife

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

mobile phone
Mobile Phone

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

mozilla
Mozilla

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

pathfinder
Pathfinder

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

router
Router

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

speech recognition
Speech Recognition

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

washing machine
Washing Machine

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

web server
Web Server

http://www.booch.com/architecture/architecture.jsp?part=Gallery

Ⓒ 2008 Grady Booch

from vision to execution
From vision to execution

http://www.gehrytechnologies.com/

Ⓒ 2008 Grady Booch

movements on civil architecture
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

movements in web centric architectures
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

forces in civil architecture

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

forces in software
Forces in software

Ⓒ 2008 Grady Booch

patterns in physical systems
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

software patterns
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

physical systems
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

architecting software is different
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

the limits of software

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

slide38

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

architecture defined
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

why architecture
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

architecture best practices
Architecture best practices

Ⓒ 2008 Grady Booch

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

Ⓒ 2008 Grady Booch

what we know we know
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

definitions
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

architectural frameworks
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

representing software architecture

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

architectural views
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

architecture metamodel
Architecture metamodel

Ⓒ 2008 Grady Booch

architecture metamodel49
Architecture metamodel

Ⓒ 2008 Grady Booch

architecture metamodel50
Architecture metamodel

Ⓒ 2008 Grady Booch

what we are fairly certain we know
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

what we know we don t know
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

misconceptions about architecture
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

sources of architecture
Sources of Architecture

Method

Method

Theft

Intuition

Theft

Intuition

Classical System

Unprecedented System

Kruchten

Ⓒ 2008 Grady Booch

complex systems
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.”

Ⓒ 2008 Grady Booch

complex systems56
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

measuring architectural complexity
Measuring architectural complexity
  • SLOC
  • For each view
    • Number of things
    • Number of patterns
    • Rate of change over time

Ⓒ 2008 Grady Booch

economics of architecture first
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

process and governance
Process and governance

Ⓒ 2008 Grady Booch

fundamentals60
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

process
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

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

Ⓒ 2008 Grady Booch

software archeology
Software archeology

Ⓒ 2008 Grady Booch

software archeology64
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

why we dig
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

process of archeology
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

process of archeology67
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

eclipse
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

eclipse artifacts
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

eclipse architecture
Eclipse architecture

Ⓒ 2008 Grady Booch

eclipse use case view
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

eclipse logical view
Eclipse logical view
  • Plugin Development Environment (PDE)
  • Workbench
  • Team
  • Debug
  • Ant
  • Help
  • Java Development Tools (JDT)

Ⓒ 2008 Grady Booch

slide74
SWT

Ⓒ 2008 Grady Booch

slide75
JDT

Ⓒ 2008 Grady Booch

9 things to do with old software
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

organizational patterns
Organizational patterns

Ⓒ 2008 Grady Booch

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

Ⓒ 2008 Grady Booch

architect patterns
Architect patterns

Ⓒ 2008 Grady Booch

developer controls process
Developer controls process
  • Make the developer the focal point of process information.

Coplien, Organizational Patterns of Agile Development, p. 71

Ⓒ 2008 Grady Booch

architect controls product
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

architect also implements
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

architecture team
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

lock em up together
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

engage customers
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

stand up meeting
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

named stable bases
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

decouple stages
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

conway s law
Conway’s law
  • Make sure the organization is compatible with the product architecture.

Coplien, Organizational Patterns of Agile Development, p. 192

Ⓒ 2008 Grady Booch

organization follows location
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

subsystem by skill
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

feature assignment
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

organizational patterns96
Organizational patterns
  • Big dripping hairball
  • Senior designer
  • Chief architect
  • Architecture team
  • Architecture control board

Ⓒ 2008 Grady Booch

big dripping hairball
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

senior designer
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

chief architect
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

architecture team100
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

architecture control board
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

handbook and preservation
Handbook and preservation

Ⓒ 2008 Grady Booch

handbook of software architecture
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

slide104

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
    • Suunto watch
    • Triton
  • 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

Ⓒ 2008 Grady Booch

slide105

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
  • 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

Ⓒ 2008 Grady Booch

preservation of classic software
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

questions
Questions

Ⓒ 2008 Grady Booch