Simon Brown — The lost art of software design

Summary

Simon Brown advocates for a balanced approach to software design in his talk, criticizing the extremes of 'big design up front' and no design at all. He emphasizes the importance of upfront design to set a direction while acknowledging the need for evolutionary architecture to adapt to changes. Brown introduces the C4 model for visualizing software architecture at different levels of abstraction, promoting better communication and decision-making within teams. His presentation encourages technical leadership and the use of various techniques to address risks and ensure the design's effectiveness.

Takeaways

• 📚 The speaker emphasizes the importance of not completely abandoning upfront design in software development, as it can be a valuable tool when done correctly.
• 🔄 The Agile Manifesto does not discourage upfront design; it encourages doing what adds value, and sometimes that includes some degree of design before development begins.
• 💡 The talk highlights the need for a balanced approach to design, advocating for 'evolutionary architecture' that allows for both planned and unplanned evolution over time.
• 🚫 The speaker criticizes the extreme approaches of either doing 'big design up front' or no design at all, suggesting that both extremes can be detrimental to effective software development.
• 🛠 The speaker introduces the C4 model for visualizing software architecture, which provides a hierarchical set of diagrams at different levels of abstraction to communicate design decisions effectively.
• 🤔 The importance of being able to answer two key questions in design is stressed: whether the diagrams reflect what we think we're going to build, and whether it's going to work.
• 📉 The script discusses the S-curve of learning, indicating that many people get stuck at the early stages of learning about upfront design and fail to progress to a more sophisticated understanding.
• 🤝 The speaker encourages the use of diagrams as a communication tool, stating that better diagrams lead to better design discussions and improved team alignment.
• 📈 The talk underlines the significance of making architectural decisions related to technology and modularity upfront, as these are the decisions that are hard to change later.
• 🧩 The speaker suggests using various techniques and practices, such as risk storming and architecture evaluations, to ensure that the design is robust and addresses key risks and requirements.
• 🔍 The importance of having a common set of abstractions and a ubiquitous language for discussing architecture is highlighted, as it aids in scaling teams and maintaining a shared understanding of the system.

Q & A

What is the main argument Simon Brown makes about software design in his talk?

Simon Brown argues that while big upfront design has been largely abandoned in favor of agile practices, it's a mistake to throw out all upfront design work. Instead, he advocates for a balanced approach that incorporates some upfront design to set a direction, while also embracing evolutionary architecture to adapt to changes.

What does Brown mean by 'The Agile Manifesto does not say, don't do any of that stuff'?

Brown is referring to the common misconception that agile development excludes any form of upfront design. He clarifies that the Agile Manifesto does not explicitly forbid upfront design activities; rather, it encourages flexibility and adaptation, which does not preclude doing design work that adds value.

What is the quote from Dave Thomas that Brown frequently uses in his talks?

The quote from Dave Thomas that Brown frequently uses is 'Big design up front is dumb. Doing no design up front is even dumber.' This quote encapsulates Brown's stance on the importance of a balanced approach to design in software development.

Why does Brown emphasize the importance of technical leadership in software design?

Brown emphasizes the importance of technical leadership because it provides direction and ensures that all team members, regardless of team size or distribution, are aligned in their approach to design and development. It helps in making significant design decisions and maintaining a good architectural structure.

What is the C4 model that Simon Brown created and what does it represent?

The C4 model is a tool created by Simon Brown for visualizing software architecture. It consists of a hierarchical set of diagrams at different levels of abstraction, including system context, container, component, and code. It is designed to help teams communicate their design effectively and is notation-independent, allowing the use of various diagramming styles.

What does Brown suggest is the minimum level of upfront design needed before starting development?

Brown suggests that the minimum level of upfront design should include understanding the key requirements, important quality attributes, and constraints that drive the architecture. Specifically, one should be able to confidently draw a system context diagram and a container diagram that illustrate the design direction.

Why does Brown criticize the lack of technical decisions on architecture diagrams?

Brown criticizes the lack of technical decisions on diagrams because it leads to ambiguity and a lack of clarity about the system's design. Without specifying technologies and significant design decisions, it's difficult for teams to understand, evaluate, and communicate the architecture effectively.

What is the 'S-curve of learning' that Brown refers to and how does it relate to upfront design?

The 'S-curve of learning' is a concept that describes the rate of skill acquisition over time. Brown uses it to illustrate the initial slow progress in learning upfront design, followed by a phase of accelerated learning, and eventually a plateau. He encourages designers to push through the initial slow phase to gain a deeper understanding of design principles before they plateau.

What is Brown's view on the use of UML in modern software design?

Brown notes that UML is not widely used in modern software design due to various reasons, such as it being seen as too detailed, old-fashioned, or a tool for imposing solutions on developers. However, he suggests that the issue is not with UML itself but with how it is applied and that a common set of abstractions could be more useful than the standard notation.

What are some of the techniques Brown suggests for determining how much upfront design is sufficient?

Brown suggests techniques such as risk storming, architecture spike, threat modeling, and the use of architecture decision records to determine when enough upfront design has been done. The key is to stop when the team understands the significant design decisions and is comfortable with the risks of proceeding.

Outlines

00:00

🔄 The Shifting Perception of Software Design

Simon Brown discusses the evolution of software design over the past two decades, noting a pendulum swing from extensive upfront design to none at all. He emphasizes that while big upfront design can be wasteful, the complete abandonment of design principles has left a void. Brown highlights the Agile Manifesto's non-prescriptive approach to design, advocating for value-adding design work. He introduces the concept of evolutionary architecture and design, stressing the importance of making informed, adaptable design decisions that can guide a project through both planned and unplanned evolutions.

