Tweet
Tweet

Slide 1

Slide 1 text

Essential architectural thinking Why, what, when, how and how much? Uwe Friedrichsen – codecentric AG – 2006-2019

Slide 2

Slide 2 text

Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://medium.com/@ufried

Slide 3

Slide 3 text

Why we need architectural work

Slide 4

Slide 4 text

Architectural work without asking “why” …

Slide 5

Slide 5 text

BDUF architecture Big Design Upfront Stack-overflow architecture closely related to Conference-driven architecture Google-driven architecture “Agile” architecture a.k.a. “Emergent” architecture often in conjunction with “Death to all architects!” Developer-centric architecture “Strategic” architecture often found in conjunction with the “Powerpoint architect” “Architect” – step on the company career ladder working as fire accelerant … and many more anti-patterns

Slide 6

Slide 6 text

… results in a mess

Slide 7

Slide 7 text

And how do we try to address the problem?

Slide 8

Slide 8 text

We tend to discuss what architecture is instead of asking us why we need it or how to work on architecture

Slide 9

Slide 9 text

… which results in even worse archetypes

Slide 10

Slide 10 text

Hype-driven architecture

Slide 11

Slide 11 text

Tunnel-vision architecture

Slide 12

Slide 12 text

Blast-from-the-past architecture

Slide 13

Slide 13 text

One-size-fits-all architecture

Slide 14

Slide 14 text

Accidental architecture

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

We need to ask why to focus our work Without asking why the value of our work will be accidental

Slide 17

Slide 17 text

Let’s (re-)establish focus

Slide 18

Slide 18 text

Why do we need architecture? • We need architecture to address • an optimization problem over time • with changing constraints

Slide 19

Slide 19 text

Eh, WTF?

Slide 20

Slide 20 text

Architecture attempts to satisfy quality attributes

Slide 21

Slide 21 text

see, e.g., ISO 25010, ISO 9126 or SEI for comprehensive collections of quality attributes Maintainability Changeability Availability Performance Scalability Functionality Security … Understandability Accessibility Reliability Usability Portability Operability

Slide 22

Slide 22 text

Quality attributes can be segmented in two general classes 1. Development (incl. build & test) related attributes 2. Runtime (usage and operations) related attributes

Slide 23

Slide 23 text

Development related attributes • Describe the desired behavior of a system from a development perspective • Influence how efficiently the system can be modified • Target “cost of change” • Effectiveness can usually only be measured in hindsight • “Arcane guesswork” – subject of many (heated) debates à Optimization problem over time

Slide 24

Slide 24 text

Runtime related attributes • Describe the desired behavior of a system from a usage and operations perspective • Target “correctness” • Constrain the solution options • Support evaluation of solution options • May change over time à Changing constraints

Slide 25

Slide 25 text

Correctness of behavior Runtime (usage and operations) related attributes Cost of change Development related attributes Maintainability Changeability Availability Performance Scalability Functionality Security … Understandability Accessibility Reliability Usability Portability Operability

Slide 26

Slide 26 text

Note that cost of change is not sufficient as an optimization goal as it neglects all other relevant types of costs. Thus, the optimization goal for architectural work needs to target the cumulative costs instead. (unfortunately, usually not covered by quality attributes)

Slide 27

Slide 27 text

Why do we need architecture? • With architecture we attempt • to minimize the cumulative costs of a system over its lifetime • while ensuring the correctness of behavior at runtime • On a side note: What is architecture? • Architecture is whatever is needed to implement the required quality attributes (i.e., achieve the why)

Slide 28

Slide 28 text

What the essential activities are

Slide 29

Slide 29 text

1ST LAW OF ARCHITECTURAL WORK EVERY DECISION HAS ITS PRICE NO DECISION IS FOR FREE (NO DECISION ONLY HAS UPSIDES. EVERY DECISION ALSO HAS DOWNSIDES)

Slide 30

Slide 30 text

2ND LAW OF ARCHITECTURAL WORK A DECISION CAN ONLY BE EVALUATED WITH RESPECT TO ITS CONTEXT (DECISIONS ARE NOT INVARIABLY “GOOD” OR “BAD”, BUT ONLY IN A GIVEN CONTEXT)

Slide 31

Slide 31 text

The 4E model of architectural work

Slide 32

Slide 32 text

The 4E model of architectural work Explore

Slide 33

Slide 33 text

Explore Find solution options

Slide 34

Slide 34 text

Explore • About designing solution options • Designing structures and behavior • Combining frameworks, tools, technologies, … • Important activity • Always done, either explicitly or implicitly • Architectural work often reduced to Explore activities • Unclear if and how solution delivers to the Why

Slide 35

Slide 35 text

The 4E model of architectural work Explore Execute

Slide 36

Slide 36 text

Execute Help stakeholders to make the best possible decisions

Slide 37

Slide 37 text

Execute • About making decisions • Often not made by architect, but by other stakeholders • Communication, collaboration, convincing, … • Very important activity • Need to collaborate with all stakeholder groups • Learn their needs, points of view, language, … • Do not forget dev’s and ops as important stakeholder groups

Slide 38

