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.

Architecture in an Agile World

1,270 views

Published on

We now acknowledge that complete upfront requirements is an impossible mission. Agile approaches have emerged as a way to manage the creation of systems that can never be completely defined and are certain to change.
But what about architecture and design for these systems? How much is the right amount? How do you plan for emergent design? What is the architect's role on an agile project?

Topics include:
- Role of the agile architect
- Agile design
- Keeping change easy
- Reducing technical risks
- Capturing non-functional and technical requirements and constraints
- Dealing with technical debt
- Addressing architectural concerns within the Scrum framework
- Tests – They're not just for finding bugs
- Architecture anti-patterns

Published in: Technology

Architecture in an Agile World

  1. 1. Architecture)in)an)) Agile)World) Don McGreal don.mcgreal@ImprovingEnterprises.com @donmcgreal linkedin.com/in/donmcgreal!
  2. 2. Agenda' ! Agile and Architecture ! Reducing Technical Risks ! Team Makeup & Roles ! Architecture Anti-Patterns
  3. 3. What'is'So/ware'Architecture?'
  4. 4. Business'Goals' • What business goals could affect our Architectural decisions?
  5. 5. Non9Func;onal'Requirements' " Usability' " Scalability' " Portability' " Maintainability' " Availability' " Accessibility' " Supportability " Security " Performance " Cost " Legal " Cultural " ...
  6. 6. Does'it'compare'to'building'this?' ' • Standard' House' '
  7. 7. …'or'this?' ' • House???' '
  8. 8. …'or'this?' ' • ???' '
  9. 9. Level'of'Complexity' Simple' Everything'is'known' Complicated' More'is'known'than'unknown' Complex' More'is'unknown'than'known' Chao;c' Very'liNle'is'know' Source:'Ralph'Stacey,'University'of'HerRordshire'
  10. 10. Empirical'vs'Defined'Processes' Defined) Empirical) Predict'the'Future' Ini;al'informa;on'and'assump;ons'are' valid'throughout'the'planning'horizon.' ' Adapt'to'the'Future' Frequent'inspec;on/adapta;on'rather' than'predic;ve'planning' ' Examples:'' assembly'line,'construc;on,'accoun;ng,' orchestra' Examples:'' sales,'marke;ng,'crea;ve'wri;ng,'band' Plan' Do' P' D' P' D' P' D' P' D'
  11. 11. Team)(BA,)QA,)Dev,)etc.))creates) and)es@mates)Sprint)Backlog)(tasks)' • Business)Case) • Financing) • Scope)&)Approach) • Contracts) • Ini@al)Release)Plan) • Assemble)Team) Sprint)Planning) 1)day) • Acceptance)) Defined) • Team)commits) • Tasks)created) Product)Owner) establishes)vision)and) priori@zes)Product)Backlog) Sprint 1)to)4)weeks) Releasable) Increment) Daily)Scrum <)15)minutes) Burn)down) Scrum' Sprint)Review 1/2)day) Sprint)Retrospec@ve 1/2)day) Burn)up) velocity)
  12. 12. BigDUF'or'LiNleDUF?' Monday) Tuesday) Wednesday) Thursday) Friday) Sprint)) 1) Sprint)) 2) Sprint)Planning) Sprint)Planning) LDUF) PB)Grooming) PB)Crea@on) PB)Sizing) Release)Planning) PB)Grooming) Sprint)Review) Retrospec@ve) Sprint)Review) Retrospec@ve)
  13. 13. Non9Func;onal'Requirements' " Usability' " Scalability' " Portability' " Maintainability' " Availability' " Accessibility' " Supportability " Security " Performance " Cost " Legal " Cultural " ...
  14. 14. Non9Func;onal'Requirements' " Usability' " Scalability' " Portability' " Maintainability' " Availability' " Accessibility' " Supportability " Security " Performance " Cost " Legal " Cultural " ... Captured'as:' ' " Acceptance' Criteria' " Defini;on'of' Done' " User'Stories'
  15. 15. Sprint'Capacity'over'Time' 100' 90' 80' 70' 60' 50' 40' 30' 20' 10' 0' Infrastructure'/' Architecture' Func;onality'
  16. 16. …'but'one'is'different' " Usability " Scalability " Portability " Maintainability " Availability " Accessibility " Supportability " Security " Performance " Cost " Legal " Cultural " ...
  17. 17. Most'Important'Architecture'Goal?' • Maintainability
  18. 18. Agenda' ! Agile and Architecture ! Reducing Technical Risks ! Team Makeup & Roles ! Architecture Anti-Patterns
  19. 19. Technical'Debt'in'an'Unhealthy'Team' Time'available'for' new'feature' development' Time'struggling'with'' complexity'and'debt' *From'Scrum.org’s' Professional'Scrum'Master' cer;fica;on'course'
  20. 20. Yuck.' *From'Scrum.org’s' Professional'Scrum'Master' cer;fica;on'course'
  21. 21. Stabiliza;on:'Plan'vs.'Reality' Plan" P D P D P D RC P D P D P D RC P D P D P D RC Release Actual" " P D P D P D RC P D P D P D RC P D P D P D RC Stabilization"Release *From'Scrum.org’s' Professional'Scrum'Master' cer;fica;on'course'
  22. 22. How'do'you'get'out'of'debt?' 1. Stop'crea;ng'debt' 2. Make'a'small'payment'each'Sprint' 3. Repeat'from'2' *From'Scrum.org’s' Professional'Scrum'Master' cer;fica;on'course'
  23. 23. • Business)Case) • Financing) • Scope)&)Approach) • Contracts) • Ini@al)Release)Plan) • Assemble)Team) Sprint)Planning) 1)day) • Acceptance)) Defined) • Team)commits) • Tasks)created) Product)Owner) establishes)vision)and) priori@zes)Product)Backlog) Sprint 1)to)4)weeks) Daily)Scrum <)15)minutes) Burn)down) Defini;on'of' Sprint)Review 1/2)day) Sprint)Retrospec@ve 1/2)day) Burn)up) Done)Release?) Compliance' velocity) Team)(BA,)QA,)Dev,)etc.))creates) and)es@mates)Sprint)Backlog)(tasks)' Sprint)Review 1/2)day) Done)Task?) Unit'Tested' Code'Reviewed' Checked9in' others?' ' Done)Feature?) Acceptance'Tested' On'Test'Server' Performance'Tested' others?' ' ' Done)Sprint?) Versioned' In'UAT' Integrated' others?' ' ' Labeled' Training' others?' ' ' Releasable) Increment) Done'
  24. 24. Paying'off'Debt' Feature))Name) Scheduled) Ac@ve) Blocked) Closed) ' Feature''1' Task1.4' Task1.2' ' Task1.3' Task1.1' Feature''2' ' Task2.3' Task2.1' Task2.2' Feature''3' Task3.3' Task3.1' Task3.2' Task3.4'
  25. 25. Paying'off'Debt' Feature))Name) Scheduled) Ac@ve) Blocked) Closed) ' Feature''1' Task1.4' Task1.2' ' Task1.3' Task1.1' Design)Task) ' Feature''2' ' Task2.3' Upgrade)Task) Task2.1' Task2.2' ENGINEERING)&) MAINTENANCE) Eng.)Task)1) Bug) Eng.)Task)2) Upgrade)Task) '
  26. 26. Design Patterns != Good Design
  27. 27. What'is'a'PaNern?'
  28. 28. Design'PaNern'Structure' Pattern Name: A descriptive and unique name that helps in identifying and referring to the pattern." " Intent: A description of the goal behind the pattern and the reason for using it." " Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used." " Structure: A graphical representation of the pattern, such as Class diagrams and Interaction diagrams." " Consequences: A description of the results, side effects, and trade offs caused by using the pattern." " Implementation: A description of an implementation of the pattern; the solution part of the pattern." " Sample Code: An illustration of how the pattern can be used in a programming language" " Known Uses: Examples of real usages of the pattern." " Related Patterns: Other patterns that have some relationship with the pattern."
  29. 29. Core'Aspects'of'Good'Design' ✓✓ Low Coupling Good Design ✓ High Cohesion
  30. 30. Coupling'vs.'Cohesion'
  31. 31. Core'Aspects'of'Bad'Design' X • Duplication Bad Design • Ambiguity • Complexity
  32. 32. Bad'Smells' The Bloaters Long Method, Large Class, Data Clumps The OO Abusers Type Attribute, State Attribute, Indecent Exposure The Dispensables Lazy Class, Dead Code, Data Class The Couplers Feature Envy, Message Chains, Middleman The Change Preventers Divergent Change, Shotgun Surgery, Non-localized Logic
  33. 33. How'do'we'get'there?' XBad ➔ ✓Good Design Design
  34. 34. Refactoring' X ➔ Design Bad ✓ Good Design Refactoring to / towards / away from Design Patterns Bad Smells
  35. 35. Refactoring' X ➔ Design Refactoring ✓ Good to / towards / away from Design Patterns Bad Smells Encapsulate Field! Extract Method ! Generalize Type! Pull Up! Push Down! Rename Method ! ...! Bad Design
  36. 36. Agenda' ! Agile and Architecture ! Reducing Technical Risks ! Team Makeup & Roles ! Architecture Anti-Patterns
  37. 37. Ver;cal'Teams' TEAM)1) TEAM)2) TEAM)3) TEAM)4) Presentation Business PersisDBt ence
  38. 38. Ver;cal'Features' TEAM)1) TEAM)2) TEAM)3) TEAM)4) Presentation Features' Features' Features' Features' Business PersisDBt ence
  39. 39. Ideal'Team'Composi;on' VP' QA' 'Manager' Product'Manager' QA' QA' QA' Dev' Dev' Dev' Dev' Architecture' Manager' Architect' Architect' Architect' DBA'' Manager' DBA' DBA' Team)A) Team)B)
  40. 40. Realis;c'Team'Composi;on' VP' QA' 'Manager' Product'Manager' QA' QA' QA' Dev' Dev' Dev' Dev' Architecture' Manager' Architect' Architect' Architect' DBA'' Manager' DBA' DBA' Team)A) Team)B) What' now?'
  41. 41. Specialists '' 1. IDEAL:'Specialists'are'dedicated'to'a'team'and' par;cipate'throughout'the'sprint.' ' 2. REALISTIC:'Specialists'service'mul;ple'teams'and' par;cipate'as'needed.' ' 3. WORST)CASE:'Specialists'do'not'par;cipate'in'a' sprint,'but'someone'on'the'team'takes' responsibility'for'working'with'them.'
  42. 42. Architect'Roles' • Enterprise'Architect'' (policies'&'standards)' • Infrastructure'Architect'' (systems'&'network'design)' • Solu;on'Architect'' (advisory'&'governance)'' • Applica;on'Architect'' (on'teams)'
  43. 43. Where'to'Plug'In?' Monday) Tuesday) Wednesday) Thursday) Friday) Sprint)) 1) Sprint)) 2) Sprint)Planning) Sprint)Planning) LDUF) PB)Grooming) PB)Crea@on) PB)Sizing) Release)Planning) PB)Grooming) Sprint)Review) Retrospec@ve) Sprint)Review) Retrospec@ve)
  44. 44. Agenda' ! Agile and Architecture ! Reducing Technical Risks ! Team Makeup & Roles ! Architecture Anti-Patterns
  45. 45. Logic'in'Wrong'Layer' Think about what would need to change in other layers if one was swapped out or modified. Presentation Controller Façade Business Integration Persistence S h a r e d
  46. 46. No'Architectural'Vision' ! A single architecture vision should be well defined and communicated across the team and organization. ! The vision should map to business goals and objectives. ! All decisions should be made with this vision in mind.
  47. 47. Swiss'Army'Knife' ! Do not try to anticipate every possible use of the system and over-design the interfaces - this will lead to needless complexity. ! Do the simplest thing that works, within the Architectural Vision.
  48. 48. Threading' Do your homework! ✓ Typically not necessary ✓ Adds massive complexity ✓ Hard to maintain, test, and debug ✓ Rely on the application frameworks threads
  49. 49. Caching' Do your homework! ✓ Do you even need a cache? ✓ Can you keep everything in memory? ✓ Rely on persistence framework’s caching
  50. 50. Ivory'Tower'Architect' ! It is very hard to truly know the best solutions for design problems if you are not working (coding) on the project. ! It takes many iterations of a solution before it finally works - so you can’t suggest a solution then leave.
  51. 51. Custom'Frameworks' ! May seem like a good idea at first. But... – Who will maintain it? – Who will upgrade it when it’s depended upon libraries are upgraded? Java version? – How long will your new hires need to learn it? Who will teach them? ! Look for an off-the-shelf solution first. – You can hire/train people on it easier. – It will be upgraded for you.
  52. 52. So, to sum up…
  53. 53. Emergent'Architecture' Agile'architects'build' plans'and'founda;ons' that'embrace'change' ' Today’s'technologies'' and'enterprise'' frameworks'give'us' this'flexibility' We)just)need)to) take)advantage)of) them.)
  54. 54. Thank You! Don McGreal don.mcgreal@ImprovingEnterprises.com @donmcgreal linkedin.com/in/donmcgreal!
  55. 55. Questions? Don McGreal don.mcgreal@ImprovingEnterprises.com @donmcgreal linkedin.com/in/donmcgreal!

×