05:01

🤔 The Misinterpretation of Agile Design Principles

This paragraph delves into common misconceptions about Agile design, particularly the belief that Agile等同于no upfront design. Brown refutes this by referencing Agile literature and the Agile Manifesto, which do not preclude upfront design but rather encourage design that adds value. He uses a quote from Dave Thomas to illustrate the balanced approach needed, stating that while big design upfront is not ideal, doing no design at all is even worse. Brown also addresses the challenges of creating an architecture that is easy to evolve and the importance of making significant, yet adaptable, decisions.

10:02

📈 The Importance of Evolutionary Design and Technical Leadership

Simon Brown explains the concept of evolutionary design as starting with a simple foundation and iteratively adding features. He stresses the importance of establishing a good enough 'version one' to build upon, avoiding future rework. Brown also discusses the role of technical leadership in guiding design decisions across various team sizes and organizational structures, emphasizing the need for a shared understanding of design direction and principles.

15:03

📚 The Knowledge Gap in Software Design Practices

The speaker addresses the concerning gap in knowledge regarding fundamental software design practices. He points out that many teams lack a shared understanding of design techniques and heuristics, which hampers their ability to articulate and teach design processes. Brown laments the loss of traditional design methods like decomposition and the CRC card technique, which are essential for transforming business ideas into structured software solutions.

20:04

🛠️ The Role of Upfront Design in Agile Projects

Simon Brown discusses the role of upfront design in Agile projects, advocating for a balanced approach that avoids extremes. He argues that upfront design should focus on significant decisions that are costly to change later, such as technology choices and modularity. Brown emphasizes the importance of creating diagrams that can be understood and critiqued by others, facilitating better design discussions and enabling technical leadership.

25:05

🗺️ The Utility of Diagrams in Communicating Design

The speaker critiques the common practice of creating ambiguous diagrams that fail to communicate design effectively. He argues for the use of diagrams as a visual checklist for design decisions, advocating for clarity and precision in diagramming to foster better understanding and discussion. Brown also addresses the misconception that diagrams are not needed if the team has had a conversation about the design, asserting that diagrams are essential for capturing and conveying design intent.

30:05

📝 The Need for a Ubiquitous Language in Design Communication

Simon Brown discusses the need for a common set of abstractions and a ubiquitous language to communicate design effectively across teams. He introduces the C4 model, a hierarchical set of architecture diagrams at different levels of abstraction, designed to tell different stories to different audiences. The C4 model is notation-independent, allowing the use of various diagramming styles to suit the audience's technical level.

35:06

🔍 Deepening Design Understanding Through C4 Diagrams

The speaker explains how the C4 model helps teams deepen their understanding of the system they are designing. By creating system context and container diagrams, teams can answer key questions about the system's scope, user roles, integration points, and technology building blocks. Brown emphasizes that these diagrams should spark meaningful questions and discussions, leading to better design decisions.

40:08

🚦 Techniques for Assessing Design Adequacy

Simon Brown suggests techniques for assessing whether a design is adequate, including risk storming, threat modeling, and the use of architecture decision records. He advises using concrete experiments like prototypes and proof of concepts to validate architectural hypotheses. Brown also discusses the iterative nature of upfront design, recommending that teams stop when they understand the key drivers of their architecture and are comfortable with the risks of proceeding.

🛑 Knowing When to Stop with Upfront Design

The speaker addresses the question of how much upfront design is enough by suggesting that teams should stop when they have a good understanding of their key requirements, quality attributes, and constraints. Brown emphasizes the importance of being able to confidently draw system context and container diagrams and being comfortable with the design's ability to meet its objectives. He encourages teams to adopt an agile mindset, using various techniques as needed to reach this point of confidence.

📚 Seeking Resources for Improving Design Skills

In the final paragraph, Simon Brown is asked about resources for improving design skills. He acknowledges the lack of a single comprehensive resource and suggests that a portfolio of books, including classic design texts, may be necessary. Brown also expresses concern about teams becoming too focused on specific methodologies like DDD and hexagonal architecture, advocating for a broader understanding of design principles to deliver business value effectively.

Keywords

💡Agile Manifesto

The Agile Manifesto is a guiding set of principles for software development that values individuals and interactions, working software, customer collaboration, and responding to change over strict processes and plans. In the video, it is discussed in the context of how it does not discourage upfront design but rather emphasizes value addition through design if it supports the project's goals.

💡Evolutionary Architecture

Evolutionary Architecture refers to a design approach where the architecture of a system is allowed to evolve over time through incremental changes. The speaker mentions this concept, advocating for a balance between upfront design and the flexibility to adapt and evolve the architecture as needed.

💡Technical Design

Technical Design in the context of the video pertains to the process of making decisions about the modularity, technology choices, and other structural aspects of a software system. The speaker emphasizes the importance of technical design in creating a solid foundation for software development, beyond just writing better code.

💡Upfront Design

Upfront Design is the practice of conducting significant design work before the development phase begins. The video discusses the misconception that Agile methodologies reject upfront design, clarifying that Agile actually encourages design when it adds value, and that a balanced approach is preferable to extreme positions.

💡Modularity

Modularity is a design principle that involves dividing a system into separate, interchangeable modules or components. The script discusses the importance of modularity in creating an architecture that is easy to evolve and maintain, which is a key aspect of the speaker's argument for thoughtful upfront design.

💡Microservices

Microservices is an architectural style that structures an application as a collection of small, loosely coupled services. The speaker warns against the blind adoption of microservices, suggesting that while they offer benefits for agility and evolution, they are not suitable for every project and can introduce complexity.

