ASAS 2014 - Simon Brown
4 likes1,221 views
The document discusses the need for software teams to establish firm foundations for their projects through initial architectural design. It advocates doing just enough upfront design to understand significant structural elements and create a shared vision, context and initial container/component model, rather than detailed blueprints. This approach balances the need for initial structure with ongoing agility. Risks should also be identified and mitigated through techniques like risk-storming and concrete experiments.
ASAS 2014 - Simon Brown
- 1. Firm Foundations Simon Brown @simonbrown
- 2. Jersey
- 4. I help software teams understand software architecture, technical leadership and the balance with agility I code too ⇧ ; - ⇧ 0
- 5. Software architecture needs to be more accessible
- 6. A developer-friendly guide to software architecture, technical leadership and the balance with agility 10 out of 10 “Highly recommended reading” ! Junilu Lacar, JavaRanch http://leanpub.com/software-architecture-for-developers
- 7. In previous ASAS editions…
- 8. 2012 The conflict between agile and architecture
- 9. The conflict between agile and architecture Myth or reality?
- 10. 1. A conflict in team structure Dedicated software architect ! Single point of responsibility for the technical aspects of the software project Everybody is a software architect ! Joint responsibility for the technical aspects of the software project vs
- 11. 2. A conflict in process Software Architecture Document Big up front design ! Requirements capture, analysis and design complete before coding starts /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; ! public SomeWizard() { } ! Evolutionary architecture ! The architecture evolves secondary to the value created by early regular releases of working software ... !} vs
- 12. 2013 Agility and the essence of software architecture
- 13. A good architecture enables agility
- 14. Monolithic architecture Service-based architecture (SOA, micro-services, etc) Something in between (components)
- 16. “Big design up front is dumb. ! Doing no design up front is even dumber.” ! (Dave Thomas)
- 18. Beyond Scrum DSDM Atern Disciplined Agile Delivery (DAD) Scaled Agile Framework (SAFe)
- 19. “The Atern lifecycle process” (from http://dsdm.org/content/6-lifecycle)
- 20. “ The Foundations phase is aimed at establishing firm and enduring foundations for the project. ”
- 21. Software development is not a relay sport Software Architecture Document AaaS ... architecture as a service
- 22. It’s not about creating a perfect end-state, framework or complete architecture
- 23. You need a starting point
- 24. I often need to be the process guy…
- 25. Structure
- 26. Whiteboards and context diagrams
- 28. Whiteboards and domain diagrams
- 31. Pair* architecting * two or more people
- 32. We’re trying to design some software; not create a fluffy, conceptual solution
- 33. Should software design be technology agnostic?
- 34. “the solution is simple and can be built with any technology” ! “we don't want to force a solution on developers” ! "it's an implementation detail” ! “we follow the ‘last responsible moment’ principle” Risk System 1. Context A global investment bank based in London, New York and Singapore trades (buys and sells) financial products with other banks (counterparties). When share prices on the stock markets move up or down, the bank either makes money or loses it. At the end of the working day, the bank needs to gain a view of how much risk they are exposed to (e.g. of losing money) by running some calculations on the data held about their trades. The bank has an existing Trade Data System (TDS) and Reference Data System (RDS) but need a new Risk System. Trade Data System Reference Data System Risk System 1.1. Trade Data System The Trade Data System maintains a store of all trades made by the bank. It is already configured to generate a file-based XML export of trade data at the close of business (5pm) in New York. The export includes the following information for every trade made by the bank: • Tr ad e ID • Date • Current trade value in US dollars • Counterparty ID 1.2. Reference Data System The Reference Data System maintains all of the reference data needed by the bank. This includes information about counterparties; each of which represents an individual, a bank, etc. A file-based XML export is also available and includes basic information about each counterparty.
- 36. Significant decisions can be moved but rarely eliminated Web Application Another abstraction layer Database Abstraction Layer (e.g. ORM) Relational Database
- 37. Technology is not an “implementation detail”
- 38. A common set of abstractions is more important than a common notation
- 39. Software System Container Container (e.g. web server, application server, standalone application, (e.g. web server, application browser, database, file system, etc) application, database, Component Component Component Class Class Class Container application server, standalone database, file system, etc) Agree on a simple set of abstractions that the whole team can use to communicate
- 40. Components Classes, Responsibilities, Collaborations
- 41. An initial set of components
- 42. Abstraction is about reducing detail rather than creating a different representation
- 43. Software architecture vs code
- 44. Does your code reflect the abstractions that you think about?
- 45. Agree upon some principles If you genuinely don’t know what you’re building (and therefore can’t create a component model), agree on some principles that you will use to structure your software
- 46. Structure Components, technologies, principles
- 47. Vision
- 48. Detailed blueprints! ! vs setting a direction
- 49. In my experience, software teams aren’t able to effectively communicate the software architecture of their systems
- 50. The C4 model System Context The system plus users and system dependencies Containers The overall shape of the architecture and technology choices Components Logical components and their interactions within a container Classes Component or pattern implementation details
- 52. Context ! •What are we building? ! •Who is using it? (users, actors, roles, personas, etc) ! •How does it fit into the existing IT environment? (systems, services, etc)
- 53. Containers ! •What are the high-level technology decisions? (including responsibilities) ! •How do containers communicate with one another? ! •As a developer, where do I need to write code?
- 54. Components ! •What components/ services is the container made up of? ! •Are the technology choices and responsibilities clear?
- 56. Sketches will become out of date
- 57. Software architecture as code
- 59. Software architecture model as code -> JSON -> diagrams
- 60. structurizr.com
- 61. Risks
- 62. An example timeline from “Beyond Retrospectives” by Linda Rising ! #gotocon Aarhus 2011
- 63. Base your architecture on requirements, travel light and prove your architecture with concrete experiments. Scott Ambler http://www.agilemodeling.com/essays/agileArchitecture.htm
- 64. Web tier Concrete experiments (prototype, proof of concept or production code) Middle tier Database tier
- 65. What is architecturally significant? Costly to change Complex New
- 66. You need to identify and mitigate your highest priority risks
- 67. Security holes/breaches, data loss, network outages, server outages, poor performance, poor scalability, deployment complexity, lack of skills, unproven technology, external interfaces changing, users doing things they shouldn’t…
- 68. Like estimates, risks are subjective
- 69. Risk-storming A collaborative and visual technique for identifying risk
- 70. You still need to deal with the risks (mitigation strategies include hiring people, undertaking proof of concept and changing your architecture)
- 71. Does your architecture work? (write code and test early if needed)
- 72. For structurizr.com ! Rendering a dynamic diagram in JavaScript Exporting that diagram to PNG Rackspace vs Pivotal Web Services
- 73. You can still get it wrong though!
- 74. In summary…
- 75. Risks ! Identify and mitigate the highest priority risks. ! ! ! ! ! ! Risk-storming and concrete experiments. Vision ! Create and communicate a vision for the team to work with. ! ! ! ! ! Context, container and component diagrams. Structure ! Understand the significant structural elements and how they fit together, based upon the architectural drivers. ! ! ! Design and decomposition down to containers and components. Just enough up front design to create firm foundations for the software product and its delivery
- 76. Requirements Context, Containers and Components Big Bank plc Internet Banking System How long? 1. Current Situation We have an existing Internet Banking offering that allows customers to securely view information about their bank accounts held with us via the web. Although we were one of the first to market with such a product, the system itself is a number of years old now and a series of problems has been identified during a consulting exercise that we recently initiated. In summary: • The system only provides customers with read-only access to information about their bank accounts. This includes account balances, recent transactions and recent statements. • The information presented to customers is slightly out-of-date, because information from the core banking system is exported to the website on a nightly basis. • Transactional requests are not possible through the site, with customers instead sending a secure message to the call centre with their request instead. This process is open to abuse 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 to maintain. In addition, the technology has reached “end of life” and is no longer proactively 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 user experience and the level of information available through the website. With our competitors now offering fully transactional systems, there is a risk that we will lose business. 2. Vision The board have given us the go-ahead to initiate a project to replace the current Internet Banking system, which will need to coincide with the corporate rebranding that will be taking place 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.
- 77. Firm foundations Create a sufficient starting point and set a direction, in a minimal amount of time, to stack the odds of success in your favour simon.brown@codingthearchitecture.com @simonbrown on Twitter