Software architecture for developers by Simon Brown

3,946 views

Published on

The agile and software craftsmanship movements are pushing up the quality of the software systems we build, but there’s more we can do because even a small amount of software architecture can prevent many of the problems that projects still face, particularly if the team seems to be more chaotic than they are self-organising. Successful software projects aren’t just about good code and sometimes you need to step away from the IDE for a few moments to see the bigger picture. This session is about that bigger picture, software architecture, technical leadership and the balance with agility.

Published in: Technology, Economy & Finance

Software architecture for developers by Simon Brown

  1. 1. Follow me on Twitter @simonbrownSimon BrownSoftware architecture for developers
  2. 2. I help software teams understandsoftware architecture,technical leadership andthe balance with agility(I code too)Training Book SpeakingBuy the book for $10YI85bLbAXGks(expires 30th March 2013)
  3. 3. simon.brown@codingthearchitecture.com@simonbrown on TwitterJersey, Channel Islands
  4. 4. What is softwarearchitecture?
  5. 5. What is architecture?As a noun...StructureThe definition of something in termsof its components and interactions As a verb...VisionThe process of architecting,making (significant) design decisions, etcand
  6. 6. Grady Boochhttp://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog&part=2006What is design?Architecture represents thesignificant decisions,where significance is measuredby cost of change.Can you refactorit in an afternoon?
  7. 7. Chaos!Does the team understand what they are building and how they are building it?
  8. 8. Chaos!Does the team understand what they are building and how they are building it?No defined structure,inconsistent approaches,big ball of mud,spaghetti code, ...STOPSlow, insecure, unstable, unmaintainable,hard to deploy, hard to change,over time, over budget, ...
  9. 9. Shared vision ofTL; DRSoftwareArchitectureDocument
  10. 10. Shared vision ofWTF?!
  11. 11. The softwarearchitecture role
  12. 12. The software architecture role isdifferentto the lead developer roleIt’s an inward andoutward facing role
  13. 13. It’s about thebigpicture
  14. 14. Abstract SpecificAs software developers, thecodeis usually our main focusLines of codeClasses, functionsDesign patternsUnit testsRefactoring
  15. 15. Abstract SpecificSometimes you need tostep backfrom the IDELines of codeClasses, functionsDesign patternsUnit testsRefactoring
  16. 16. The low-level detailis equally importantDon’t code 100% ofthe time though!
  17. 17. Would wecodeit that way?
  18. 18. All decisionsinvolve atrade-off
  19. 19. Should software architects writecodeon software projects?Ideally yes, but...
  20. 20. Software architectsmust bemaster buildersAnd coding is a great wayto retain this skillPlus it reduces many of theproblems associated withivory tower architecture
  21. 21. DepthDeep hands-on technologyskills and knowledgeBreadthBroad knowledge ofpatterns, designs,approaches, technologies,non-functional requirements,different ways of working, etc...options and trade-offsGeneralisingSpecialist
  22. 22. Every softwaredevelopment teamneeds amaster builder1 or many
  23. 23. Software architecture is abouttechnicalandsoft skills
  24. 24. Software ArchitectLeadershipCommunicationInfluencingNegotiationCollaborationCoaching and MentoringMotivationFacilitationPolitical
  25. 25. The irresponsible architectCross-site scripting attackspossible; weak passwordsallowed; HTTP sessionsdidn’t timeout; ...Basic functionality errors;little or no qualityassurance; rework requiredlate in the project becauseof assumptions; ...Even on“strategic platform”projects :-oNo non-functional testing(e.g. penetration testing orload testing); ...No documentation; ...
  26. 26. The software architecture roleArchitecturalDriversUnderstanding requirementsand constraintsArchitectureEvolutionOwnership of the architecturethroughout the deliveryCoaching andMentoringGuidance and assistanceQualityAssuranceIntroduction and adherenceto standards and principlesCodingInvolvement in the hands-onelements of software deliveryTechnologySelectionChoosing and evaluatingtechnologyArchitectingDesigning softwareArchitectureEvaluationUnderstanding that thearchitecture works
  27. 27. Software architecture introducescontrol?
  28. 28. Chaos!Does the team understand what they are building and how they are building it?Let’s agreeon some thingsLet’s make the implicit,explicitPut some boundariesand guidelines in place
  29. 29. Software ArchitectSoftware DevelopersControlGuidelines, consistency,discipline, rigour, boundaries,...Feedback“I don’t understand why...”“How should we...”“I don’t like the way that...”
  30. 30. Developer Developer Developer Developer DeveloperGapArchitectSits in an ivory towerFocusses on thelow level detail
  31. 31. Collaborating andsharingArchitecturallyawareSoftware ArchitectSoftware DeveloperReduced gapAvoid ivory towers bycollaborating andbeing engagedDo this well and everybodybecomes an architect :-)
  32. 32. Designingsoftware
  33. 33. 1. Current SituationWe have an existing Internet Banking offering that allows customers to securely viewinformation about their bank accounts held with us via the web. Although we were one of thefirst to market with such a product, the system itself is a number of years old now and a seriesof problems has been identified during a consulting exercise that we recently initiated. Insummary:• The system only provides customers with read-only access to information about theirbank accounts. This includes account balances, recent transactions and recentstatements.• The information presented to customers is slightly out-of-date, because information fromthe core banking system is exported to the website on a nightly basis.• Transactional requests are not possible through the site, with customers instead sendinga secure message to the call centre with their request instead. This process is open toabuse and fraud.• The number of features supported by the offering is limited.• The technology is no longer seen as “leading edge”, is hard to enhance and costly tomaintain. In addition, the technology has reached “end of life” and is no longerproactively supported by the vendor.• The system doesn’t meet current website accessibility standards.In a recent survey, our Internet Banking system was perceived as poor in terms of the userexperience and the level of information available through the website. With our competitorsnow offering fully transactional systems, there is a risk that we will lose business.2. VisionThe board have given us the go-ahead to initiate a project to replace the current InternetBanking system, which will need to coincide with the corporate rebranding that will be takingplace in 12 weeks. The replacement system should:• Provide customers with real-time access to information about their bank accounts.• Provide customers with the ability to perform common transactions through the website.This includes making payments, setting up standing orders, transferring money and so on.• Provide customers with a rich user experience.• Meet current website accessibility standards.• Be developed using the new corporate website design guidelines.Big Bank plcInternet Banking SystemOptionsFunctional&non-functionalrequirementsPrinciplesConstraints
  34. 34. (003) As a business customer, Iwant to login so that I can managemy bank accounts online.Priority: Must(009) As a personal customer Iwant to download statements forthe last three months.Priority: MustUnderstanding the functional requirements isobvious but forgotten(003) As a business customer, Iwant to login so that I can managemy bank accounts online.Priority: Must(009) As a personal customer Iwant to download statements forthe last three months.Priority: Must
  35. 35. PerformanceScalabilityAvailabilitySecurityDisaster RecoveryAccessibilityMonitoringManagementAudit...FlexibilityExtensibilityMaintainabilityInteroperabilityLegalRegulatoryCompliancei18nL10n...✓✓✓✓✓✓✓✓Know which areimportant to youQuality Attributes
  36. 36. Learn about and understand the(often complex) quality attributesin order to buildsufficientfoundations
  37. 37. Software lives in the real world,and the real world hasconstraintsConstraints are usuallyforced upon you
  38. 38. Understand what the constraints are,who imposed them,why they are being imposed andhow they affect thearchitectureGiven total freedom thework is likely to sprawl.T.S.Eliot
  39. 39. Principlesare the thingsyou want to adoptThey help to introduceconsistency and clarity
  40. 40. Principles are good, but make surethey’re realisticand don’t have anegative impact
  41. 41. 1. Current SituationWe have an existing Internet Banking offering that allows customers to securely viewinformation about their bank accounts held with us via the web. Although we were one of thefirst to market with such a product, the system itself is a number of years old now and a seriesof problems has been identified during a consulting exercise that we recently initiated. Insummary:• The system only provides customers with read-only access to information about theirbank accounts. This includes account balances, recent transactions and recentstatements.• The information presented to customers is slightly out-of-date, because information fromthe core banking system is exported to the website on a nightly basis.• Transactional requests are not possible through the site, with customers instead sendinga secure message to the call centre with their request instead. This process is open toabuse and fraud.• The number of features supported by the offering is limited.• The technology is no longer seen as “leading edge”, is hard to enhance and costly tomaintain. In addition, the technology has reached “end of life” and is no longerproactively supported by the vendor.• The system doesn’t meet current website accessibility standards.In a recent survey, our Internet Banking system was perceived as poor in terms of the userexperience and the level of information available through the website. With our competitorsnow offering fully transactional systems, there is a risk that we will lose business.2. VisionThe board have given us the go-ahead to initiate a project to replace the current InternetBanking system, which will need to coincide with the corporate rebranding that will be takingplace in 12 weeks. The replacement system should:• Provide customers with real-time access to information about their bank accounts.• Provide customers with the ability to perform common transactions through the website.This includes making payments, setting up standing orders, transferring money and so on.• Provide customers with a rich user experience.• Meet current website accessibility standards.• Be developed using the new corporate website design guidelines.Big Bank plcInternet Banking SystemOptionsFunctional&non-functionalrequirementsPrinciplesConstraints
  42. 42. Start analysingor start coding?“Analysis paralysis” &“refactor distractor”are both bad
  43. 43. Boxes & linesThingOther ThingImportant line
  44. 44. Visualisingsoftware
  45. 45. UML tool?Whiteboard orflip chart?You don’t need a UMLtool to do architecturebut agree on notation
  46. 46. Collaborative design(e.g. pair architecting)
  47. 47. NoUMLdiagrams?
  48. 48. We can visualise our process......but not oursoftware!
  49. 49. Moving fast (agility) requiresgoodcommunication
  50. 50. SystemContainerContainerContainerComponentComponentComponentClassClass ClassClass
  51. 51. 1. Context 2. Containers 3. ComponentsThinking inside the box... and, optionally,4. ClassesC4ContextContainersComponentsClassesThis only coversthe static structure(runtime, infrastructure,deployment, etc are also important)
  52. 52. This isn’t aboutcreating a standardIt’s about providing yousome organisational ideas
  53. 53. Context• What are we building?• Who is using it? (users, actors, roles, personas, etc)• How does it fit into the existing IT environment?
  54. 54. • What are the high-level technology decisions?• How do containers communicate with one another?• As a developer, where do I need to write code?Containers
  55. 55. Components• What components/services is the system made up of?• Is it clear how the system works at a high-level?• Do all components have a home (a container)?
  56. 56. Some tips foreffective sketchesTitlesShort and meaningful, numbered ifdiagram order is importantLinesMake line style and arrows explicit,add annotations to lines to provideadditional informationLayoutSticky notes and index cards make agreat substitute for drawn boxes,especially early onLabelsBe wary of using acronymsColourEnsure that colour codingis made explicitOrientationUsers at the top and database at thebottom? Or perhaps “upside-down”?ShapesDon’t assume that people willunderstand what different shapesare being used forBordersUse borders to provide emphasisor group related items,but ensure people know whyKeysExplain shapes, lines, colours,borders, acronyms, etcResponsibilitiesAdding responsibilities to boxes canprovide a nice “at a glance” view(Miller’s Law; 7±2)
  57. 57. Effective sketchesare an excellent way tocommunicatesoftware architectureDuring the design processand retrospectively
  58. 58. Documentingsoftware
  59. 59. “Working softwareovercomprehensivedocumentationThis doesn’t mean“don’t do anydocumentation”!Manifesto for Agile Software Development, 2001
  60. 60. The code doesn’t tellthe *whole* story,but it does *a* story
  61. 61. Tribalknowledge“just talk!”“diagrams and documentsare just propsfor conversations”
  62. 62. The bus factor(it’s not just about buses though!)Any idea how Xworks?No idea whatyou’re on about...#fail
  63. 63. Your systemCurrent Development TeamDatabase AdministratorsBusiness SponsorsOperations/Support StaffCompliance and AuditSecurity TeamOther TeamsFuture Development TeamSoftware architectureis a platform forconversation ... be social!
  64. 64. SoftwareArchitectureDocumentGuidebookMapsSights anditinerariesHistory andculturePracticalInformation
  65. 65. FunctionalOverviewWhat does the system do?QualityAttributesAre there any significantnon-functionalrequirements?ConstraintsAre there any significantconstraints?PrinciplesWhat design anddevelopment principleshave been adopted?SoftwareArchitectureWhat does the big picturelook like and how is thesystem structured?InfrastructureArchitectureWhat does the targetdeploymentenvironment look like?DeploymentWhat is the mappingbetween software andinfrastructure?Operation& SupportHow will people operateand support the system?ContextWhat is this all about?ExternalInterfacesWhat are the externalsystem interfaces?CodeAre there anyimplementation detailsyou need to explain?DataWhat does the data modellook like and where is itbeing stored?
  66. 66. Documentation shoulddescribe whatthe code doesn’tReduce waste,add valueUse it to explain intent andact as a guide to navigatethe source code
  67. 67. How much of the document isup to date and relevant?
  68. 68. Software architecture in thedevelopmentlifecycle
  69. 69. AaaS ... architecture as a serviceSoftware development is not arelay sportSoftwareArchitectureDocument
  70. 70. The software architecturerole should be engagedthroughout(not just analysis and design)
  71. 71. How much up front design should you do?Big design up front?Emergent design?(or none, depending onyour viewpoint!)Something in between?Waterfall
  72. 72. You should do“just enough”
  73. 73. Base your architecture onrequirements, travel lightand prove your architecturewith concrete experiments.Base your architecture onrequirements, travel lightand prove your architecturewith concrete experiments.Base your architecture onrequirements, travel lightand prove your architecturewith concrete experiments.Scott Amblerhttp://www.agilemodeling.com/essays/agileArchitecture.htm
  74. 74. What is architecturallysignificant?Costly to change(can you refactor itin an afternoon?)ComplexNew
  75. 75. You need toidentify and mitigateyour highest priorityrisksThings that will causeyour project to failor you to be fired!
  76. 76. ProbabilityImpact Low (1) Medium (2) High (3)Low(1)Medium(2)High(3)1 22 433 669
  77. 77. Who looks after the riskson most software projects?A (usually) non-technical project manager!
  78. 78. Risk-stormingA collaborative and visual technique for identifying risk
  79. 79. You still need todeal with the risks(mitigation strategies include hiring people,undertaking proof of conceptand changing your architecture)
  80. 80. How much up front design should you do?“Just enough”Understand how thesignificant elementsfit togetherIdentify and mitigatethe key risksProvide firm foundationsand a visionto move forward
  81. 81. The software architecture role andthe process of software architecting aredifferent
  82. 82. From chaos to self-organisingDedicatedsoftware architectSingle point of responsibility forthe technical aspects of thesoftware projectEverybody is asoftware architectJoint responsibility for thetechnical aspects of thesoftware projectThe software architecture roleElastic Leadership (Roy Osherove)Survival (command and control),learning (coaching),self-organising (facilitation)
  83. 83. SoftwareArchitectureDocumentFrom big design up front to evolutionaryThe process of software architectingBig up front designRequirements capture, analysisand design complete beforecoding startsEvolutionaryarchitectureThe architecture evolvessecondary to the value createdby early regular releases ofworking software/// <summary>/// Represents the behaviour behind the .../// </summary>public class SomeWizard : AbstractWizard{private DomainObject _object;private WizardPage _page;private WizardController _controller;public SomeWizard(){}...}
  84. 84. /// <summary>/// Represents the behaviour behind the .../// </summary>public class SomeWizard : AbstractWizard{private DomainObject _object;private WizardPage _page;private WizardController _controller;public SomeWizard(){}...}21st century software architecture“just enough”The roleThe processUnderstand how thesignificant elementsfit togetherIdentify and mitigatethe key risksProvide firm foundationsand a visionto move forwardSoftwareArchitectureDocument
  85. 85. youDo whatever works for
  86. 86. Buy the book for $10YI85bLbAXGks(expires 30th March 2013)

×