💡Risk Storming

Risk Storming is a collaborative technique for identifying and addressing potential risks in a project. The video mentions this as a method to deal with risk in agile projects, emphasizing the importance of proactively identifying and mitigating risks, especially those related to architectural decisions.

💡Architectural Decisions

Architectural Decisions are significant choices made during the design of a software system that can have lasting impacts on its structure and function. The speaker discusses the importance of making informed and deliberate architectural decisions, particularly those related to technology and modularity.

💡C4 Model

The C4 Model is a method for visualizing software architecture through a hierarchy of diagrams at different levels of abstraction. The speaker introduces the C4 Model as a tool for creating clear, communicative diagrams that can help teams understand and evaluate their architectural decisions.

💡System Context Diagram

A System Context Diagram is a type of architecture diagram that shows the system of interest in the middle, surrounded by its users and the environment. The video script uses this term to illustrate the level of detail and understanding required to create a meaningful diagram that reflects the system's scope and integration points.

Highlights

The talk emphasizes the balance between big upfront design and no design, advocating for a middle ground that incorporates evolutionary architecture and design.

Agile manifesto does not discourage upfront design; it encourages doing work that adds value, which can include design activities.

Dave Thomas' quote 'big design up front is dumb, doing no design up front is even dumber' encapsulates the need for a balanced approach to design.

The speaker introduces the concept of evolutionary architecture, which involves making significant decisions that are hard to change, and planning for both planned and unplanned evolution.

The importance of creating an architecture that is easy to evolve is discussed, highlighting the challenges in making decisions that will stand the test of time.

The speaker differentiates between technical design (modularity, technology choices) and UI/UX/product design, focusing the talk on the former.

The talk argues that good design is essential for agility, supported by the Agile Manifesto's principle of continuous attention to technical excellence and good design.

The speaker introduces the C4 model for visualizing software architecture, emphasizing its hierarchical structure and notation independence.

The concept of 'diagrams as maps' is introduced, suggesting that different levels of diagrams should cater to different audiences and purposes.

The speaker discusses the importance of including technology choices on architecture diagrams to aid in understanding and communication.

The talk addresses the common misconception that architects should not impose solutions, arguing that making significant design decisions is part of an architect's role.

The speaker advocates for a common set of abstractions in architecture diagrams, rather than relying solely on standard boxes and lines notation.

The C4 model is described as a way to provide a visual checklist for design decisions, helping teams understand the scope and functionality of the system.

The speaker introduces the idea of using architecture diagrams to spark meaningful questions and discussions about the design, rather than just as decorative elements.

The talk discusses the need for better communication in design, suggesting that rich diagrams can lead to better design discussions and decision-making.

The speaker recommends techniques like risk storming, threat modeling, and architecture evaluations to help teams understand when they have done enough upfront design.

The closing point emphasizes adopting an agile mindset and having a toolbox of techniques to apply as appropriate, rather than a one-size-fits-all approach to design.

Transcripts

[Applause]

thank you very much so good afternoon

the lost art of software design

over the past decade maybe two decades

teams have thrown away big design up

front

this is generally

uva's talk caveat of course this has

generally been a very good thing big

upfront design is very wasteful et

cetera et cetera however

those same teams have also thrown away

all of this stuff

and it turns out that all of this stuff

is actually quite useful

now the agile manifesto does not say

don't do any of that stuff

but it's not very specific about teams

should do that stuff if it adds value so

dave thomas is in the room so i saw dave

speak at a conference i think it was

amsterdam and i think dave just threw

this comment out off the cuff

and i thought i loved that comment and

it's been in every single talk since

big design front is dumb doing no design

front is even dumber and i love this

this really epitomizes exactly what i've

seen over the past 20 years with this

flip-flop between doing everything to

doing nothing

why do we do this why do we take extreme

approaches to everything what's in the

middle

and that's really what this talk is all

about

so

of course agile doesn't say

don't do design and

people are probably not doing no design

and really the emphasis that you'll see

many people

encouraging these days is really about

evolutionary architecture and

evolutionary design and of course we've

heard lots of that uh today and

yesterday with rebecca and pat and

there's a fabulous book about this whole

topic that i thoroughly recommend

but it's not that easy

creating an architecture that is easy to

evolve

by doing that

you are

creating and making a number of

significant decisions

that are hard to change themselves and

many people jump on architectures

microservices architectures serverless

architectures anyone who went to randy's

talk earlier you know 99 of people don't

need microservices i completely agree

but people jump on these things because

they think they give them

they think these architectural styles

give them the ability to move fast and

evolve quickly and they do but there are

some caveats

and of course when we think about

changes and evolution

there's both planned evolution and

there's both unplanned evolution there's

things we know that are going to happen

in the future and things we have no idea

about

and we also need to make sure these

changes are done in a guided fashion to

repeat what pat said earlier

to caveat this talk i'm going to use the

word design

i'm really focusing on technical design

so modularity choosing technologies etc

etc i'm not focusing on ui ux product

design that stuff is super important

super vital i'm just focusing on that on

the tech stuff why

because of that

sure we have tdd and code reviews and

pairing and we have lots of great

techniques to help us make better code

but this isn't just about writing better

code this is so much bigger

so the goal of my talk today

is to explain why some upfront design is

useful

and i want to provide some real world

tips that you can use tomorrow

to take back to organizations and start

to apply these things so my overall

approach here to be very upfront is some

design upfront

but admitting that we can't know

everything and we are going to have to

do some degree of evolutionary

architecture

you all know the drill

that's the length for the slides when

the downstairs room

uh so if you don't know me my name is

simon brown i'm an independent

