Docstoc

Architecture Organizational Patterns

Document Sample
Architecture Organizational Patterns Powered By Docstoc
					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
     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



                          Ⓒ 2008 Grady Booch   2/10/2012   7
Architecture defined and
defended




               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012   9
       Air Traffic Control




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   10   2/10/2012
       ATM




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   11   2/10/2012
       Battlefield Management




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   12   2/10/2012
       Cargo Routing




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   13   2/10/2012
       Computational Chemistry




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   14   2/10/2012
       Enterprise




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   15   2/10/2012
       Games




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   16   2/10/2012
       Games




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   17   2/10/2012
Google




         Ⓒ 2008 Grady Booch   18   2/10/2012
       Linux




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   2/10/2012   19
       MetLife




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   20   2/10/2012
       Mobile Phone




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   21   2/10/2012
       Mozilla




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   22   2/10/2012
       Pathfinder




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   23   2/10/2012
       Router




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   24   2/10/2012
       Speech Recognition




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   25   2/10/2012
       Washing Machine




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   26   2/10/2012
       Web Server




http://www.booch.com/architecture/architecture.jsp?part=Gallery
                                                             Ⓒ 2008 Grady Booch   27   2/10/2012
       From vision to execution




http://www.gehrytechnologies.com/
                                    Ⓒ 2008 Grady Booch   28   2/10/2012
     Movements on civil
     architecture
         Egyptian/Babylonian, Assyrian, Persian
                                                                    Progress
         Classical Indian                                              - Imitation of previous efforts
         Dynastic China                                                - Learning from failure
                                                                        - Integration of other forces
         Grecian/Roman
                                                                        - Experimentation
         Early Christian/Byzantine
         Islamic
         Romanesque
         Gothic
         Renaissance                                               Architects
                                                                        - Imhotep
         Palladian                                                     - Vitruvius
         Neoclassical                                                  - Michelangelo
                                                                        - Palladio
         Picturesque
                                                                        - Wright
         Mannerism                                                     - Wren
         Baroque                                                       - LeCorbusier
                                                                        - Geary
         Engineering/Rational/National/Romantic                        - Libeskind
         Art Noveau
         Modernism

Cole, The Grammar of Architecture
                                                   Ⓒ 2008 Grady Booch     29       2/10/2012
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   2/10/2012
       Forces in civil architecture

                Load
                                                                  Kinds of loads
                                                                  - Dead loads
                                                                  - Live loads
                                                                  - Dynamic loads
Compression                    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   2/10/2012
                                                                  31
Forces in software




               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012
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   2/10/2012
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   2/10/2012
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   2/10/2012
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                            Human

   The limits of human imagination
                          Ⓒ 2008 Grady Booch   37   2/10/2012
The entire history
of software engineering
is one of rising levels of abstraction
   Languages:     Assembly  Fortran/COBOL  Simula  C++  Java
    Platforms:    Naked HW  BIOS  OS  Middleware  Domain-specific
    Processes:    Waterfall  Spiral  Iterative  Agile
  Architecture:   Procedural  Object Oriented  Service Oriented
         Tools:   Early tools  CLE  IDE  XDE  CDE
  Enablement:     Individual  Workgroup  Organization




                                            Ⓒ 2008 Grady Booch   2/10/2012
                                                                 38
       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   2/10/2012
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   2/10/2012
Architecture best practices




               Ⓒ 2008 Grady Booch   2/10/2012   41
Fundamentals

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




                          Ⓒ 2008 Grady Booch   42   2/10/2012
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   2/10/2012
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   44   2/10/2012
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   2/10/2012   45
      Representing software
      architecture
                  Logical View                     Implementation View


      End-user                                                            Programmers
      Functionality                                           Configuration management
                                   Use Case View



                 Process View                       Deployment View
     System integrators                                                 System engineering
     Performance                                                            System topology
     Scalability                                                             Communication
     Throughput                                                                 Provisioning

                      Conceptual                           Physical

Kruchten, “The 4+1 Model View”
                                                   Ⓒ 2008 Grady Booch    2/10/2012
                                                                         46
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   47    2/10/2012
Architecture metamodel




               Ⓒ 2008 Grady Booch   2/10/2012
                                    48
Architecture metamodel




               Ⓒ 2008 Grady Booch   2/10/2012
                                    49
Architecture metamodel




               Ⓒ 2008 Grady Booch   2/10/2012
                                    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   2/10/2012
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   2/10/2012
      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   2/10/2012
      Sources of Architecture

             Method                                     Method

Theft                      Intuition   Theft                            Intuition




        Classical System                 Unprecedented System



Kruchten
                                         Ⓒ 2008 Grady Booch   54   2/10/2012
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   2/10/2012   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   2/10/2012   56
Measuring architectural
complexity
 SLOC
 For each view
   Number of things
   Number of patterns
   Rate of change over time




                               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012   58
Process and governance




               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012   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                         2/10/2012   61
Governance

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




Ⓒ 2008 Grady Booch         2/10/2012   62
Software archeology




               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012
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   2/10/2012
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   2/10/2012
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   2/10/2012
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   2/10/2012
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   2/10/2012
Eclipse architecture




               Ⓒ 2008 Grady Booch   70   2/10/2012
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   2/10/2012
Eclipse implementation view

