Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Kirk Knoernschild
Analyst, SDLC and Containers,
                                       Agile Architecture - Patterns & Tec...
Agile Architecture                                              2




                 The Law of Two Feet




           ...
Agile Architecture       3




 Defining Architecture
 Modularity
 The Patterns
 Patterns Applied
Agile Architecture       3




 Defining Architecture
 Modularity
 The Patterns
 Patterns Applied
Agile Architecture                              4




          Defining Architecture

What                         What  ...
Defining Architecture                                       5




     Preliminary Thoughts
      • Architects architect a...
Defining Architecture                                                        6




What is Architecture?
• An architecture...
Defining Architecture                                                       7




What is Architecture?
• In most successf...
Defining Architecture                             8




What is Architecture?
• The fundamental organization of a system, ...
Defining Architecture                                                       9




What is Architecture?
• A formal descrip...
Defining Architecture                                                        10




What is Architecture?
• Architecture e...
Defining Architecture   11




The Goal of Architecture
Defining Architecture                  11




The Goal of Architecture
                                  What if we were
 ...
Defining Architecture                     11




The Goal of Architecture
                                   What if we we...
Defining Architecture                                      12




     Architecture Paradox

                             ...
Defining Architecture                                         12




     Architecture Paradox


                         ...
Defining Architecture                                           13




I contend...
• Architecture requires modularity
   ...
Agile Architecture                                               14




                             Modularity

What     ...
Modularity                                                 15




Defining Module

                  Hey, it’s a JAR file!
...
Modularity                                                 15




Defining Module

                  Hey, it’s a JAR file!
...
Modularity     16




      Advantages of Modularity


    - reus
           e
   - re du
          ce co m
  - ease      ...
Modularity   17
Modularity           17




  as change occurs
Modularity                               17




  as change occurs




                     modules and their
            ...
Modularity                                                17




  as change occurs
                                      ...
Modularity                                                17




  as change occurs
                                      ...
Modularity   18




     Architectural Joints




 Which
          ar
system ea of the
          deman
flexib           ds ...
Modularity   18




     Architectural Joints




 Which
          ar
system ea of the
          deman
flexib           ds ...
Modularity                                            19




   Module Design

        Few teams are designing software sy...
Modularity                         20




Platform Modularity
                       Why a
                              r...
Modularity                                  20




  Platform Modularity
                                    Why a
       ...
Modularity                  21




Platform Modularity
                       But w
                               hat if
...
Modularity                                         21




    Platform Modularity
                                        ...
Modularity                 22




Runtime Model
                        - Dyn
                              am
           ...
Modularity                                         23




Development Model

         Progra                     Design
  ...
Modularity                                             23




Development Model

         Progra                         D...
Modularity                                 24




Modular Tension
                      Maximizing reuse complicates use
Modularity                                    24




Modular Tension
                      Maximizing reuse complicates us...
Agile Architecture                25




    The Patterns

         What
                ar
         mo dul e the
        ...
The Patterns                                     26




Base Patterns
• ManageRelationships – Design Module Relationships....
The Patterns                                       27




Dependency Patterns
• AcyclicRelationships - Module relationship...
The Patterns                                     28




Usability Patterns
• PublishedInterface - Make a modules published...
The Patterns                                     29




Extensibility Patterns
• StableModules - Modules heavily depended ...
The Patterns                                    30




Utility Patterns
• LevelizedBuild – Execute the build in accordance...
Agile Architecture                  31




                 Patterns Applied

How c                      How d
       an I...
Patterns Applied                      32




The System


    Design a system to handle payment and
    auditing of variou...
Patterns Applied   33




   Initial System Class Diagram




 Note t
        he bi-
direct
       io n
associ al
      at...
Patterns Applied                          34




Initial System Modules



                                 If I la
      ...
Patterns Applied                                    35




Physical Layers
• Module relationships should not violate the c...
Patterns Applied                                       36




Abstract Modules
• Depend upon the abstract elements of a mo...
Patterns Applied   37




Abstract Modules


  What
          if Bill
  be ab            m
        le to u ust
 differ    ...
Patterns Applied                            38




Abstract Modules




                              Au ditF
            ...
Patterns Applied   39




Abstract Modules
Patterns Applied                 40