consultant specializing in software

architecture i'm the creator of the c4

model for visualizing software

architecture that will come up later of

course

i've been talking about this topic for

pretty much 15 almost 20 years in some

cases

and

i could have done this talk 20 years ago

from my perspective nothing has really

changed here and when i was listening to

the panel so i arrived late yesterday

because all the flight debacle etc but

when i was listening to the panel

yesterday

this sign caught my eye

architect sorry agile mates architecture

and i thought

the ordering of those words was kind of

interesting because i've been calling

this conference

this

and architecture meets agile kind of

simultaneously in my head

and that really reflects the stuff i've

been doing in this in the interview of

the past decade or so i've been flying

around the world helping teams

and many of the teams

still have these big upfront design

processes and they want to become more

agile so i'm helping those teams kind of

strip down those processes and become

more lightweight and also i'm now seeing

more and more teams who are saying we've

been through our agile transformation

for the past five years and we're in a

total mess we have no docs our code's a

complete mess can you come and help us

can you come and reintroduce some degree

of structure so really for me this is

the same topic approach from multiple

different angles

so my workshops i get to fly around the

world do

it's basically it's a simple architect

jakarta it's like here are some

requirements break up to groups two

three people go do some design draw some

pictures and this is literally how the

task is phrased

so it's very open it's very vague and

this is kind of what happens in the real

world of course

90 minutes during iteration one during

the first iteration of this exercise we

get diagrams like that

and if anybody has seen my talks before

you know exactly what these things mean

nothing

so we do a bunch of stuff we do some

reviews and we drop into iteration 2 and

during iteration 2 guess what we get

some nicer pictures

so this is an initial picture for a

solution and then we kind of dive into

some detail and we get another nice

picture

yay

and it's at this point people say well

interesting you're basically teaching

people how to create nice pictures

well yes

but there's actually much more that goes

into this and that's what this talk is

about so i want to talk about a number

of different topics related to this

central theme and the first of these is

just upfront design

i get many of my customers and clients

and the teams

literally asking me this question out

loud

so you're talking about upfront design

are we allowed to do web front design

because we do extreme programming i'm

like what

they're like yeah we do extreme

programming

a customer comes to us they give us a

bunch of things that need to be done and

we go write code

to which my response is so how is that

working out for you and they're like bad

that's why you're here oh yeah so don't

do that then i get a lot of people say

we're agile so we don't do what front

design i'm like what

like nothing says you can't do what

front design i get lots of people still

telling me these are all genuine excuses

reasons that people have given me over

the past couple of decades for not doing

design it's not expecting agile where

does it say this and it turns out if you

go dig through some of the older agile

literature you'll see things like this

you know there is no big design upfront

agreed most of the design activity takes

place on the fly and incrementally

again reinforcing that kind of

evolutionary architecture approach you

go look at some other texts uh some of

the more aggressive xp are putting more

energy into avoiding upfront

architectural design

and of course the agile manifesto

doesn't say this it doesn't say don't do

that that upfront work

and the people behind our manifesto are

also not saying by the way you should

still go and do design that whole topic

is not being talked about and it's

really easy to read between the lines

and come to the wrong conclusion

just because people are no longer

talking about upfront design it doesn't

mean it's not important

and of course the people who put the

mantra the agile manifesto together have

a ton of experience

and our teams likely don't our teams are

likely younger

so all of these things kind of factor in

here now

i kind of wondered what happens if you

take these agile people

into a non-software world

and this happened so kent beck a couple

years ago now posted i'm writing a new

book

and he posted a photo upside down for

some reason maybe this is twitter

and it's it's a photo of an of the

outline for his book

and yeah i know where this is going yeah

exactly so somebody said it's

interesting that you have an outline uh

my daughter's also writing a book and i

and she kind of works with just writing

and

refactoring which is basically what tdd

is all about right

and his response was yeah i've done like

20 000 words

i need to basically step back and see

the hole so it's very easy to get stuck

down that rabbit hole to kind of do tdd

tdd tdd and not step back and see the

bigger picture

and even someone like kent beck

has to step back at some point and i'm

exactly the same if i jump into a

solution too much depth i'm lost

and i need to step back and some people

need to step back earlier than others

that's essentially what all this is

about the whole agility thing

it requires a

toolbox of various techniques and

practices

and i think we've stopped teaching a lot

of this stuff

and that kind of makes me sad

go ask your colleagues back at work how

do you design software so if you get

some requirements what do you do next

how do you design software they're like

what

i know what's your process how do you

take requirements and go through and get

some software

like uh we use a whiteboard

right

what for

the drawing pictures well obviously

drawing pictures for what are you

drawing on these on these on these

pictures i would draw boxes and lines

those are our architecture diagrams

quite unquote

great so what did the boxes represent

well it depends isn't it well no go what

you know one of the boxes well the boxes

represent components what's a component

i have no idea because everybody thinks

of components as being different things

and ultimately when you kind of fraud

people enough like why are you drawing

three components not for the like oh

we're just using experience

and we've lost the ability to explain

how we do design

the heuristics we use to take a business

idea and transform it do some analysis

in our mind and transform it into

something we write on a piece of paper

and that's

a shame because now we if we can't

articulate how we do design we can't

teach other people to do design

and it turns out

this is not new like there's a whole

bunch of stuff out there that exists and

has existed for decades

like decomposition how do you take a

thing and chop it up into smaller parts

there's a whole ton of different

decomposition techniques and like people

haven't heard of these things

every time you go to a serverless or

microservices talk you'll see people

quoting citing this paper from parnasse

about modularity

like none of this stuff is basically

like take a big thing and chop it up

