t14
play

T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns - PDF document

T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns and Technology" Presented by: Kirk Knoernschild Burton Group Presented at: Agile Development Practices Conference & EXPO 2009 November 9 13, 2009 Orlando, Florida 330


  1. T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns and Technology" Presented by: Kirk Knoernschild Burton Group Presented at: Agile Development Practices Conference & EXPO 2009 November 9 ‐ 13, 2009 Orlando, Florida 330 Corporate Way, Suite 300, Orange Park, FL 32073 888 ‐ 268 ‐ 8770 ∙ 904 ‐ 278 ‐ 0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

  2. Kirk Knoernschild A software developer currently working as an analyst for Burton Group, Kirk Knoernschild has more than fifteen years of software development experience during which he has filled most roles on the software development team. Kirk is an open source contributor, has authored Java Design: Objects, UML, and Process and numerous articles, and is a frequent conference speaker. He has trained and mentored thousands of software professionals on topics including Java/J2EE, modeling, software architecture and design, component-based development, service-oriented architecture, and software process. Kirk enjoys hacking in a variety of languages.

  3. Agile Architecture Kirk Knoernschild Analyst, SDLC and Containers, Languages, & Frameworks Burton Group www.burtongroup.com kknoernschild@burtongroup.com Blog: http://apsblog.burtongroup.com Blog: http://techdistrict.kirkk.com Twitter: pragkirk Tuesday, September 1, 2009

  4. 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/ Tuesday, September 1, 2009

  5. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied Tuesday, September 1, 2009

  6. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied Tuesday, September 1, 2009

  7. Agile Architecture 4 Defining Architecture What is the goal of What is agile What is architecture? architecture? architecture? Tuesday, September 1, 2009

  8. 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 Tuesday, September 1, 2009

  9. 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 Tuesday, September 1, 2009

  10. 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. Tuesday, September 1, 2009

  11. 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 Tuesday, September 1, 2009

  12. 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 Tuesday, September 1, 2009

  13. 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 Tuesday, September 1, 2009

  14. Defining Architecture 11 The Goal of Architecture Tuesday, September 1, 2009

  15. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change? Tuesday, September 1, 2009

  16. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change? We need to eliminate architecture! Tuesday, September 1, 2009

  17. Defining Architecture 12 Architecture Paradox Increasing evolvability decreases survivability ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect” Tuesday, September 1, 2009

  18. Defining Architecture 12 Architecture Paradox Increasing evolvability We must recognize decreases survivability which areas of the system demand the increased complexity that will bring greater flexibility! ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect” Tuesday, September 1, 2009

  19. 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 Tuesday, September 1, 2009

  20. Agile Architecture 14 Modularity Why is modularity a What challenges face What is modularity? necessary component us today in designing of agile architecture? modular software? Tuesday, September 1, 2009

  21. Modularity 15 Defining Module Hey, it’ s a JAR file! - unit of reuse - unit of composition - unit of deployment - unit of management Tuesday, September 1, 2009

  22. Modularity 15 Defining Module Hey, it’ s a JAR file! - unit of reuse - unit of composition - unit of deployment - unit of management A module system provides a runtime environment for modules Tuesday, September 1, 2009

  23. Modularity 16 Advantages of Modularity - reuse - reduce complexity - ease maintenance - increase extensibility Tuesday, September 1, 2009

  24. Modularity 17 Tuesday, September 1, 2009

  25. Modularity 17 as change occurs Tuesday, September 1, 2009

  26. Modularity 17 as change occurs modules and their dependencies Tuesday, September 1, 2009

  27. Modularity 17 as change occurs isolate change modules and their dependencies Tuesday, September 1, 2009

  28. Modularity 17 as change occurs isolate change modules and their dependencies Tuesday, September 1, 2009

  29. Modularity 18 Architectural Joints Which area of the system demands more flexibility? Tuesday, September 1, 2009

  30. Modularity 18 Architectural Joints Which area of the system demands more flexibility? Tuesday, September 1, 2009

  31. 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? _____ Tuesday, September 1, 2009

  32. Modularity 20 Platform Modularity Why aren’ t we designing more modular software? Tuesday, September 1, 2009

  33. Modularity 20 Platform Modularity Why aren’ t we designing more Platforms discourage modularity! modular software? Tuesday, September 1, 2009

Recommend


More recommend