Acyclic Relationships
• Module relationships must be acyclic.
Patterns Applied                                          41




Recall - Abstract Modules Class Diagram




             ...
Patterns Applied   42




Recall - Abstract Modules
Patterns Applied     43




Uni-Directional Associations
Patterns Applied   44




Acyclic Relationships
Patterns Applied                                45




           Separate Abstractions
            • Separate abstraction...
Patterns Applied   46




     Separate Abstractions


 Shoul
        d I p
              ut
 Audit
       Facad
         ...
Patterns Applied   47




Separate Abstractions
Patterns Applied                                  48




      CollocateExceptions
       • Exceptions should be close to ...
Patterns Applied                       49




 Independent Deployment
  • Modules should be independently deployable units...
Patterns Applied   50




Independent Deployment
Patterns Applied                                  51




Independent Deployment

                            1.) PayAction...
Patterns Applied   52




Independent Deployment
Patterns Applied                                     53




Implementation Factory
• Use factories to create a modules imp...
Patterns Applied   54




Final Module Structure
Patterns Applied     55




Opportunities for Extension
Agile Architecture                                56




Additional Resources
• OSGi - http://www.osgi.org
• JarAnalyzer -...
Agile Architecture                    57




                    irk Knoernschild
Presented By: K                    m
kkn...
Upcoming SlideShare
Loading in …5
×

Agile Architecture Tech And Patterns

3,124 views

Published on

Published in: Technology, Education
  • Be the first to comment