into smaller things whether it's modules

in a monolith or services services in a

distributed architecture the the

overriding principles are exactly the

same

go back to the 90s you get things like

crc classes responsibilities

collaborators this is a fabulous

workshop technique for doing

collaborative design

now we don't all sit around the room and

do like

low level class level code level design

as a committee but maybe we can take the

same approach and apply it to

services

or components

so you can take the same approach and

apply it to different types different

levels of abstractions

and this is really what i

kind of focus on when we talk about

upfront design and for me upfront design

is not about creating a perfect end

state that's what we used to do 20 years

ago it's like here's a set of blueprints

now let's go and we must never deviate

for me this is about doing something

different

it's a shame that joshua's not here he's

he's upstairs but here's his picture so

there's a great way to explain this

whole concept it's evolutionary design

it's beginning with the primitive whole

and we've seen this a million times

before you go to any agile conference

like start with something simple add

features iterate

you know that whole thing's been done to

death we hopefully get that by now

the reason i'm bringing this up is

because the thing we never talk about

is version one

but how do you make version one

a good enough thing that you can add

features to it

how do you put some sufficient

foundations in place

so you're not going to have to do lots

of unnecessary rework expensive rework

if i go back to slide you can see the

journey between the iterations

so at the end of your life cycle when

you're you're delivering no more

software you can now look back at all of

the releases and you can see the deltas

between the releases

if you're here on day one of your new

product

you don't know what the future looks

like

again it's the planned versus unplanned

evolution

it turns out the manifesto does talk

about design if you go to page two the

principles page principle number nine

says this continuous attention to

technical excellence and good design

enhances agility

this is the manifesto explicitly calling

out that good design is super important

a simple way to think about this is a

good architecture enables agility

now good is subjective i grant you that

but for me a good architecture is really

something that's well structured

and has a high degree of modularity

this is why i talk so much about

creating good modular monoliths

because this helps you move fast so what

i think we're trying to do here is we're

trying to do enough up front design to

put a starting point in place

and set a general direction

but that direction might and probably

will change in the future

so this is that blended approach it's

some upfront designed to put starting

point in place set the direction and

then use your evolutionary design to

change direction when needed and i think

that starting point adds a huge amount

of value

this is essentially what i refer to as

technical leadership

it's like we have a bunch of programmers

developers etc we all need to go in the

same direction how do you do that

technical leadership

and every team needs this

if you're a one-person team you need a

small degree of technical leadership if

you're a 100 or 1000 person team with

offices around the world

you need more technical leadership

this also exists in multiple dimensions

which gets very complicated

you'll see big organizations have

hierarchies of architects

corporate architects centralized

architects enterprise architects

centralized article architecture groups

people think those are bad and

anti-patents they're not they're needed

in big organizations because your

product teams might not be looking as

forward into the future as some of the

higher levels of architects in your

hierarchy

if you have a situation where you've got

multiple services and complete code

ownership across your entire

organization where any product team can

change any line of code in any

production service

you have to ask yourself

so who's applying technical leadership

on those product teams but also who's

making sure that there still exists

some degree of technical leadership on

the shared services that everybody is

changing

so that's why this is a little bit more

complicated than it first seems

diagrams

i had to get back to diagrams of entry

who uses uml here

wow

i thought it'd be more than that because

i'm in germany

no that's that's a compliment so when i

ask this question it's normally like 10

maybe there are two countries uh that

i've visited that predominantly have

more than 10 and it's germany and the

netherlands and i don't know what it is

it just is and i think that's a good

thing so why don't people use your ml

well i'm the only person on the team who

knows it that's one the answers people

give to me quite frequently

more frequently i don't know it

i mean that's a good reason to not use

uml if you don't know don't use it i did

some

workshops for a very very well-known

company

and i asked them do you use uml here and

they replied to my face

no because you'll be seen as old

and i really i'm the oldest person in

this room

and then they said oh and old-fashioned

i'm like what

like

do those boxes look old-fashioned or

something i get a lot of people saying

well you uml is too detailed

uml is just a language you don't have to

use the whole language but this there is

something about uml that kind of sucks

you in and then you get drawn into those

discussions of black diamonds versus

white diamonds you're like i don't know

the difference go look it up aggravation

versus composition don't know the

difference go look it up and just go

down the rabbit hole

um why don't we use uml we don't want to

tell developers what to do like what

like somehow people have attached uml to

the process of telling developers what

to do probably from those wall tool

processes 20 years ago

yes

and again it's not expected in agile

there's this uml is not expected in

agile thing where did this come from

it's the same thing you go look through

all of the old agile literature

would it be better if we used a case

tool to lay out the design no just use

crc or a bar napkin

thanks ron

a bar napkin

this guy has a youtube channel and he

said uml is a very elaborate waste of

time

thanks

so what's his recommendation just use a

whiteboard

i mean that kind of works

but it doesn't because i've see this

whenever i

do my workshop people just use a

whiteboard and the diagrams are

horrendous that no one can understand

them okay so what's wrong with these

diagrams

something i do during my workshops is

called the perfection game it's like

write a list of things you like things

you don't like give a score between one

and ten one is horrendous 10 is

absolutely perfect

here's a real diagram from a workshop it

was scored a 7 out of 10.

i'm like well it doesn't

tell me much about the solution here

here's another one from the same

workshop

also scored a 7 out of 10. i love this

little user up here

kind of a

little shock user i love looking for

little

funny things in these diagrams

uh here's another one also scored a

seven out of ten it's like here's a

layered architecture with a bunch of

stuff

angularfront.net back end doesn't really

tell you much about the

business domain i guess

