Agile Architecture Diego Fontdevila [email_address]
Contents <ul><li>Software  A rchitecture </li></ul><ul><li>The need for architecture </li></ul><ul><li>The role of the  A ...
Software Architecture
Software architecture <ul><li>“ The structure or structures of the system, which comprise software components, the externa...
Software architecture <ul><li>As much the strategic design activity as the resulting product of that activity. </li></ul><...
The need for architecture
The need for architecture <ul><li>Essential complexity </li></ul><ul><ul><li>No Silver Bullet (Brooks) </li></ul></ul><ul>...
The role of the architect
The role of the architect <ul><li>Technical lead </li></ul><ul><li>Has valuable experiences to share (might limit his visi...
Modularity
Modularity <ul><li>What is a module today? </li></ul><ul><ul><li>Piece of code? </li></ul></ul><ul><ul><li>Procedure? </li...
Modularity <ul><li>S ystem size has grown and software use is widespread. </li></ul><ul><li>Module size  is  driven by sys...
Modularity <ul><li>Modules need to have wel l defined interfaces. </li></ul><ul><li>Helps reduce dependencies between modu...
Modularity: Language <ul><li>Linguistic Modular Units  Pr inciple :  Programming language should support the syntax to des...
Team
Team <ul><li>We think only with the wor ds we know. </li></ul><ul><li>Software as a conversation and collaboration. </li><...
Team: Language <ul><li>Architecture serves as the entry point for training new team members. </li></ul><ul><li>It is usu a...
Team:  Collaboration <ul><li>Ana lyst: </li></ul><ul><ul><li>Initial requirements, feasibility  </li></ul></ul><ul><li>Dev...
Team <ul><li>When does architecture come into our work? </li></ul><ul><ul><li>When we fir st try to conceive the product a...
Team: Documentation rules <ul><li>Ar chitecture Documentation/Communication Rules </li></ul><ul><ul><li>P ut yourself in h...
Bibliography <ul><li>Austin, Bob,  Devin, Lee,  Artful Making , What Managers need to know about how artists work, </li></...
Bibliography <ul><li>Austin, Rob, Devin, Lee,  Artful Making, What managers need to know about how artists work , Prentice...
Bibliography <ul><li>Clements, Paul, et al,  Documenting Software Architecture: Views and Beyond , SEI Series in Software ...
Thank you
Upcoming SlideShare
Loading in …5
×

Agiles 2009 - Agile Architecture - Diego Fontdevila

1,764 views

Published on

What is software architecture? What does an architect do? Where do architectures come from?
How does all that relate to the product and the team? In this presentation we revise the need for the idea of architecture and how it relates to the daily work of our team. We focus on design rationale and communication.
discussing the effect on both the team and the product.

Published in: Technology
  • Be the first to comment

Agiles 2009 - Agile Architecture - Diego Fontdevila

  1. 1. Agile Architecture Diego Fontdevila [email_address]
  2. 2. Contents <ul><li>Software A rchitecture </li></ul><ul><li>The need for architecture </li></ul><ul><li>The role of the A rchitect </li></ul><ul><li>Modularity </li></ul><ul><li>Team </li></ul>
  3. 3. Software Architecture
  4. 4. Software architecture <ul><li>“ The structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them.” (Bass, Clements, Kazman) </li></ul><ul><li>Strategic design </li></ul><ul><li>Decisions we want to get right (Ralph Johnson) </li></ul><ul><li>What is hard to change (Martin Fowler) </li></ul>
  5. 5. Software architecture <ul><li>As much the strategic design activity as the resulting product of that activity. </li></ul><ul><li>Helps with iterative and incremental development. </li></ul><ul><li>Might not be apparent. </li></ul><ul><li>Noticeably affects the quality attributes of the product. </li></ul><ul><li>Technology sensitive. </li></ul><ul><li>Usually has a high level of abstraction. </li></ul>
  6. 6. The need for architecture
  7. 7. The need for architecture <ul><li>Essential complexity </li></ul><ul><ul><li>No Silver Bullet (Brooks) </li></ul></ul><ul><ul><li>Flexibility is a basic hygien e requirement </li></ul></ul><ul><ul><li>Write less code (Poppendiecks) </li></ul></ul><ul><li>Growing size </li></ul><ul><ul><li>Pattern of constant growth of our abstractions (Shaw). </li></ul></ul><ul><li>Distribution </li></ul><ul><ul><li>Generalized in the '90s </li></ul></ul><ul><ul><li>Uncerta in number of users </li></ul></ul>Agile Architecture
  8. 8. The role of the architect
  9. 9. The role of the architect <ul><li>Technical lead </li></ul><ul><li>Has valuable experiences to share (might limit his vision) </li></ul><ul><li>Mentor, guide and counselor for the team </li></ul><ul><li>Has business vision </li></ul><ul><li>Responsible for technical risks </li></ul><ul><li>Supports communication between stakeholders </li></ul><ul><li>Helps define the structure of the project </li></ul>Agile Architecture
  10. 10. Modularity
  11. 11. Modularity <ul><li>What is a module today? </li></ul><ul><ul><li>Piece of code? </li></ul></ul><ul><ul><li>Procedure? </li></ul></ul><ul><ul><li>ADT? </li></ul></ul><ul><ul><li>Class? </li></ul></ul><ul><ul><li>Package? </li></ul></ul><ul><ul><li>Application? </li></ul></ul><ul><li>Product structure in terms of work assignment (Len Bass et al). </li></ul>Agile Architecture
  12. 12. Modularity <ul><li>S ystem size has grown and software use is widespread. </li></ul><ul><li>Module size is driven by system size. Limitation on the amount of modules of a system is on the human mind. </li></ul><ul><li>Module size is constantly increasing. In other words, the granularity of our abstractions has been historically growing (Shaw). </li></ul>Agile Architecture
  13. 13. Modularity <ul><li>Modules need to have wel l defined interfaces. </li></ul><ul><li>Helps reduce dependencies between modules y facilitates working independently. </li></ul><ul><li>But the loss of dependencies inside a team may affect result eliminating opportunities for interaction and reconception between team members working in different modules (Austin and Devin). </li></ul>Agile Architecture
  14. 14. Modularity: Language <ul><li>Linguistic Modular Units Pr inciple : Programming language should support the syntax to describe modules (Meyer). </li></ul><ul><ul><li>How do you say module in you r programming language? </li></ul></ul><ul><li>Hi gh level languages are a must (Brooks). Their level of abstraction has been steadily growing. </li></ul><ul><li>Languages are becoming platforms, and there are already architecture level languages. Annotations and Aspects, for instance, allow us to extend languages. </li></ul>Agile Architecture
  15. 15. Team
  16. 16. Team <ul><li>We think only with the wor ds we know. </li></ul><ul><li>Software as a conversation and collaboration. </li></ul><ul><li>Technical v ision guides development producing a balanced and harmonic design . </li></ul><ul><li>Contributions from team members are very important and must be integrated, not evened out: Reconceiving over Compromise (Austin and Devin). </li></ul><ul><li>Different perspectives help diminish technical uncertainty . </li></ul>Agile Architecture
  17. 17. Team: Language <ul><li>Architecture serves as the entry point for training new team members. </li></ul><ul><li>It is usu ally best to use a restricted solution language, based on patterns and frameworks (Bass, Clements, Kazman). </li></ul><ul><li>Domain Driven Design: There should be a single model for problem and solution (Evans) </li></ul><ul><li>Domain Model: The T eam and the Customer build a single language for the solution they develop (Evans) </li></ul>Agile Architecture
  18. 18. Team: Collaboration <ul><li>Ana lyst: </li></ul><ul><ul><li>Initial requirements, feasibility </li></ul></ul><ul><li>Developer: </li></ul><ul><ul><li>Incremental design , pair programming </li></ul></ul><ul><li>Tester: </li></ul><ul><ul><li>Quality attributes strategy, Prototype testing, test harness definitions </li></ul></ul>Agile Architecture
  19. 19. Team <ul><li>When does architecture come into our work? </li></ul><ul><ul><li>When we fir st try to conceive the product as a whole </li></ul></ul><ul><ul><li>When we propose strategies to fulfill requirements related to quality attributes and when we test them </li></ul></ul><ul><ul><li>When we distribute work between our teams </li></ul></ul><ul><ul><li>When we organize our software configuration </li></ul></ul><ul><ul><li>When we choose languages and technology </li></ul></ul><ul><ul><li>When we record design rationale </li></ul></ul>Agile Architecture
  20. 20. Team: Documentation rules <ul><li>Ar chitecture Documentation/Communication Rules </li></ul><ul><ul><li>P ut yourself in his shoes (Views) </li></ul></ul><ul><ul><li>Keep a standard organization (Views?) </li></ul></ul><ul><ul><li>Avoid ambiguity (Unique language) </li></ul></ul><ul><ul><li>Avoid unnecesary repetition (and explain notations) </li></ul></ul><ul><ul><li>Keep documentation current but not too current </li></ul></ul><ul><ul><li>Record rationale (Decision Log) </li></ul></ul><ul><ul><li>Review documentation for fitness of purpose </li></ul></ul><ul><ul><li>(Clements, Garlan, et al) </li></ul></ul>Agile Architecture
  21. 21. Bibliography <ul><li>Austin, Bob, Devin, Lee, Artful Making , What Managers need to know about how artists work, </li></ul><ul><li>Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998. </li></ul><ul><li>Brooks, Frederick, No Silver Bullet, Essence and Accidents of Software Engineering , Computer Magazine, 1987. </li></ul><ul><li>Clements, Paul, et al, Documenting Software Architecture: Views & Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003. </li></ul><ul><li>Evans, Eric, Domain Driven Design , Tackling Complexity in the Heart of Software, 2003. </li></ul>Agile Architecture
  22. 22. Bibliography <ul><li>Austin, Rob, Devin, Lee, Artful Making, What managers need to know about how artists work , Prentice Hall, 2003. </li></ul><ul><li>Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998. </li></ul><ul><li>Brooks, Frederick, “No Silver Bullet” , in The Mythical Man-Month, Essays on Software Engineering , Addison-Wesley, 1985. </li></ul><ul><li>Clements, Paul, Shaw, Mary, &quot;Three Patterns That Help Explain the Development of Software Engineering&quot; , Position paper for Dagstuhl Workshop on Software Architecture, 1996. </li></ul>Agile Architecture
  23. 23. Bibliography <ul><li>Clements, Paul, et al, Documenting Software Architecture: Views and Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003. </li></ul><ul><li>Fowler, Martin, “Who Needs an Architect?” , IEEE Software, Volume 20, Issue 4, September 2003, pages 11-13. </li></ul><ul><li>Meyer, Bertrand, Object-Oriented Software Construction , Prentice-Hall, 1985, 2nd Edition 1997. </li></ul><ul><li>Poppendieck, Mary, Poppendieck, Tom, Implementing Lean Software Development, From Concept to Cash , Addison-Wesley, 2006. </li></ul>
  24. 24. Thank you

×