[PPT] - Deliberate Architecture Responding to Requirements over Following PowerPoint Presentation

SLIDE 1

@sixty_north

Deliberate Architecture

Responding to Requirements over Following Fashion

1

Dr Robert Smallshire

@robsmallshire

SLIDE 2 2

SLIDE 3 3

SLIDE 4 4

SLIDE 5 5

Gartner Hype Cycle

https://en.wikipedia.org/wiki/Hype_cycle

SLIDE 6 6

Gartner Hype Cycle

https://en.wikipedia.org/wiki/Hype_cycle

Pipes & Filters Layers Plug-ins MVCSoftware  Architecture  Practices SOA Agile Microservices Serverless Event-sourcing UML

SLIDE 7

7 Ambiguity Effect Anchoring Availability Heuristic Availability Cascade Bandwagon Effect Belief Bias Cheerleader Effect Choice-Supportive Bias Confjrmation Bias Declinism Endowment Effect Exaggerated Expectation Focussing Effect Hindsight-bias Hot-hand Fallacy Hyperbolic Discounting Illusory Truth Effect Sunk Cost Fallacy Mere Exposure Effect Negativity Bias Outcome Bias Post-purchase Rationalization Pro-Innovation Bias Projection Bias Subjective Validation Survivorship Bias Time-saving bias Recency Effect

SLIDE 8 8

SLIDE 9 9

security usability performance maintainability reliability cost robustness power efficiency deployability scalability testability fmexibility

SLIDE 10 10

SLIDE 11 11

Deliberate design for software qualities

SLIDE 12 12

Understand the incident forces

SLIDE 13 13

The System ( the 'solution' ) system boundary

users developers testers business

wners

customers marketing / sales management

Other system(s)

ther system

developers / owners

Incident forces

SLIDE 14 14

The System ( the 'solution' ) system boundary

users developers testers business

wners

customers marketing / sales management

Other system(s)

ther system

developers / owners

Fd Ft Fm Fo Fs Fb Fu Fc

Incident forces

SLIDE 15

But will your engineered structure support them, or buckle?

15

The incident forces will resolve to zero

Fd Ft Fm Fo Fs Fb Fu Fc

Fc + Fu + Fb + Fs + Fd + Ft + Fm + Fo = 0

ΣF = Ffunctions + Fqualities + Fconstraints + Fprinciples

SLIDE 16

Incident forces can be grouped into four terms

16

Factoring incident forces

Fprinciples Fconstraints Fqualities Ffunctions

ΣF = Ffunctions + Fqualities + Fconstraints + Fprinciples

features use cases functionality

What is it for?

non-functional requirements (NFRs) performance scalability security maintainability usability fault tolerance etc.

How well should it work? How would we like to build it?

architectural styles technology choices standards

What limits our approach?

cost legal / compliance time staff capacity staff experience

SLIDE 17

Incident forces can be grouped into four terms

17

Factoring incident forces

Fconstraints Fqualities Ffunctions

ΣF = Ffunctions + Fqualities + Fconstraints + Fprinciples

features use cases functionality

What is it for?

non-functional requirements (NFRs) performance scalability security maintainability cost fault tolerance etc.

How well should it work? How would we like to build it?

architectural styles technology choices standards

What limits our approach?

cost legal / compliance time staff capacity staff experience

Fprinciples

SLIDE 18 18

Inputs (Requirements) Outputs (Experienced) Functional Requirements Features Non-Functional  Requirements Qualities Ingredients + Recipe Taste + Texture

SLIDE 19 19

Features Qualities

Bass Clements & Kazman (2003) Software Architecture in Practice “Functionality and quality atuributes are

rthogonal.”
Explicitly captured
Intentional
Tracked
Designed / Implemented
Tested / Verifjed
Documented
Digital
Informally captured
Emergent
Untraceable
Retroactively redressed
Monitored
Undocumented
Analogue

SLIDE 20 20

Features Qualities

Bass Clements & Kazman (2003) Software Architecture in Practice “Functionality and quality atuributes are

rthogonal.”

ideallybutunachievably

Explicitly captured
Intentional
Tracked
Designed / Implemented
Tested / Verifjed
Documented
Digital
Informally captured
Emergent
Untraceable
Retroactively redressed
Monitored
Undocumented
Analogue

SLIDE 21 21

SLIDE 22 22

George Henry Lewes 1817–1878 “Every resultant is either a sum or a difference of the co-operant forces; their sum, when their directions are the same – their difference, when their directions are

contrary. Further, every resultant is clearly

traceable in its components, because these are homogeneous and commensurable. It is

therwise 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-

peration of things of unlike kinds. Tie

emergent is unlike its components insofar as these are incommensurable, and it cannot be reduced to their sum or their difference.”

SLIDE 23 23

emergent accidental

SLIDE 24

The System Features Qualities Required Constraints Actual M a i n t a i n a b i l i t y U s a b i l i t y S c a l a b i l i t y e m e r g e n t q u a l i t i e s Defects ×1000 cross-cutting concerns Software Architecture Agile Process