uh here's a funny another one

seven out of ten

x com

no idea

uh here's another one seven out of ten i

love this little

thing there it's like a little database

maybe hanging off config

no one knows what that's for but

whatever

uh here's another one which also scored

seven out of ten do you get a feeling

here

uh and this one's called six and

ironically this might have the most

detail but i think the detail put people

then like now it's too complicated

most people score these diagrams seven

out of ten

sometimes it's out of politeness

depending on the country um but other

times it's just people don't have the

prerequisite experience to

critique these diagrams they've never

seen a good architecture diagram and

they don't know how to compare theirs to

a good diagram so something i do instead

i say right

you're in groups swap your diagrams with

another group

and ask them to review your diagrams and

answer these two questions

so do you think the solutions

satisfy the drivers the requirements

quality attributes and if you were the

bank would you buy the solution

and i give people like a few minutes to

ponder this question and they're like oh

we can't answer those

like why can't you answer those two

questions they're pretty simple like

well we can't answer the questions

because we can't see and understand the

solutions

and that's the problem if you can't

understand what the diagrams are showing

you you can't interpret them so you

can't understand the solution so you

can't evaluate the solution

and many people are basing their entire

company's fortunes off designed to look

like those diagrams and that's a

horrendous state of the industry to be

in

oh yeah people tell me this the values

in the conversation so we don't need

your stinking pictures

thanks

where did this come from it's the same

thing it's like do we need uml pictures

no because you might just have better

experiences

with conversation in your co located

whole team

i've had people say that actually all

those diagrams that you've just slated

they're good they're excellent as long

as there's a discussion a conversation

about the meaning and intent of those

pictures

well that's fine but this whole the

value in the conversation thing only

works if you're all having the same

conversation and if there's lots of

ambiguity in the diagrams there's no way

you can possibly do that

this leads me on two superficial views

of upfront design so when i look over

these pictures

i often get some quite startling

questions in in response

for example i've seen a diagram that's a

bunch of boxes and arrows and somebody

said to me is that a microservices

architecture or monolithic architecture

i'm like

good question because it's not obvious

from the diagram and i've actually had

groups where half the group thinks is a

monolith and harp the group thinks it's

a microservices architecture but they

never said they never agreed on

the basics of their architectural style

which is

absolutely astounding

why is the orm directly connected to the

angular front end this is very specific

let me take you on back to one of those

pictures i showed you

we have an angular front end here we

have a net back end here there's an

entity framework object relational

mapping framework with an arrow going

from net to angular

like what like how does that work no

idea

is the web ui getting data from amazon

s3 i see a ton of people drawing like a

web box a web ui box and an amazon s3

box and a line between them all right

perfect so you're pulling a date out of

s3 sticking it on the web love it how

are you doing that

like oh well there's a javascript api

and we can use the javascript api

in our angular app to talk to s3 okay

perfect where are you putting your secur

your security credentials

on the web page yeah that's not a good

idea is it and people are just not

thinking through the implications of

their designs

and it's because people are rushing

they're not putting some time and effort

into considering

the implications of what they're drawing

we need to slow down a little bit

and make sure we invest some time and

effort into probably understanding

the solution space

rather than jumping on solutions george

fairbanks has a great book on

architectures called just enough

software architecture and he says this a

good architecture rarely happens through

architecture in different design this is

just jumping on a solution because

that's what we've always done

all hype and trend and fashion and i'm

going to squarely throw microservices

right into that bucket i've seen a ton

of teams jump on mic services

and guess what now they're regretting it

and you'll see this when you go to

conferences now people are saying

actually this is a bad idea we're going

back to monolith

you need to save some time to discover

that unknowns

somebody mentioned the s curve earlier

and i i i'm sorry i completely forgot

who what uh it was i think it was randy

actually

i'd like to use the s-curve of learning

to kind of illustrate the same point

when many people are doing upfront

design

they're getting stuck here

so you're learning a new skill it's very

slow to get started you have to learn

the terminology and the jargon and the

basics and that can take some time

but after a while something clicks you

get that accelerated learning

and then after maybe 10 000 hours you

start to plateau

i like to liken this to doing upfront

design

most people attempting upfront design

are getting stuck here

they're not learning much and they they

come up with those very superficial

approaches to front design

i want to get people here i want to get

people learning fast

but stopping before they plateau you

know the platter is big design front

tech decisions something i've noticed

over the years is that people don't put

tech decisions on architecture diagrams

and it drives me bonkers

like why have you not put tech decisions

on your diagrams

and what's interesting here is there's a

conflict the people producing diagrams

don't want to put tech choices on them

they don't want to name technologies

but when you do the swapping exercise

and you ask people to review the

diagrams the comment often comes back is

if these diagrams had tech choices on

them i would maybe able to be able to

understand them easier

so why don't people put tech choices on

diagrams

again i've had people say this to my

face we don't solutionize i'm like what

that's not even a word

our architects are not allowed to do

solutioneering

like what the whole point of being an

architect is to come up with a solution

so what on earth does that mean we don't

want to impose a solution upon your

development team you do

right constraints are useful

otherwise if you if you want the

trade-off and you want full autonomy

exactly as pat said earlier then give

all the teams full autonomy if you don't

want full autonomy then maybe this is

useful we want to leave our developers

to use implementation details same thing

i'm not saying we need to choose all the

implementation details for them

and obviously it's a java solution

because we're a java team well i don't

know that and people joining our team

are not going to know that either

so let's be a bit more specific please

so how much design should we do

imagine you're back in your office

you're drawing some pictures you're

doing an upfront design exercise i want

you to be able to answer two basic

questions question number one

