grady booch. the current state the typical software-intensive system is continuously evolving ...

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


Battlefield Management

12 Ⓒ 2008 Grady Booch 04/21/23


Cargo Routing

13 Ⓒ 2008 Grady Booch 04/21/23


Computational Chemistry

14 Ⓒ 2008 Grady Booch 04/21/23


Enterprise

15 Ⓒ 2008 Grady Booch 04/21/23


Games

16 Ⓒ 2008 Grady Booch 04/21/23


Games

17 Ⓒ 2008 Grady Booch 04/21/23


Google

18 Ⓒ 2008 Grady Booch 04/21/23

Linux

04/21/23 19 Ⓒ 2008 Grady Booch


MetLife

20 Ⓒ 2008 Grady Booch 04/21/23


Mobile Phone

21 Ⓒ 2008 Grady Booch 04/21/23


Mozilla

22 Ⓒ 2008 Grady Booch 04/21/23


Pathfinder

23 Ⓒ 2008 Grady Booch 04/21/23


Router

24 Ⓒ 2008 Grady Booch 04/21/23


Speech Recognition

25 Ⓒ 2008 Grady Booch 04/21/23


Washing Machine

26 Ⓒ 2008 Grady Booch 04/21/23


Web Server

27 Ⓒ 2008 Grady Booch 04/21/23


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:


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


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


49



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

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

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

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


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


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.


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.


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.


04/21/23 91 Ⓒ 2008 Grady Booch

Organization follows location The architectural partitioning should

reflect the geographic partitioning, and vice versa.


04/21/23 93 Ⓒ 2008 Grady Booch

Subsystem by skill

Birds of a feather flock together. Separate subsystems by staff skills and skill requirements.


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.


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


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


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

grady booch. the current state the typical software-intensive system is continuously evolving ...

Documents

grady booch architecture

grady booch atm

grady booch enterprise

grady booch cargo routing

systems architecture

systems of systemsservices

distributed teamsmost

significant design decisions