Agile Architecture Tech And Patterns

  1. 1. Kirk Knoernschild Analyst, SDLC and Containers, Agile Architecture - Patterns & Technology Languages, & Frameworks Burton Group www.burtongroup.com kknoernschild@burtongroup.com Blog: http://apsblog.burtongroup.com Blog: http://techdistrict.kirkk.com Twitter: pragkirk
  2. 2. Agile Architecture 2 The Law of Two Feet If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute. Image Source: http://www.flickr.com/photos/jamesfarnham/32302798/
  3. 3. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied
  4. 4. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied
  5. 5. Agile Architecture 4 Defining Architecture What What What is arc is is hitect ure? archit the goal of archit ag ile ecture ecture ? ?
  6. 6. Defining Architecture 5 Preliminary Thoughts • Architects architect architecture • “Architecture is design, but not all design is architecture”.1 • We are often asked to design solutions to problems that require knowledge we currently do not possess. • Gall’s Law • A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. 2 • This session describes my approach to agile architecture. It is not all-inclusive, nor necessarily complete. Your feedback is valued and encouraged! 1. Booch made this statement. 2. John Gall. “How Systems Really Work and How They Fail.” P. 71
  7. 7. Defining Architecture 6 What is Architecture? • An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural elements and behavioral elements into progressively larger subsystems, and the architecture style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. Source: Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999
  8. 8. Defining Architecture 7 What is Architecture? • In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers...Architecture is about the important stuff. Whatever that is. Source: Fowler, Martin. IEEE Software, 2003. “Who Needs an Architecture.” A quote from Ralph Johnson on the XP mailing list.
  9. 9. Defining Architecture 8 What is Architecture? • 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. Source: ANSI/IEEE Std 1471-2000
  10. 10. Defining Architecture 9 What is Architecture? • A formal description of a system, or a detailed plan of the system at component level to guide its implementation • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. Source: TOGAF - http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html
  11. 11. Defining Architecture 10 What is Architecture? • Architecture embodies the critical design decisions that typify a system. • Relates to cost of change, organizational structure, structure of code, capabilities of a system, etc. • The significance of decisions needs to be understood and assessed • A heavy-weight approach is likely to reduce understanding and our ability to assess Source: QCON London Presentation by James Coplien & Kevlin Henney title Agile Architecture Is not Fragile Architecture - http://www.infoq.com/presentations/Agile- Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
  12. 12. Defining Architecture 11 The Goal of Architecture
  13. 13. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change?
  14. 14. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change? We n ee d t elimin o ate archit ectur e!
  15. 15. Defining Architecture 12 Architecture Paradox Increa sing e decre vo ases s lvability ur viva bility ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
  16. 16. Defining Architecture 12 Architecture Paradox We m Increa ust re sing e decre vo which cogniz e ases s lvability areas ur viva system of the bility deman increa d the se d co that w mplex ill bri ity greate ng r flex ibility! ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
  17. 17. Defining Architecture 13 I contend... • Architecture requires modularity • otherwise, how do we understand the impact of change • how do we identify areas of the system that demand flexibility • Agile architecture requires decision temporality • we cannot create solutions today for that which we will not know until tomorrow • otherwise we’ll create unnecessarily complex designs that do not address the impact of change
  18. 18. Agile Architecture 14 Modularity What Why i What is mo d s mo d ch ular neces ula us to d allenges fa ity? sar y c rity a ay in c of ag i o mp o n mo dul design e le arc ent ar sof in hitect tware g ure? ?
  19. 19. Modularity 15 Defining Module Hey, it’s a JAR file! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent
  20. 20. Modularity 15 Defining Module Hey, it’s a JAR file! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent A module system provides a runtime environment for modules
  21. 21. Modularity 16 Advantages of Modularity - reus e - re du ce co m - ease ple mainte xity - incr nance ease exten sibility
  22. 22. Modularity 17
  23. 23. Modularity 17 as change occurs
  24. 24. Modularity 17 as change occurs modules and their dependencies
  25. 25. Modularity 17 as change occurs isolate change modules and their dependencies
  26. 26. Modularity 17 as change occurs isolate change modules and their dependencies
  27. 27. Modularity 18 Architectural Joints Which ar system ea of the deman flexib ds mo ility? re
  28. 28. Modularity 18 Architectural Joints Which ar system ea of the deman flexib ds mo ility? re
  29. 29. Modularity 19 Module Design Few teams are designing software systems this way today! POLL: Question: Response: ----------------------------------------------------- - How many design class relationships? _____ - How many design package relationships? _____ - How many design module (JAR, Assembly) relationships? _____
  30. 30. Modularity 20 Platform Modularity Why a re design n’t we ing mo mo dul re ar sof tware ?
  31. 31. Modularity 20 Platform Modularity Why a re design n’t we Platforms discourage modularity! ing mo mo dul re ar sof tware ?
  32. 32. Modularity 21 Platform Modularity But w hat if platfo the rm enco u rage d mo dul arity?
  33. 33. Modularity 21 Platform Modularity But w This is the next generation application platform! hat if platfo the rm enco u rage d mo dul arity?
  34. 34. Modularity 22 Runtime Model - Dyn am - Mult ic deployme ipl nt - Enfo e versions rce depen dencie s
  35. 35. Modularity 23 Development Model Progra Design m ming Para d - The Mo del - The igm frame techn an d te works use d t iques ch that a nolog ies create o i den tify a llow u the ri nd create s to of mo ght se mo dul dules t softw ar are
  36. 36. Modularity 23 Development Model Progra Design m ming Para d - The Mo del - The igm frame techn an d te works use d t iques ch that a nolog ies create o i den tify a llow u the ri nd create s to of mo ght se mo dul dules t softw ar are The Design Paradigm - What’s the right granularity for a module? - What the right weight for a module?
  37. 37. Modularity 24 Modular Tension Maximizing reuse complicates use
  38. 38. Modularity 24 Modular Tension Maximizing reuse complicates use - SOL ID - Desi gn Pat - Mo d terns ularity Patter ns
  39. 39. Agile Architecture 25 The Patterns What ar mo dul e the arity patter ns?
  40. 40. The Patterns 26 Base Patterns • ManageRelationships – Design Module Relationships. • ModuleReuse – Emphasize reusability at the module level • CohesiveModules – Create cohesive modules. • ClassReuse - Classes not reused together belong in separate components.
  41. 41. The Patterns 27 Dependency Patterns • AcyclicRelationships - Module relationships must be acyclic. • LevelizeModules – Module relationships should be levelized • PhysicalLayers - Module relationships should not violate the conceptual layers. • ContainerIndependence - Consider your modules container dependencies. • IndependentDeployment - Modules should be independently deployable units. • CollocateExceptions - Exceptions should be close to the classes that throw them.
  42. 42. The Patterns 28 Usability Patterns • PublishedInterface - Make a modules published interface well known. • ExternalConfiguration – Modules should be externally configurable. • ModuleFacade – Create a facade serving as a coarse-grained entry point to the modules underlying implementation.
  43. 43. The Patterns 29 Extensibility Patterns • StableModules - Modules heavily depended upon should be stable. • AbstractModules - Depend upon the abstract elements of a module. • ImplementationFactory - Use factories to create a modules implementation classes. • SeparateAbstractions - Separate abstractions from the classes that realize them.
  44. 44. The Patterns 30 Utility Patterns • LevelizedBuild – Execute the build in accordance with module levelization. • TestComponent – For each module, create a test component that validates it’s behavior and illustrates usage.
  45. 45. Agile Architecture 31 Patterns Applied How c How d an I u o they mo dul se the acco m h arity mo dat elp patter archit e ns? ectura l shift s?
  46. 46. Patterns Applied 32 The System Design a system to handle payment and auditing of various types of bills. The system must integrate with 3rd party auditing software, and a legacy financials system that must be fed payment information for reconciliation.
  47. 47. Patterns Applied 33 Initial System Class Diagram Note t he bi- direct io n associ al ations !
  48. 48. Patterns Applied 34 Initial System Modules If I la yer conce ptu physic ally but no all t I real y, then am izing t a dvan he tages layeri of ng? W layer ? hy do I
  49. 49. Patterns Applied 35 Physical Layers • Module relationships should not violate the conceptual layers.
  50. 50. Patterns Applied 36 Abstract Modules • Depend upon the abstract elements of a module. - “Inje ct implem ” the entati Client. on int o - “Lo o ku implem p” the entati w ithin on Client.
  51. 51. Patterns Applied 37 Abstract Modules What if Bill be ab m le to u ust differ se ent au system diting s?
  52. 52. Patterns Applied 38 Abstract Modules Au ditF ac inject a de1 is e d int as an oB Au ditF ill type. aca de
  53. 53. Patterns Applied 39 Abstract Modules
  54. 54. Patterns Applied 40 Acyclic Relationships • Module relationships must be acyclic.
  55. 55. Patterns Applied 41 Recall - Abstract Modules Class Diagram Au ditF ac inject a de1 is e d int as an oB Au ditF ill type. aca de
  56. 56. Patterns Applied 42 Recall - Abstract Modules
  57. 57. Patterns Applied 43 Uni-Directional Associations
  58. 58. Patterns Applied 44 Acyclic Relationships
  59. 59. Patterns Applied 45 Separate Abstractions • Separate abstractions from the classes that realize them. How d o I integr ate w ith anoth er au diting syste m? W here does Audit Facad live? e2
  60. 60. Patterns Applied 46 Separate Abstractions Shoul d I p ut Audit Facad e2 in audit. jar?
  61. 61. Patterns Applied 47 Separate Abstractions
  62. 62. Patterns Applied 48 CollocateExceptions • Exceptions should be close to the classes that throw them. Audit Facad e throw s the Audit Excep tion.
  63. 63. Patterns Applied 49 Independent Deployment • Modules should be independently deployable units. How d o I re bill.ja use r with financ out ial.ja in a b r? Lik atch e applic ation?
  64. 64. Patterns Applied 50 Independent Deployment
  65. 65. Patterns Applied 51 Independent Deployment 1.) PayAction invokes Bill.pay() and passes BillPayAdapter as a BillPayer. 2.) Bill.pay() invokes BillPayer.generateDraft() 3.)BillPayAdapeter.generateDraft() invokes Payment.generateDraft() passing itself as a Payable. 4.) Payment.generateDraft() invokes Payable.getAmount()
  66. 66. Patterns Applied 52 Independent Deployment
  67. 67. Patterns Applied 53 Implementation Factory • Use factories to create a modules implementation classes.
  68. 68. Patterns Applied 54 Final Module Structure
  69. 69. Patterns Applied 55 Opportunities for Extension
  70. 70. Agile Architecture 56 Additional Resources • OSGi - http://www.osgi.org • JarAnalyzer - http://www.kirkk.com/main/Main/JarAnalyzer • Illustrates dependencies between JAR files • Google Code - http://code.google.com/p/jaranalyzer/
  71. 71. Agile Architecture 57 irk Knoernschild Presented By: K m kknoernschild @burtongroup.co m p ragkirk@kirkk.co m http://te chdistrict.kirkk.co

×