do the diagrams reflect what we think

we're going to build

question number two is it going to work

again we're not trying to decide

everything like we would do 20 years ago

with big design up front

so what are we trying to decide

i love the grady boots quote here about

architecture architecture represents the

significant decisions where significance

is measured by cost of change so there

are some decisions that once you make

them they're really hard to

change like adopting a distributed

microservices architectural style like

once you have a bunch of services in

production you're kind of stuck with it

similarly you lock yourself into a

monolith with a single language maybe a

bit you're burning like a hexagonal

architecture with spring boots you're

stuck with those things now

for me the significant decisions we want

to think about

are technology and modularity related

decisions

it's not do we use tabs or white spaces

and curly braces on the same line i

don't care about that stuff right

literally don't care about it

it's those bigger ticket decisions i

want us to think about as teams and

agree upon upfront

including things like error handling how

we're going to do error handling

consistently across our code base or

logging or authentication or

authorization

martin fowler said the same thing years

and years ago he said i think there's a

broad role for starting point

architecture

like how to do layering interacting with

the database web service approaches that

sort of thing so again these are the big

ticket decisions

so this whole just user whiteboard the

values in the conversation thing does

not cut it

we need better

we need better pictures because then

that forces to make better decisions

this is not a tooling issue

this is something much more fundamental

if you go to google and you do search

with architecture diagram you get

garbage like this

and these have all the same issues that

the hand-drawn pictures do

and with these diagrams you can't answer

that first question

the diagrams are just far too ambiguous

and we need a ubiquitous language

to communicate effectively and this

sounds like a really silly thing to

still be saying in 2022 like we have a

bunch of developers and they still can't

talk in the same language about what

this system looks like from an

architectural perspective

and we could all go use uml

who wants to use uml here

no one right

so that idea is dead

so i think we need to step back and i

think what's really missing here is a

common set of things

a common set of abstractions and i think

those abstractions are potentially much

more useful

than the standard boxes and lines

notation and of course uml gives you

both but we always focus on on the

latter so this is where my c4 model

comes into play you go to c4model.com

there's a whole bunch of information on

there but essentially it's a

hierarchical set of architecture

diagrams

at named levels of abstraction

software systems containers not docker

sorry components and code ask me later

if you want to and the concept here is

diagrams as maps we want different

levels of diagrams to be able to tell

different stories of different audiences

sometimes we want the 30 000 foot view

and other times we want to zoom in so we

want to zoom in for the more technical

audiences we want to zoom out for the

less technical audiences

and the c4 model is notation independent

so you can use boxes and arrows of

pretty colors

knock yourself out or you could use uml

or archimate or other formal notations

that get created in the future

and the reason i talk about diagrams so

much is because they're a fantastic

visual checklist

for design

decisions

in order to draw a c4 model system

context diagram

so a system context diagram shows you

the system you are focused on in the

middle the people using it and how it

fits into the world around it in order

to draw that diagram you need to answer

those questions

so what is the scope of the system we're

building what functionality sits inside

the system boundaries what sits outside

in the existing environment

who's using my system what types of

things they expecting to do

and what system integration points do we

need to support once you answer those

questions even at a high level you can

draft up something like a nice looking

system context diagram

so here we can see the red box the

financial risk system box here that's

the system people are designing they've

identified rightly a couple of different

roles here so roles actors personas

there are various ways to represent your

users and they've also identified a

bunch of system integration points which

is fantastic

we do the pinch to zoom in movement like

you do in google maps to that red box

and drop down to level two level two is

a container diagram

a container diagram basically shows you

applications and data sources that sit

inside your system boundary that's it

in order to draw that diagram

different set of questions

so what are the major technology

building blocks that we are going to

create as a team is it a monolith

talking to a database or is it like a

bunch of services who knows

what are the responsibilities of each of

these boxes what do they do

and how do they communicate answer those

questions you can draft up a container

diagram so here we can see there are a

couple of react web apps

javaspring web server thing

a couple of command line apps and some

data storage and that's exactly what a

container diagram shows you then these

diagrams should now spark meaningful

questions

so the next time you go and look at an

architecture diagram if you're finding

yourself asking these questions like

what do the colors mean what are the

boxes represent the diagram is not good

enough

the questions i want developers to be

asking are

oh i can see you've got two java apps

and there's an arrow between them

but the arrows are unlabeled

why are these two java apps talking to

each other what technology are they

using what's the interface what's the

api

these are much more targeted questions

maybe scan your eyes over a diagram and

there's a database and it says mongodb

and you're like but we don't use

here we use oracle

again challenge those decisions have a

conversation

so these diagrams the richer diagrams

lead to better design discussions

because now people talk in the same

language and they can challenge the

designs because they can see the designs

this makes it easier to have better

communication which makes it easier to

scale teams

and the diagram should also provide a

decent level of feedback

one of the questions i always get my

workshop is

we're trying to build or design a

microservices architecture

with 20 services

and our diagram is really complicated

because now we're showing 20 services

and arrows between them

how do we make our diagram better

simplify your solution

this is not a diagramming thing the

diagrams should show you complexity if

you have a complicated solution you're

going to get a complicated diagram let's

just admit that

and if we're not if we're not happy with

that let's change the solution

so the c410 lygrams definitely help us

answer that first question because

there's so much more rich and sad but

they still don't answer question number

two

is it going to work

and this is where i'm going to bring

scott ambler into play he has a bunch of

stuff on agile architecture and he says

this in one of his essays base your

architectural requirements

it's kind of what pat said this morning

there's a bunch of stuff that's really

important security

resilience like

what are you interested in what are you

trying to trade off here and not trade