ant.jar                  jdtcore.jar            servlets.jar
antrunner.jar            jface.jar              servlets-common.jar
antsupport.jar           jfacetext.jar          servlets-default.jar
antsupportlib.jar        jsp.jar                servlets-invoker.jar
appserver.jar            junit.jar              servlets-manager.jar
boot.jar                 junitsupport.jar       servlets-webdav.jar
bootstrap.jar            launching.jar          slimlauncher.jar
catalina.jar             launchingsupport.jar   snippetsupport.jar
commons-logging.jar      lucene-1.2.jar         startup.jar
compare.jar              naming-common.jar      swt.jar
cvs.jar                  naming-factory.jar     team.jar
dtcore.jar               naming-resources.jar   teamcvsssh.jar
dtui.jar                 optional.jar           teamcvsui.jar
editors.jar              parser.jar             tomcat-coyote.jar
externaltools.jar        pde.jar                tomcat-http11.jar
forms.jar                pde-ant.jar            tomcat-util.jar
help.jar                 pdebuild.jar           tomcatwrapper.jar
helpworkbench.jar        pdebuild-ant.jar       ui.jar
helpworkbenchwin32.jar   pdecore.jar            updatecore.jar
jakarta-regexp-1.2.jar   pdert.jar              update-servlets.jar
jasper-compiler.jar      pdeui.jar              updateui.jar
jasper-runtime.jar       pdeuiant.jar           update32.jar
jdi.jar                  resources.jar          versioncheck.jar
jdimodel.jar             resources-ant.jar      views.jar
jdui.jar                 runtime.jar            webapp.jar
jdt.jar                  search.jar             workbench.jar
jdtCompilerAdapter.jar   servlet.jar            workbenchwin32.jar


                                                                       72
Eclipse logical view

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


                        Ⓒ 2008 Grady Booch   73   2/10/2012
SWT




      Ⓒ 2008 Grady Booch   74   2/10/2012
JDT




      Ⓒ 2008 Grady Booch   75   2/10/2012
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   2/10/2012   76
Organizational patterns




               Ⓒ 2008 Grady Booch   2/10/2012   77
Patterns

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




                             Ⓒ 2008 Grady Booch   2/10/2012   78
Architect patterns




               Ⓒ 2008 Grady Booch   2/10/2012   79
Coplien, Organizational Patterns of Agile Development
                                                 Ⓒ 2008 Grady Booch   2/10/2012   80
Coplien, Organizational Patterns of Agile Development
                                                 Ⓒ 2008 Grady Booch   2/10/2012   81
Coplien, Organizational Patterns of Agile Development
                                                 Ⓒ 2008 Grady Booch   2/10/2012   82
     Developer controls process

       Make the developer the focal point of process
        information.




Coplien, Organizational Patterns of Agile Development, p. 71
                                                  Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   95
Organizational patterns

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




                          Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   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   2/10/2012   101
Handbook and preservation




               Ⓒ 2008 Grady Booch   2/10/2012   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   2/10/2012
   Artificial Intelligence      Content Authoring                  Entertainment and Sports
       Asimo                      Avid                                Disney Hall of the Presidents
       Avida
       Blondie24                  Massive                             Hong Kong Jockey Club
       CYC                        Microsoft Word                      NBC control room
       Swarm                      Photoshop                           Olympics
       Trilogy
                                   Renderman                           Spiderman
   Commercial and Non-Profit      Wall Street Journal                 Veri-Lite
       Amazon                     Yamaha                           Financial
       eBay
       Home Depot               Development                           Fedline bond system
       LDS                        Eclipse                             Great Plains
       Library of Congress                                             NYSE
                                   emacs
       Sabre
                                   JIT                                 Visa
       Starwood
       Ticketmaster                                                    Wells Fargo
                                 Devices
   Communications                                                   Games
       5ESS                       Bernini Artista
       911                        CocaCola                            Deep Blue
       Nokia                                                           Doom III
                                   Foveon camera
                                   General Electric                    StarCraft
                                                                        The Sims
                                   Hamilton Automation
                                   Otis
                                   Suunto watch
                                   Triton



                                                          Ⓒ 2008 Grady Booch   2/10/2012
                                                                               104
   Industrial            Military                        Scientific
        Dow Chemical       AEGIS                            ABI Prism
        NERTO              AWACS                            Earth Weather Simula
        Toyota                                               Jason
                            Bendix
   Legal                   Chyenne Mountain                 Mars Exploration Rover
        Identix                                              Mathematica
                            F16
        Lexis/Nexis                                          Mona Loa observatory
                            Force XXI
        Supreme Court
                            GPS                              National Data Buoy Center
   Medical                                                   National Ignition Facility
                            Pathfinder
        Cogency
                            Predator                         NavTech
        Medtronics
        Philips            Space Command                    Protein Data Bank
        Siemens                                              SETI@home
                          Operating Systems
   Utilities               Linux                         Transportation
        AOL Messenger                                        BMW
                            Palm OS
        Babblefish                                           British Rail
                            Wind River OS
        Google
                            Windows XP                       CAATS
        Groove
                                                              Evans and Sutherland
        sendmail         Platforms
                                                              Fedex
                            .NET
                                                              Ford
                            J2EE
                                                              NuTech
                                                              OOCL




                                                Ⓒ 2008 Grady Booch   2/10/2012
                                                                     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   2/10/2012
                                                                    106
Questions




            Ⓒ 2008 Grady Booch   2/10/2012   107

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:2/10/2012
language:English
pages:107