facilitates delivers deliberate design for constrains ‘how’

𝚬wellness

SLIDE 25 25

“However beautiful the strategy, you should

ccasionally look at the results”

Winston Churchill

SLIDE 26

Many local maxima which are globally suboptimal

Fitness landscapes of software qualities

26

https://commons.wikimedia.org/wiki/File:Visualization_of_two_dimensions_of_a_NK_fjtness_landscape.png

SLIDE 27

Navigating this space is what makes software architecture difficult

High-dimensional software quality space

27

security usability performance maintainability reliability cost robustness power efficiency deployability scalability testability fmexibility

https://commons.wikimedia.org/wiki/File:SWAG_Fitness_Landscape.png

SLIDE 28 28

Architecture as a counterbalance to ‘agile’ featurism

SLIDE 29

Different structures can deliver the same functionality

Functionality is independent of structure

29

Web Application Native iOS Application

Interoperability Portability Usability Maintainability Deployability Performance Interoperability Portability Usability Deployability Performance Maintainability

Identical Functionality

SLIDE 30

Different structures can deliver the same functionality

Functionality is independent of structure

30

Mobile Web Application Native iOS Application

Interoperability Portability Usability Maintainability Deployability Performance Interoperability Portability Usability Deployability Performance Maintainability Main

SLIDE 31 31

Microservices Layered Monolith Three Tier Architecture

31

Resilience Operability Modifjability (Replaceability) Maintainability Performance formance Resilience Operability Modifjability Deployability Maintainability Performance Resilience Operability Modifjability Deployability Maintainability Performance Deployability

SLIDE 32 32 UNIVERSITY OF CALIFORNIA, IRVINE Architectural Styles and the Design of Network-based Software Architectures DISSERTATION submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in Information and Computer Science by Roy Thomas Fielding Dissertation Committee: Professor Richard N. Taylor, Chair Professor Mark S. Ackerman Professor David S. Rosenblum 2000 15 architecture may be composed of multiple styles. Likewise, a hybrid style can be formed by combining multiple basic styles into a single coordinated style. Some architectural styles are often portrayed as “silver bullet” solutions for all forms

f software. However, a good designer should select a style that matches the needs of the

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 architectural styles and the particular concerns they address, and the ability to anticipate the sensitivity of each interaction style to the characteristics of network-based communication [133]. Unfortunately, using the term style to refer to a coordinated set of constraints often 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 denigrating the notion that personal stylistic concerns have any place in the work of a 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 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 designer’s goals. Since referring to a named set of constraints as a style makes it easier to communicate the characteristics of common constraints, we use architectural styles as a method of abstraction, rather than as an indicator of personalized design.

“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 particular problem being solved”

SLIDE 33 33

ARCHITECTURE

Fundamental Issues

Forrest Wilson

with William Loerke and Ron Keenberg

Personal stylistic concerns have no place in the work of the professional architect.

SLIDE 34

TODO IMPEDED DOING DONE

SLIDE 35 35

https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done

The code is well written The code is checked in [Doh!] The code was pair programmed/peer reviewed The code comes with tests at all appropriate levels The feature the code implements has been documented Definition of Done Q u a l i t i e s ? ! The change doesn’t degrade any software qualities below acceptable levels

SLIDE 36

TODO IMPEDED DOING ALMOST DONE NEARL Y THERE

SLIDE 37 37

Monitoring

SLIDE 38

Who cares about the system?

38

The System ( the 'solution' )

Stakeholders

system boundary

users developers testers business

wners

customers marketing / sales management

Other system(s)

ther system

developers / owners

SLIDE 39

Success depends on who participates

39

The System ( the 'solution' )

Stakeholders

users developers testers business

wners

customers marketing / sales management technical authors analysts trainers supporters

perations

system integrators designers architects sys-admins

SLIDE 40

Who cares about the system?

40

The System ( the 'solution' )

Functionality

users developers testers business

wners

customers marketing / sales management technical authors analysts trainers supporters

perations

system integrators designers architects sys-admins

SLIDE 41

Who cares about the system?

41

The System ( the 'solution' )

Development and maintenance costs

users developers testers business

wners

customers marketing / sales management technical authors analysts trainers supporters

perations

system integrators designers architects sys-admins

SLIDE 42

Who cares about the system?

42

The System ( the 'solution' )

Usability

users developers testers business

wners

customers marketing / sales management technical authors analysts trainers supporters

perations

system integrators designers architects sys-admins

SLIDE 43

Who cares about the system?

43

The System ( the 'solution' )

Performance or scalability

users developers testers business

wners

customers marketing / sales management technical authors analysts trainers supporters

perations

system integrators designers architects sys-admins

SLIDE 44 44

Architect as champion for software qualities

SLIDE 45 45

SLIDE 46 46

You look after the quality attributes  The features will look after themselves