off

so focus on the stuff that's important

to you travel light

just enough be sufficient be lean

etcetera and prove your architect with

concrete experiments

writing code

prototypes proof of concepts traces

stripes slices excuse architectures

architecture runways there's like a

million terms the same thing

it's like i have a hypothesis let's

write some code and test out that

hypothesis

how do you choose which hypotheses

to

spike

risk

one of the questions i get is how do we

deal with risk in our agile projects my

answer is

go and read the rational unified process

book

not all of it because it's really big

but rupp is a is a risk-driven approach

to delivering software and it front

loads the risky stuff to the early

stages and that's all we want to do here

if there's something super risky let's

get out of the way

risks are also very subjective aren't

they like estimates like how long will

it take to build a thing i don't know

we're gonna get different answers so i

have a technique you can find called

risk storming

so this is a nice visual collaborative

technique for identifying risks

basically it's a bunch of people still

in front of some nice diagrams

identifying risks

you can do things like threat modeling

when you have good architecture diagrams

all of these things can of course feed

into things like your fitness functions

people say how do we how do we represent

decisions on diagrams you don't your

diagrams represent the end state of all

of decisions you've made

you should recall those decisions as

things like architecture decision

records

so all of the stuff we're trying to

weave in our version of upfront design

so how much upfront design should we do

well sometimes you know what you're

doing and sometimes you don't

i think kind of randy alluded to this as

well

if you're like doing an enterprise thing

and maybe you're building a piece of

software for a compliance reason or

regulatory reason you've got some hard

known well-known requirements

if you're doing a product or a startup

it's a completely different ballgame

i think oovy said the same

so how much design should we do

i had someone say this to me i'm good

with maybe a day for a one year effort

like wow one day of design for one

year of development effort that might

work for your team is not going to work

for my team

so i don't like answering the question

how much upfront design should we do i

think it's a poor question to ask so the

question i want to ask is well let's

assume we're going to do some design

how do we know when to stop

and for me upfront design is iterative

and you should stop when you understand

the things that drive your architecture

your key requirements your important

quality attributes security performance

scaling et cetera and the constraints

that exist in your environment once you

understand those things you're good

if you can understand the context and

the scope of what you're designing what

you're building you're in a good spot so

if you can confidently draw a system

context diagram

you're good

if you understand the significant design

decisions you're having to make in terms

of modularity and technology

you're good so if you can draw a

container diagram to illustrate your

design you're done

if you have a way to share these ideas

with other people both inside your team

and outside your team

you're done and of course the c4

diagrams help teams do that

if you're confident that your design is

going to work

so it satisfies those architectural

drivers you've done

risk storming you've done threat

modeling you've maybe written some

fitness functions you've done some

testing then you're in a good spot

and basically if you're comfortable with

the risks of proceeding

go

how do you do that there's a whole bunch

of techniques out there

old-fashioned ooad crc uml ddd there's

all the ddds these days of course event

storming impact mapping et cetera et

cetera you've got my risk forming

architecture to dry runs architecture

evaluations both formal and informal

there's a whole bunch of techniques out

there that we need in our toolbox to get

to that point but for me

that's my definition of how much upfront

design should we do and again just to

reiterate this i'm trying to put a good

starting point in place

with an admittance that we're not going

to learn everything upfront and we are

going to have to change direction and

that's where evolutionary design comes

into play so my closing point here is

adopt an agile mindset as uva said

before there's no one-size-fits-all

and you should have all these tools in

your toolbox and get them out when

appropriate

so thank you very much

[Applause]

i bet we have a ton of questions right

there's one um one we've got one

question it's not the docker question

um if you can't explain

how you design how can you know you're

doing it right

that's the question isn't it if you

can't articulate and explain how you do

design

it's kind of hard to

quantify elaborate it explain to other

people and you don't know if you're

doing a good job

so how do you know if you're doing a

good job

i don't know

are you getting fired on a regular basis

is your is your company making lots of

money are your fitness functions passing

on a regular basis there's a whole bunch

of other stuff that you need to even

describe here but of course there's no

one design fits all situations either so

you can have a single problem solved in

multiple different ways and they can all

be good from different perspectives

that's my way of getting out that

question

brilliant um do you have some examples

of your workshops available online

do i have some examples of my workshops

available online so

if you go to my website which is linked

somewhere there's architecture.je

that look so i showed you a slide with

the requirements for the financial risk

system so that pdf is available free on

my website and also the entire slide set

for my workshop is also available free

on my website so i i'm not sure if that

answers the question but yeah there's

all the workshop materials available

sure it does another one and what book

could you recommend that help people

improve their design skills

oh that's an interesting question

because

i think this is an a little bit of an

untapped area

um

this might be an unpopular opinion but

someone on twitter last week said

they're kind of getting tired of

all of the ddd and hexagonal

architecture stuff and clean

architecture stuff because teams are

kind of getting too sucked into all of

that stuff

and i kind of agree

i i'm i'm i'm super happy that people

are focused on like how do we make and

create good code structures

but as i've said you know it this is not

just about good coding there's so much

more stuff

that really kind of

is important here when we're trying to

deliver business value and move fast etc

etc so

if people were kind of

wondering would he say go and read this

tdd book and this bdd book and this ddd

book etc etc the answer is no

i think we need to look at how do you do

design from a high-level perspective and

honestly i don't think there's a single

book i can recommend that says this is

how you do design well

i think lots of the classic books

so enterprise integration patterns and

some of the kind of older design books

are still very very relevant today but i

think you'd have to get like a bunch of

books a portfolio of books in place to

answer that question

wonderful thank you so much simon brown

thank you

you