Beyond “it depends” How much architectural work do we need? Uwe Friedrichsen – codecentric – 2006-2022

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

When to do what and how much

There is no “one-size-fits-all”

We came from “waterfall all-the-things”

Waterfall all-the-things • We didn’t like it • It didn’t work well in quite some contexts • We complained • Too limited, too uniform for our heterogeneous demands • “We need something that adapts better to our needs”

We went “Agile”

Well, quite often it feels more like this ...

Still, fine … but …

… now we are “Agile all-the-things”

Agile all-the-things • We love it • It doesn’t work well in quite some contexts • We do not complain • Instead, we try to squeeze everything into an agile corset • “We’re agile. Period!”

We just created the next “one-size-fits-all”

No content

Understanding uncertainty

Uncertainty breaks the linear relation between effort and value

Eh, WTF?

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

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 ?

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

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

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

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

Sources of uncertainty in IT • Post-industrial markets • Complexity of context and tasks • Digital transformation (a.k.a. digitization, digitalization) • Disruptive technologies and more

Going post-agile or killing the one-size-fits-all dogma

The suitability of an approach depends on its context

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

And acting under uncertainty is “Agile”, isn’t it?

Well, not really …

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 required external feedback • Essential, complex, not avoidable • Cannot be solved internally

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

Agile as implemented in most companies does not address essential uncertainty

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)

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

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)

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)

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) Is this all we need to take into account?

We need to take the lifecycle of a system into account

Initial empty state S0 C1 S1 First change Resulting state C2 S2 Next change Next state SI Initial release (V1.0) SN CN Final state (EOL) Last change System lifecycle (simplified)

Most architectural work considers this part only … … but 80%+ of the costs and efforts accrue after the initial system release S0 C1 S1 C2 S2 SI SN CN

How can the architecture deteriorate over the lifecycle of a system?

Architecture deterioration drivers • Changes in business domain • Involuntary inadmissible implementation • Focus on implementation efforts only • Accumulated “technical debt” (quick-fixes, workarounds, ...) and more

We need to reassess our architecture over the lifecycle of a system regularly

Uncertainty Certainty Approach summary Project start Project ongoing Maintenance Cost “Agile” Flow Feedback Innovation BDUF Big Design UpFront BDUF Complete design Duration: ~weeks --- Reassessment Frequency: ~2y Duration: ~days Decent DUF & occasional updates DDUF Most of design Duration: ~days Missing details added if needed Frequency: > month Duration: ~hours Reassessment Frequency: ~2y Duration: ~days JDUF Quick pass (“Just enough”) Duration: < day Just enough DUF & continuous evolution „Whatever works“ (Minimal agreement) Discuss, complement and reassess continuously along the way Frequency: ~weekly Duration: < hour Just enough agreement to get things done fast (90%+ of all written code will be deleted anyway) --- Approach not useful for systems in maintenance “Too early for IT” ---

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

Wrap-up

Wrap-up • Align architectural work with uncertainty • Should fit the chosen software development approach • Take the lifecycle into account • Most architectural efforts only target initial development • Reassess regularly to avoid architecture deterioration • There is no “one-size-fits-all”

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