Slide 38 text

The 4E model of architectural work Explore Evaluate Execute

Slide 39

Slide 39 text

Evaluate Identify the trade-offs

Slide 40

Slide 40 text

Evaluate • About trade-offs • Comparing solution options • How well NFRs are satisfied • Essential activity • Delivers to Why and 1st law of architectural work • Needed for Execute • Keep different perspectives in mind

Slide 41

Slide 41 text

The 4E model of architectural work Examine Explore Evaluate Execute

Slide 42

Slide 42 text

Examine Understand the problem

Slide 43

Slide 43 text

Examine • About understanding the problem and context • Examine problem space holistically • Functionality, NFRs, time, costs, risks, constraints, … • The basis of all other activities • Provides focus and context • Delivers to Why and 2nd law of architectural work • Needed for Explore and Evaluate

Slide 44

Slide 44 text

Examine Explore Evaluate Execute

Slide 45

Slide 45 text

Examine (1/3) • Understand the degree of uncertainty • What is the business model context? • How good does the customer understand the problem? • How often do they change their mind? • Have you done something similar before? • Do you have a specification/backlog? How specific is it? • Do you already have an IT solution for the problem? • Are success criteria defined? How do you measure them? • …

Slide 46

Slide 46 text

Examine (2/3) • Understand the business problem • Hypothesis collection and confidence check • Event storming • Actors and use cases • Dissect requirements document • Analyze existing IT solution • Interview key users • …

Slide 47

Slide 47 text

Examine (3/3) • Understand architectural context • Context view (incl. all actors, external systems and interfaces) • Quality tree with prioritized quality attributes • Collect key figures • Gather known constraints (financial, organizational, legal, …) • Assess external system interfaces • … • One or more workshops with required stakeholders

Slide 48

Slide 48 text

Explore (1/3) • The creative part of the work • Lots of material available • Yet, little advice regarding the actual task • Usually just lots of basics and (unfortunately) opinions • Designing good options is hard • Requires broad knowledge and experience • Few recommendations here that worked well for me …

Slide 49

Slide 49 text

Explore (2/3) • Explore variability axes to identify options, e.g. • Cloud vs. on-premise • Make vs. buy (OSS vs. managed service) • Architectural styles, communication styles, integration styles • … • About creating a high-level design • Understand required functionality and the business domain • The magic lies in the behavior, not the static structure! • Prefer architectural styles over blueprints

Slide 50

Slide 50 text

Explore (3/3) • About creating a set of options (max. 3 options) • Use constraints and key figures to reduce options • Take your environment into account • Document rationale (why you selected an option) • Use spikes and prototypes as exploration tools • Have evolvability in mind • But balance flexibility and understandability

Slide 51

Slide 51 text

Evaluate (1/2) • Understand scenario based analysis • E.g., ATAM (and how to strip it down) • Consider evaluation matrix for summary overview • Use SWOT as an augmenting risk evaluation tool • Helps to balance short-term and long-term consequences • Take the financial consequences of choices into account • Consider all dimensions: development, testing, deployment, operations, maintenance, licenses, infrastructure, usage, administration, revenue (e.g., windows of opportunity), … • Do not forget the long-term financial consequences!

Slide 52

Slide 52 text

Evaluate (2/2) • Take additional constraints into account • E.g., market situation, required deadlines, available skills • Evaluate with focus on all stakeholders • Especially do not forget consequences for operations • Have a “cheat sheet” for popular options • General usage scenarios, costs, risks and trade-offs • Use spikes and prototypes to leverage risk • Automated evaluation as an outlook * * https://www.thoughtworks.com/insights/blog/fitness-function-driven-development

Slide 53

Slide 53 text

Execute (1/2) • Know how to create a recommendation • Be familiar with decision templates and how to tweak them • Learn to present and discuss a recommendation • Try to understand biases and concerns upfront • Adjust language and arguments to your stakeholder group • Communicate all perspectives – value, risks and trade-offs • “Give 'em all the info and then let 'em decide”

Slide 54

Slide 54 text

Execute (2/2) • Accept that it (usually) is neither your risk nor your money • Thus accept the decisions of the risk takers and sponsors • If people decide against your recommendations • Stay supportive and sympathetic • Be authentic • Use time as an ally • Using code as design documentation • Great for developers, shitty for everyone else …

Slide 55

Slide 55 text

When to do what and how much

Slide 56

Slide 56 text

Understanding uncertainty

Slide 57

Slide 57 text

Uncertainty breaks the linear relation between effort and value

Slide 58

Slide 58 text

Eh, WTF?

Slide 59

Slide 59 text

Internally controlled Externally controlled Effort spent Units produced / Output Certainty-driven value prediction model (a.k.a. industrial value prediction model) Value created Units sold / Outcome Linear relation due to certainty We are looking for this Due to the linear relation it is sufficient to plan effort in order to predict value

Slide 60

Slide 60 text

Internally controlled Externally controlled Effort spent Units produced / Output The effect of uncertainty Value created Units sold / Outcome We are still looking for this Influencing factors outside our control We cannot predict it reliably upfront We can only observe it after the fact No longer suitable to predict value Breaks linear relation Uncertainty ?

