Your SlideShare is downloading. ×
0
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Software architecture for developers by Simon Brown
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software architecture for developers by Simon Brown

2,675

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 …

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
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,675
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
262
Comments
0
Likes
10
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Follow me on Twitter @simonbrownSimon BrownSoftware architecture for developers
  • 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. simon.brown@codingthearchitecture.com@simonbrown on TwitterJersey, Channel Islands
  • 4. What is softwarearchitecture?
  • 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. 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. Chaos!Does the team understand what they are building and how they are building it?
  • 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. Shared vision ofTL; DRSoftwareArchitectureDocument
  • 10. Shared vision ofWTF?!
  • 11. The softwarearchitecture role
  • 12. The software architecture role isdifferentto the lead developer roleIt’s an inward andoutward facing role
  • 13. It’s about thebigpicture
  • 14. Abstract SpecificAs software developers, thecodeis usually our main focusLines of codeClasses, functionsDesign patternsUnit testsRefactoring
  • 15. Abstract SpecificSometimes you need tostep backfrom the IDELines of codeClasses, functionsDesign patternsUnit testsRefactoring
  • 16. The low-level detailis equally importantDon’t code 100% ofthe time though!
  • 17. Would wecodeit that way?
  • 18. All decisionsinvolve atrade-off
  • 19. Should software architects writecodeon software projects?Ideally yes, but...
  • 20. Software architectsmust bemaster buildersAnd coding is a great wayto retain this skillPlus it reduces many of theproblems associated withivory tower architecture
  • 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. Every softwaredevelopment teamneeds amaster builder1 or many
  • 23. Software architecture is abouttechnicalandsoft skills
  • 24. Software ArchitectLeadershipCommunicationInfluencingNegotiationCollaborationCoaching and MentoringMotivationFacilitationPolitical
  • 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. 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. Software architecture introducescontrol?
  • 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. Software ArchitectSoftware DevelopersControlGuidelines, consistency,discipline, rigour, boundaries,...Feedback“I don’t understand why...”“How should we...”“I don’t like the way that...”
  • 30. Developer Developer Developer Developer DeveloperGapArchitectSits in an ivory towerFocusses on thelow level detail
  • 31. Collaborating andsharingArchitecturallyawareSoftware ArchitectSoftware DeveloperReduced gapAvoid ivory towers bycollaborating andbeing engagedDo this well and everybodybecomes an architect :-)
  • 32. Designingsoftware
  • 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. (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. PerformanceScalabilityAvailabilitySecurityDisaster RecoveryAccessibilityMonitoringManagementAudit...FlexibilityExtensibilityMaintainabilityInteroperabilityLegalRegulatoryCompliancei18nL10n...✓✓✓✓✓✓✓✓Know which areimportant to youQuality Attributes
  • 36. Learn about and understand the(often complex) quality attributesin order to buildsufficientfoundations
  • 37. Software lives in the real world,and the real world hasconstraintsConstraints are usuallyforced upon you
  • 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. Principlesare the thingsyou want to adoptThey help to introduceconsistency and clarity
  • 40. Principles are good, but make surethey’re realisticand don’t have anegative impact
  • 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. Start analysingor start coding?“Analysis paralysis” &“refactor distractor”are both bad
  • 43. Boxes & linesThingOther ThingImportant line
  • 44. Visualisingsoftware
  • 45. UML tool?Whiteboard orflip chart?You don’t need a UMLtool to do architecturebut agree on notation
  • 46. Collaborative design(e.g. pair architecting)
  • 47. NoUMLdiagrams?
  • 48. We can visualise our process......but not oursoftware!
  • 49. Moving fast (agility) requiresgoodcommunication
  • 50. SystemContainerContainerContainerComponentComponentComponentClassClass ClassClass
  • 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. This isn’t aboutcreating a standardIt’s about providing yousome organisational ideas
  • 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. • 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. 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. 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. Effective sketchesare an excellent way tocommunicatesoftware architectureDuring the design processand retrospectively
  • 58. Documentingsoftware
  • 59. “Working softwareovercomprehensivedocumentationThis doesn’t mean“don’t do anydocumentation”!Manifesto for Agile Software Development, 2001
  • 60. The code doesn’t tellthe *whole* story,but it does *a* story
  • 61. Tribalknowledge“just talk!”“diagrams and documentsare just propsfor conversations”
  • 62. The bus factor(it’s not just about buses though!)Any idea how Xworks?No idea whatyou’re on about...#fail
  • 63. Your systemCurrent Development TeamDatabase AdministratorsBusiness SponsorsOperations/Support StaffCompliance and AuditSecurity TeamOther TeamsFuture Development TeamSoftware architectureis a platform forconversation ... be social!
  • 64. SoftwareArchitectureDocumentGuidebookMapsSights anditinerariesHistory andculturePracticalInformation
  • 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. Documentation shoulddescribe whatthe code doesn’tReduce waste,add valueUse it to explain intent andact as a guide to navigatethe source code
  • 67. How much of the document isup to date and relevant?
  • 68. Software architecture in thedevelopmentlifecycle
  • 69. AaaS ... architecture as a serviceSoftware development is not arelay sportSoftwareArchitectureDocument
  • 70. The software architecturerole should be engagedthroughout(not just analysis and design)
  • 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. You should do“just enough”
  • 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. What is architecturallysignificant?Costly to change(can you refactor itin an afternoon?)ComplexNew
  • 75. You need toidentify and mitigateyour highest priorityrisksThings that will causeyour project to failor you to be fired!
  • 76. ProbabilityImpact Low (1) Medium (2) High (3)Low(1)Medium(2)High(3)1 22 433 669
  • 77. Who looks after the riskson most software projects?A (usually) non-technical project manager!
  • 78. Risk-stormingA collaborative and visual technique for identifying risk
  • 79. You still need todeal with the risks(mitigation strategies include hiring people,undertaking proof of conceptand changing your architecture)
  • 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. The software architecture role andthe process of software architecting aredifferent
  • 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. 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. /// <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. youDo whatever works for
  • 86. Buy the book for $10YI85bLbAXGks(expires 30th March 2013)

×