Deliberate Architecture Responding to Requirements over Following Fashion Dr Robert Smallshire @robsmallshire @sixty_north 1
2
3
4
Gartner Hype Cycle https://en.wikipedia.org/wiki/Hype_cycle 5
Gartner Hype Cycle Plug-ins UML Layers Microservices Agile Event-sourcing MVCSoftware Serverless SOA Pipes & Filters Architecture Practices https://en.wikipedia.org/wiki/Hype_cycle 6
Bandwagon E ff ect Anchoring Availability Heuristic Cheerleader E ff ect Availability Cascade Ambiguity E ff ect Belief Bias Hindsight-bias Con fj rmation Bias Endowment E ff ect Focussing E ff ect Recency E ff ect Exaggerated Expectation Declinism Pro-Innovation Bias Choice-Supportive Bias Sunk Cost Fallacy Post-purchase Rationalization Outcome Bias Illusory Truth E ff ect Negativity Bias Time-saving bias Survivorship Bias Mere Exposure E ff ect Hyperbolic Discounting Subjective Validation Hot-hand Fallacy Projection Bias 7
8
power scalability e ffi ciency fm exibility security performance reliability cost usability maintainability deployability testability robustness 9
10
Deliberate design for software qualities 11
Understand the incident forces 12
Incident forces system customers developers boundary users testers The System ( the 'solution' ) business management owners other system Other marketing / sales developers / owners system(s) 13
Incident forces system F c customers F d developers boundary F u F t users testers The System ( the 'solution' ) F b business F m management owners F o F s other system Other marketing / sales developers / owners system(s) 14
The incident forces will resolve to zero But will your engineered structure support them, or buckle? F c F d F u F t F b F m F o F s F c + F u + F b + F s + F d + F t + F m + F o = 0 Σ F = F functions + F qualities + F constraints + F principles 15
Factoring incident forces How well should it work? Incident forces can be grouped into four terms non-functional requirements (NFRs) performance What is it for? scalability features security F qualities use cases F functions maintainability functionality usability fault tolerance cost etc. legal / compliance F principles architectural styles time F constraints technology choices staff capacity standards staff experience How would we like to build it? What limits our approach? Σ F = F functions + F qualities + F constraints + F principles 16
Factoring incident forces How well should it work? Incident forces can be grouped into four terms non-functional requirements (NFRs) performance What is it for? F qualities scalability features security use cases F functions maintainability functionality cost fault tolerance cost etc. legal / compliance F principles architectural styles time technology choices staff capacity F constraints standards staff experience How would we like to build it? What limits our approach? Σ F = F functions + F qualities + F constraints + F principles 17
Inputs Outputs (Requirements) (Experienced) Functional Features Requirements Non-Functional Qualities Requirements Ingredients + Recipe Taste + Texture 18
‣ Explicitly captured Features ‣ Intentional ‣ Tracked ‣ Designed / Implemented ‣ Tested / Veri fj ed ‣ Documented “Functionality and quality a tu ributes are ‣ Digital orthogonal.” ‣ Informally captured Bass Clements & Kazman (2003) Software Architecture in Practice ‣ Emergent ‣ Untraceable ‣ Retroactively redressed ‣ Monitored Qualities ‣ Undocumented ‣ Analogue 19
‣ Explicitly captured ‣ Intentional Features ‣ Tracked ‣ Designed / Implemented ‣ Tested / Veri fj ed ‣ Documented “Functionality and quality a tu ributes are ‣ Digital ideally��but�unachievably� orthogonal.” ‣ Informally captured Bass Clements & Kazman (2003) Software Architecture in Practice ‣ Emergent ‣ Untraceable ‣ Retroactively redressed Qualities ‣ Monitored ‣ Undocumented ‣ Analogue 20
21
“Every resultant is either a sum or a di ff erence of the co-operant forces; their sum, when their directions are the same – their di ff erence, when their directions are contrary. Further, every resultant is clearly traceable in its components, because these are homogeneous and commensurable. It is otherwise with emergents, when, instead of adding measurable motion to measurable motion, or things of one kind to other individuals of their kind, there is a co- operation of things of unlike kinds. Ti e emergent is unlike its components insofar as these are incommensurable, and it cannot be George Henry Lewes reduced to their sum or their di ff erence.” 1817–1878 22
emergent accidental 23
Required Actual The System Agile delivers Features Process facilitates t constrains ‘how’ n e g Constraints s r e e i t m Software i deliberate l y e a t u i l design for i q b Architecture y a Qualities t n y i l i t i b a i l i a t b n l a a i a c s Defects M U S × 1000 cross-cutting concerns 𝚬 wellness
“However beautiful the strategy, you should occasionally look at the results” Winston Churchill 25
Fitness landscapes of software qualities Many local maxima which are globally suboptimal https://commons.wikimedia.org/wiki/File:Visualization_of_two_dimensions_of_a_NK_ fj tness_landscape.png 26
High-dimensional software quality space Navigating this space is what makes software architecture difficult power scalability e ffi ciency fm exibility security performance cost reliability usability maintainability deployability testability robustness https://commons.wikimedia.org/wiki/File:SWAG_Fitness_Landscape.png 27
Architecture as a counterbalance to ‘agile’ featurism 28
Functionality is independent of structure Di ff erent structures can deliver the same functionality Web Application Native iOS Application Identical Functionality Usability Usability Interoperability Interoperability Performance Performance Maintainability Maintainability Deployability Deployability Portability Portability 29
Functionality is independent of structure Di ff erent structures can deliver the same functionality Mobile Web Application Native iOS Application Usability Usability Interoperability Interoperability Performance Performance Main Maintainability Maintainability Deployability Deployability Portability Portability 30
Layered Three Tier Microservices Monolith Architecture Modi fj ability Modi fj ability Modi fj ability (Replaceability) Resilience Resilience Resilience Performance Performance Performance formance Maintainability Maintainability Maintainability Deployability Deployability Deployability Operability Operability Operability 31 31
architecture may be composed of multiple styles. Likewise, a hybrid style can be formed UNIVERSITY OF CALIFORNIA, by combining multiple basic styles into a single coordinated style. IRVINE Some architectural styles are often portrayed as “ silver bullet ” solutions for all forms of software. However, a good designer should select a style that matches the needs of the Architectural Styles and the Design of Network-based Software Architectures particular problem being solved [119]. Choosing the right architectural style for a network-based application requires an understanding of the problem domain [67] and thereby the communication needs of the application, an awareness of the variety of DISSERTATION architectural styles and the particular concerns they address, and the ability to anticipate submitted in partial satisfaction of the requirements for the degree of “Some architectural styles are often portrayed as “silver the sensitivity of each interaction style to the characteristics of network-based communication [133]. DOCTOR OF PHILOSOPHY Unfortunately, using the term style to refer to a coordinated set of constraints often bullet” solutions for all forms of software. However, a in Information and Computer Science leads to confusion. This usage differs substantially from the etymology of style , which would emphasize personalization of the design process. Loerke [76] devotes a chapter to good designer should select a style that matches the denigrating the notion that personal stylistic concerns have any place in the work of a by professional architect. Instead, he describes styles as the critics ’ view of past architecture, where the available choice of materials, the community culture, or the ego of the local Roy Thomas Fielding needs of the particular problem being solved” ruler were responsible for the architectural style, not the designer. In other words, Loerke views the real source of style in traditional building architecture to be the set of constraints applied to the design, and attaining or copying a specific style should be the least of the Dissertation Committee: designer ’ s goals. Since referring to a named set of constraints as a style makes it easier to Professor Richard N. Taylor, Chair Professor Mark S. Ackerman communicate the characteristics of common constraints, we use architectural styles as a Professor David S. Rosenblum method of abstraction, rather than as an indicator of personalized design. 2000 15 32
Recommend
More recommend