Slide 61

Slide 61 text

Internally controlled Externally controlled Effort spent Units produced / Output The effect of uncertainty Under uncertainty we cannot predict upfront which kind of performance we are going to produce Support performance Idle performance No value Value-adding performance Creates value Value-reducing performance Destroys value

Slide 62

Slide 62 text

Uncertainty means that you cannot predict the value that will result from your effort

Slide 63

Slide 63 text

Acting under uncertainty 1. Create a hypothesis regarding the effect of an effort 2. Do smallest action suitable to measure an effect 3. Measure effect and evaluate hypothesis a. Further develop hypothesis if expectations met b. Drop hypothesis otherwise (optionally pivot) 4. Repeat

Slide 64

Slide 64 text

Under uncertainty you do not maximize value by optimizing efficiency of efforts (a.k.a. cost efficiency), but by detecting and cutting idle and value-reducing performances as soon as possible

Slide 65

Slide 65 text

Uncertainty Certainty • Extensive effort planning • Maximize efficiency • Detailed controlling • Hypotheses validation • Small steps • Quick feedback cycles Value maximization approaches

Slide 66

Slide 66 text

Uncertainty drivers in IT • Complexity of context and tasks • Post-industrial (& startup) markets • Digital transformation (a.k.a. digitization, digitalization) • Disruptive technologies • …

Slide 67

Slide 67 text

Types of uncertainty • Due to homework not done • Accidental, complicated, avoidable • Lack of diligence • Due to missing internal feedback • Semi-accidental, complex, harder to avoid • Rooted in company culture deficiencies • Due to missing external feedback • Essential, complex, not avoidable • Cannot be solved internally

Slide 68

Slide 68 text

Uncertainty and “Agile” • Due to homework not done • Accidental, complicated, avoidable • Lack of diligence • Due to missing internal feedback • Semi-accidental, complex, harder to avoid • Rooted in company culture deficiencies • Due to missing external feedback • Essential, complex, not avoidable • Cannot be solved internally This is what Agile originally tried to address This is what Enterprise Agile * usually addresses This is what Enterprise Agile * often causes * Enterprise Agile: Typical “Agile” implementation in most companies

Slide 69

Slide 69 text

Agile as implemented in most companies does not address essential uncertainty

Slide 70

Slide 70 text

Uncertainty Certainty Invent potential new business offerings Grow a successfully launched new business offering Explore a potential new business offering Extend/improve an established business offering Create a new digital interaction point for an established business offering Implement new legal regulation Replace system that technologically reached EOL Typical tasks with varying uncertainty

Slide 71

Slide 71 text

Uncertainty Certainty Task examples with varying uncertainty “Create a better world for our children” (vision) Evolution of new Living 360 offering (insurance) Fruits4U (startup) Release of new Warp wireless plans (telecommunications) Subcontractor self-service app OTID (logistics) Implement the new customer documentation law (banking) Replacement of AS/400 based ERP AMS/400 (retailer)

Slide 72

Slide 72 text

Uncertainty Certainty Software development approaches Focus on cost (Waterfall, V-model, SAFe, …) Enterprise “Agile” (SCRUM, LeSS, …) Focus on flow (DevOps, Lean, …) Focus on feedback (Developer anarchy, …) Focus on innovation (No software development)

Slide 73

Slide 73 text

Uncertainty Certainty Software development approaches Cost “Agile” Flow Feedback Innovation BDUF Big Design UpFront All 4 activities completely upfront Rare reassessments Decent DUF & occasional updates All 4 activities largely upfront, missing details added along the way Rare reassessments Just enough DUF & continuous evolution Quick pass through all 4 activities upfront Then discuss, complement and re-evaluate continuously along the way „Whatever works“ (Minimal agreement) Just enough agreement to get things done fast (90%+ of all written code will be deleted anyway) Note: Approach not suitable for systems in maintenance “Too early for IT” ---

Slide 74

Slide 74 text

Uncertainty Certainty Software development approaches Cost “Agile” Flow Feedback Innovation “Create a better world for our children” (vision) Evolution of new Living 360 offering (insurance) Fruits4U (startup) Release of new Warp wireless plans (telecommunications) Subcontractor self-service app OTID (logistics) Implement the new customer documentation law (banking) Replacement of AS/400 based ERP AMS/400 (retailer)

Slide 75

Slide 75 text

Additional influencing factors • Time and budget constraints • Availability of people (who and when) • Available skills and knowledge • Risk of resulting system (e.g., can harm human lives) • …

Slide 76

Slide 76 text

Wrap-up

Slide 77

Slide 77 text

Wrap-up • Why architectural work • To minimize cumulative costs without violating correctness • How to do architectural work • 4E model: Examine, Explore, Evaluate, Execute • When to do architectural work and how much • Align your activities with uncertainty • There is no one-size-fits-all • Do what is needed, not what is fashionable

Slide 78

Slide 78 text

Uwe Friedrichsen CTO @ codecentric https://twitter.com/ufried https://www.speakerdeck.com/ufried https://medium.com/@ufried