Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020

Summary

The speaker addresses common myths about software architecture, emphasizing the importance of a balanced approach between 'big design up front' and agility. They discuss the evolution from waterfall models to agile and iterative development, highlighting the Agile Manifesto's preference for responding to change over sticking to a plan. The talk explores the concept of 'just enough' design, which involves making significant decisions that are hard to change later, such as technology choices, while remaining flexible and open to feedback. The speaker also stresses the role of software architects in coding, coaching, and collaboration, advocating for a continuous involvement throughout the project lifecycle. They debunk the necessity of UML for architecture and introduce the C4 model as a tool for creating hierarchical diagrams to communicate architecture effectively. Finally, they argue that a good architecture enables agility, allowing for rapid, incremental development and continuous improvement, and advise against adopting trends like microservices without careful consideration of the specific needs and structure of the project.

Takeaways

• 🚫 **Myth Dispelling**: The speaker emphasizes that 'big design up front' and software architecture are not the same, and that the former has been largely debunked in favor of agile and iterative approaches.
• 🔄 **Agile Manifesto**: The manifesto prioritizes responding to change over following a plan, which challenges traditional waterfall methodologies and encourages a more flexible approach to software development.
• ⚖️ **Balanced Design**: Both extremes of 'no design' and 'big design up front' are not ideal. The speaker advocates for a balanced approach, suggesting that 'just enough' upfront design is necessary.
• 🛠️ **Technical Leadership**: Every team needs some degree of technical leadership to guide architecture decisions and avoid chaos, such as big balls of mud or inconsistent code bases.
• 🤝 **Collaborative Architecture**: The old-fashioned, dictatorial approach to architecture is outdated. Instead, architects should code, coach, and collaborate with development teams throughout the project lifecycle.
• 👥 **Team Maturity**: Different levels of team maturity require different leadership styles. Inexperienced teams might need more direct guidance, while experienced teams benefit from autonomy and the removal of blockers.
• 💻 **Architects Should Code**: Good software architects are also skilled developers, which allows them to stay connected with the code base and ensure that architectural decisions are practical and followed.
• 📈 **Risk Management**: Identifying and mitigating the highest priority risks should be a part of the architecture process. Techniques like 'risk storming' can help teams collaboratively identify these risks.
• 📝 **Documentation and Experimentation**: Documentation should be light but sufficient to guide development. Concrete experiments, such as prototypes or spikes, are crucial to validate architectural decisions.
• 📐 **C4 Model**: The C4 model provides a hierarchical set of diagrams to describe software systems at different levels of abstraction, which can be used to communicate effectively without prescribing specific notation.
• 🔧 **Architecture for Agility**: A good architecture enables agility by being well-structured and modular, allowing for faster and more isolated changes, which is crucial for responding to volatile business requirements.

Q & A

What is the first myth the speaker wants to dispel about software architecture?

The first myth the speaker wants to dispel is the notion that software architecture is synonymous with 'big design up front.' Historically, there was a tendency towards this approach, but the speaker emphasizes that this is not the same as software architecture, which can be more iterative and flexible.

What does the speaker say about the concept of 'big design up front'?

The speaker points out that 'big design up front' was a predominant approach in the past, particularly in the 80s, 90s, and early 2000s. However, Winston Royce, who described the waterfall model in the 1970s, actually warned against this approach, stating that it was risky and could invite failure.

What is the Agile Manifesto's stance on responding to change versus following a plan?

The Agile Manifesto, created in 2001, values responding to change over following a plan. This principle challenges the traditional approach of 'big design up front' and encourages a more flexible and adaptive methodology in software development.

What does Dave Thomas say about the extremes of 'big design up front' and doing no design at all?

Dave Thomas is quoted as saying that 'big design up front' is done for various reasons, and that doing no design up front is even more foolish. This underscores the need for a balanced approach to software architecture that avoids both extremes.

What is the concept of 'just enough' design?

'Just enough' design refers to doing the minimum amount of upfront design necessary to establish a good starting point and set an initial direction for the project. It emphasizes the need for a foundation that can evolve and adapt as more is learned through feedback and experimentation.

What is the significance of the term 'architecture' as defined by Grady Booch?

Grady Booch defines 'architecture' as representing significant decisions, where significance is measured by the cost of change. This definition highlights that some design decisions are more important than others due to their long-term impact and the difficulty of changing them later on.

Why is it important for software development teams to have technical leadership?

Technical leadership is important because it guides the team in making significant decisions about the architecture and technology choices that will affect the system's maintainability, scalability, and overall quality. It also helps to prevent chaos and ensure that the team's efforts are directed towards a coherent vision.

What is the role of an architect in the context of coding and coaching?

The role of an architect is not just to design the system but also to engage in coding, coaching, and collaboration with the development team. This approach moves away from a dictatorship model to a more collaborative one, where architects work closely with developers to ensure that the design is practical and adhered to.

Why should architects write production code?

Architects should write production code to maintain a pulse on the code base, ensure that guidelines are followed, and to keep the design and code base moving in the right direction. It also helps architects to understand the trade-offs involved in design decisions and to assess the impact of those decisions on the system.

What is the C4 model and how does it help in describing software architecture?

The C4 model is a set of hierarchical diagrams that can be used to describe different levels of abstraction in software systems. It stands for Context, Containers, Components, and Code. The model provides a structured way to visualize and communicate the architecture at various levels, from a high-level context diagram to detailed code structure.

How does a good architecture enable agility in software development?

A good architecture enables agility by being well-structured and highly modular. This allows changes to be isolated to specific parts of the code base, reducing the complexity and risk associated with making changes. It supports the ability to move fast and adapt quickly to changing requirements, which is a key aspect of agile software development.

Outlines

00:00

🏛️ Debunking Software Architecture Myths

The speaker begins by addressing common misconceptions about software architecture, emphasizing the shift from 'big design up front' to more agile and iterative approaches. The historical context of software development is provided, referencing the waterfall model and its pitfalls as highlighted by Winston Royce. The Agile Manifesto's preference for responding to change over following a plan is discussed, along with the importance of finding a balanced approach between extremes. The concept of 'just enough' upfront design is introduced, tailored to the context and needs of the project, whether in an enterprise environment or a startup.

05:00

🔍 Prioritizing Significant Design Decisions

The paragraph focuses on the importance of identifying and prioritizing significant architectural decisions based on their cost of change. It discusses the concept of software architecture as defined by Grady Booch, where architecture represents decisions with lasting impact. The speaker differentiates between major technology choices, which are significant, and minor coding preferences, which are not. The role of concrete experiments in validating architectural decisions is also highlighted, along with the importance of risk-driven approaches to software development.

10:01

🤼‍♀️ Collaborative Software Architecture

The speaker dispels the myth of the isolated architect, advocating for a collaborative approach to software architecture. The traditional 'dictatorship' model of architecture is critiqued in favor of continuous technical leadership throughout the project lifecycle. Different leadership styles for teams of varying maturity levels are discussed, emphasizing the need for adaptation. The importance of soft skills in architecture is highlighted, along with the value of architects writing production code to maintain a pulse on the codebase.

15:01

📈 The Role of Diagrams in Architecture

This section discusses the importance of diagrams in communicating software architecture effectively. The speaker criticizes the common practice of poor diagramming and introduces the C4 model as a structured approach to creating hierarchical diagrams that serve as visual maps of the system. The C4 model is described as notation-independent, allowing for various diagramming styles. The Structurizer DSL is introduced as a tool for generating diagrams from a single source file, promoting a more thoughtful and effective approach to diagram creation.

20:02

🚀 Enabling Agility with Good Architecture

The speaker argues that agility is not just a process but also a quality attribute that can be designed into the architecture of a system. The concept of agility is explored in terms of the ability to move fast and embrace change. Good architecture is described as being well-structured and highly modular, which enables agility by isolating changes to specific parts of the codebase. The importance of making thoughtful architectural decisions is emphasized, rather than following trends or hype, to achieve a structure that supports the desired level of agility.

Keywords

💡Software Architecture

Software architecture refers to the high-level design and structure of a software system, which includes the selection of the software's components and the way these components interact with each other. In the video, the speaker discusses the myths surrounding software architecture and emphasizes the need for a balanced approach that is neither 'big design up front' nor 'no design at all'. It is central to the video's theme of finding the right amount of up-front design in software development.

💡Agile Manifesto

The Agile Manifesto is a set of principles that guide the development of software through an iterative and incremental approach, valuing flexibility and customer collaboration. The video mentions the Agile Manifesto to highlight the shift from the traditional 'waterfall' approach to more adaptive planning and design, which is crucial for responding to change effectively in software development.

💡Iterative and Incremental Development

Iterative and incremental development is a software development approach where the work is broken down into smaller parts, or increments, and developed through a series of repeated cycles or iterations. The video emphasizes this approach as a contrast to the 'big design up front' methodology, advocating for a more flexible and responsive design process that can evolve with feedback and changing requirements.

💡Minimum Viable Product (MVP)

A Minimum Viable Product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future development. The speaker uses the concept of MVP to illustrate the approach startups might take when they are uncertain about the market's needs and require validation through customer interaction and experimentation.

💡Evolutionary Design

Evolutionary design is a process where an initial, basic design is created and then iteratively improved upon based on feedback and experience. The video references a blog post by Josh Kirievsky on evolutionary design to explain the need for an initial design that is flexible enough to evolve, emphasizing the importance of starting with a 'primitive whole' and building upon it.

💡Technical Leadership

Technical leadership involves guiding the technical direction and decisions within a software project. The video stresses that every software development team requires some level of technical leadership to prevent chaos and ensure that architectural decisions are made thoughtfully and consistently. It is portrayed as a key factor in maintaining the integrity and quality of the software system.

💡Architectural Decisions

Architectural decisions are significant choices made during the design of a software system that can have long-term implications on its structure and functionality. The speaker, quoting Grady Booch, explains that these decisions are measured by the cost of change, meaning that once made, they can be difficult and expensive to alter. The video underscores the importance of making informed and justifiable architectural decisions.

💡Risk Storming

Risk storming is a collaborative technique for identifying and prioritizing risks associated with a software project. The video introduces this method as a more effective approach than having a single individual list perceived risks. It allows a team to collectively brainstorm and visualize potential issues, making the risk identification process more democratic and comprehensive.

💡C4 Model

The C4 model is a set of hierarchical diagrams used to describe different levels of abstraction in software systems. It stands for Context, Containers, Components, and Code. The video presents the C4 model as a tool for creating a visual ubiquitous language that can effectively communicate the architecture of a system. It allows for structured conversations about the system's design with various stakeholders.

💡Diagrams as Code

Diagrams as Code is a technique where diagrams are created using a textual format, such as a domain-specific language or programming language code. The video discusses this approach, mentioning the Structurizer DSL as an example, which allows for the generation of multiple diagrams from a single source file. This method promotes consistency and maintainability of diagrams, which is essential for clear communication of the software architecture.

💡Agility

Agility in software development refers to the ability to respond quickly to change and deliver value to customers in a timely manner. The video clarifies that agility is not in opposition to architecture but rather is complemented by good architectural practices. A well-structured architecture enables agility by providing a solid foundation that supports rapid, incremental changes and iterations.

Highlights

Dispelling myths around software architecture, emphasizing that big design up front and iterative design are not the same.

Historical context of software development trends, from waterfall to agile methodologies.

The Agile Manifesto's prioritization of responding to change over following a plan.

Critique of both extremes of design approaches: too much upfront and no design at all.

The concept of evolutionary design, starting with a primitive whole and iteratively improving.

Importance of making significant decisions measured by the cost of change.

Technical leadership as a key component of every development team's architecture.

Different leadership styles required for teams of varying maturity levels.

Collaboration and soft skills are crucial for effective architectural practice.

Architects should be involved throughout the entire lifecycle of a project, not just at the beginning.

The role of architects also involves coding and coaching to maintain a pulse on the code base.

The C4 model as a hierarchical set of diagrams to describe different levels of software systems.

Diagrams as code, using textual formats to create diagrams, offering flexibility and avoiding tool lock-in.

The Structurizer DSL, an open-source domain-specific language for creating C4 model diagrams.

Agility in architecture is about the ability to move fast and is a quality attribute that can be designed for.

Good architecture enables agility by being well-structured and highly modular.

Architecture should be thought out and not just following trends or hype, such as with microservices.

The importance of making significant, hard-to-change decisions carefully in architecture.

Transcripts

[Music]

really this talk is

about dispelling a bunch of myths that

i've seen over the past decade or so

when i've been traveling

the world and doing consulting and

training and that sort of thing and the

first

myth i wanted to spell is probably the

biggest one

and whenever people think about software

architecture they normally think about

big design up front and and these two

things are not

the same so of course historically there

has been a tendency towards big design

upfront

this is very predominant in the 80s and

90s and maybe the early 2000s to some

extent

this is the old waterfall thing kind of

looks like this we've seen this a

thousand times before

this diagram this image actually comes

from a paper written in the 1970s by

winston royce

and he's describing different approaches

to software development

and he actually says this underneath the

illustration

i believe in this concept but the

implementation described above is risky

and invites failure

so what he's actually saying all those

years ago is this kind of makes sense

but please don't do it

and if you read further what he actually

talks about is what we really now know

as

the agile and iterative and incremental

approaches to software development

so a bunch of stuff happens through the

80s 90s including some of the

uh the very early adore stuff and rapid

application development and dsdm and

things

and eventually we get to 2001 and the uh

creation of the agile manifesto

the actual manifesto says this on the

front page we value responding to change

over following

a plan and of course at face value this

seems to throw

everything we've ever known on its head

and what i've seen over the past

20 years or so is that many

organizations have flipped from doing

big deal upfront to literally nothing at

all

and both of these extremes are not

great and there's a great quote i'd like

to use here by dave thomas and he says

this

big design upfront is done i agree for a

whole bunch of reasons

and doing no design upfront is even

dumber

and this really epitomizes what i've

seen over the past uh couple of decades

or so

so the big question everybody's kind of

really wanting to

have answered is well how much up front

design should you do

now of course wall tool says do all of

it and agile on the face of it anyway

seems to suggest not doing any at all

and the answer is well you need to

figure out what it is you're doing and

it depends what does it depend on

sometimes you know what you're doing and

sometimes you don't so if you're working

in

a big enterprise environment and you

might be doing a system replacement

you might have a fairly good fixed idea

of what you want to be delivering

if you are creating a startup company

and putting a product out into the

market for the first time you've got to

do the mvp thing and get some feedback

and experimentation and so on and so

forth

so in that situation you might need to

take a slightly different approach

so the general way of describing how

much upfront design should you need to

do is really what we need to do just

enough

right what does that actually mean i

think

the problem with upfront design is that

it paints a picture of putting a perfect

blueprint a perfect end goal

an end state um and that's not really

what we're trying to do here i i don't

think we're trying to create that

perfect end state or complete

architecture i think we're trying to do

something else

instead there's a great blog post by

josh kirievsky

it's called evolutionary design

subtitled beginning with the primitive

whole

and this is the thing we've seen a

thousand times before as well so

you put out a first version of something

and then you add features get some

feedback and so on and so forth

the thing very few people talk about is

how do we actually get to that first

version

so in order to do the iterative and

incremental thing we need to have a good

set of foundations we need to choose in

this case

the overall shape the starting materials

potentially the extension points we

think we might want to use in the future

and so on and so forth

so we need to put some design some

thinking into that initial first version

and that's really what i'm talking about

here it's about adding

that starting point creating that

starting point

why do we want to do this imagine

starting out with a new software

development project or product

and you're sketching out some ideas on a

whiteboard when you are sketching out

those ideas either on your own or

collaboratively and we'll talk about

that later

you really want to be able to answer two

basic

questions number one do the diagrams we

are drawing do they reflect what we

think we actually want to go and build

and question number two how confident

are we that design that

solution is actually going to work and

be feasible

in order to get to the point of drawing

diagrams on whiteboards you need to make

some decisions and

there's a really nice quote by grady

booch where he talks about the

definition of architecture

or his definition of architecture and he

says this architecture represents the

significant decisions

where significance is measured by cost

of change

and the reason i like this definition of

software architecture

is that it really says some in some

design decisions

are more important than others if you

were to

go and write down all of the decisions

you've ever made on your current

product or project and try to sort

them by how important or significant

they are

what you'll find very quickly is it it's

very hard to draw a line between all of

this stuff up here is significant

and all of this stuff down here is not

significant

so it's a it's a gradient of different

types of decisions with different levels

of significance

the ones we really want to be focusing

on the ones that are hard to change

ultimately are things like choice of

language

so is this going to be a java monolith

or ruby monolith you know

once we've chosen our language that's

kind of hard to change

the overall structure of the thing we're

building so if we choose to build a

monolith

converting that to microservices

architecture is

something that involves quite a lot of

time and effort and of course the

opposite is true

so really a lot of these significant

decisions revolve around

technology choices major technology

choices the things that become ingrained

into our code bases and the way that we

use these technologies

in terms of the structure and the

modularity

one of the things to be careful of here

is many teams will say

it doesn't really matter about

technology choices because what we're

going to do is we're going to build a

java monolith and we're going to use

ports and adapters or uncle bob martin's

clean architecture

so we're going to isolate all of our

business logic and make all of our tech

choices

deferrable and decoupled from our code

base

that's fine but that has a set of

trade-offs

and the significant decision you just

made is one around structure

and that has its own set of tradeoffs

so what's not important curly braces

white's face

tabs all of that stuff don't care about

i know we have all these religious

debates but

it really doesn't matter we can just

chuck some tawning on it and fix it one

might be or the other

there's lots of material out there on

agile architecture uh something i like

is scott ambler's approach and he has a

great

essay on agile architecture that you can

basically summarize in one sentence like

this you should base your architecture

on your requirements

so in other words don't make decisions

unless you have reason for making those

decisions

travel light so do the just enough thing

you know be agile

and make sure you prove your

architecture with concrete experiments

what's a concrete experiment is nothing

more than these things

uh proof of concept uh prototype of

spiker tracer we have lots different

names for the same thing

the same thing is basically writing some

code to prove our hypothesis

and i like to include the concrete

experimentation as a part of my upfront

design process

one of the more interesting questions

here as well how do i know which

concrete experiments to run how do i

know which bits my system

i want to prototype before i start

getting into writing lots of production

code

something that the rational unified

process said all those years ago rupp

is that we should identify and mitigate

our highest

priority risks and i think this is a

great thing to do today

rupp was a risk-driven approach to

building software and

it front loaded all of the big

risky stuff to the the start of the

project life cycle

there's a bit of unpacking to do here

which we don't have time for but feel

free

feel free to ask some questions

afterwards you know what's a higher

priority risk versus low priority risk

and also how do you identify risks in

the first place

one of the typical techniques we've used

is we'll get the single project manager

or the single architect

to go write a list of all the risks that

they perceive with that solution

that's not particularly a good way to do

it because risks much like estimates are

subjective

so there's a technique i created a while

back it's called risk storming

and it's a visual collaborative kind of

game storming inspired approach to

identifying risks

collaborative collaboratively as the

groups that's something you can go look

up online

to go back to the how much upfront

design should we do question

what we're really trying to do here is

we're trying to do enough upfront design

in order to put that starting point in

place

and set an initial direction

and i do want to stress that's an

initial direction so i'm

quite happy for the set of decisions and

the solution

to change as we deliver stuff and get

feedback and have real users using our

software

but any changes we make should be done

in a

structured and justified manner

one of the other ways to think about

offline design is well when do we stop

and i think upfront design is an issue

of an incremental process

so it might be something you need to do

um one or more times

and you should stop when you can do this

type of stuff so you have a good idea of

what your context is what the scope the

system is you're building

how it fits into the world around it

what the key requirements are

what the key non-functional requirements

are and those sorts of things so

so really that's my kind of one takeaway

slide

about how much upfront design should we

do and where should we stop

so that's thing number one

thing number two is that every team

needs to think about all that stuff

what happens if teams don't think about

architecture you get a mess

chaos chaos manifests itself in a whole

bunch of different ways

big balls of mud spaghetti code systems

you know code bases are just horrible to

work with

code bases with an inconsistent

approaches to solving the same problems

so i've seen

a number of codebases over the years

with multiple logging frameworks and the

same monolith multiple database access

frameworks in the same monolith

monolithic code base and so on and so

forth i've seen systems that that are

hard to deploy hard to look after hard

to maintain logging is a problem

or they don't have appropriate quality

attributes like scaling and security

performance

so that's the category of stuff that i

think doing some upfront design

and architecture really helps to address

and all of that stuff is applicable to

every team

one of the ways i like to think about

software architecture is that it's about

technical leadership

and when you think about it that way you

kind of quickly realize that actually

every software development team

needs some degree of technical

leadership if you're a one-person team

you need a small amount of technical

leadership if you're a hundred

two hundred thousand person team then

you need a much

bigger degree of technical leadership

but nonetheless you need technical

leadership

i'm also going to say this every

software system or every product

also needs technical leadership and the

reason i say this is because i see lots

of teams these days

adopting things like the spotify model

where you've got

squads who are working on business

features and they might be

given autonomy and authority to change

multiple pieces of code and multiple

repositories

on multiple products

if that scales up what i've tended to

see happen is that because you've got

all of these teams potentially changing

the same

code bases because there's no

single ownership of those code bases

sometimes the teams start making changes

in very inconsistent ways

so do also think about technical

leadership from that perspective as well

number three the software architecture

role

is about coding coaching and

collaboration

so this is a myth i want to dispel

because again the

the old-fashioned approach to software

architecture is the dictatorship

approach

where architects work on their own they

produced a huge bid document and they

basically give that document to a team

of developers and just tell them to go

get on with it

that's not how we should be doing stuff

that's how we used to do stuff in the

past

and these architects also often used to

use these documents

as batons in a relay race

i don't like this approach i call this

approach ass it's just

architecture as a service it's just a

one-way stream of architecture decisions

with ultimately no feedback loops

and one of the things i like to tell

teams is that your technical leadership

should be continuous

so don't think about getting an

architect in for the first two or four

weeks of your project lifecycle

you need to have someone doing the

architecture role throughout the entire

life cycle

that could be one person or it could be

a whole bunch of people that's entirely

up to you and we'll talk about that in a

second

different types of teams need different

leadership styles so this is something i

realized a few years back and royal

shrove has a great book called elastic

leadership that

talks about this problem from a team

leader perspective

i think the same issue happens from a

technical leadership perspective

so if you've got a team of developers

and they're fairly

junior and they don't really know what

they're doing because they don't have

much experience

generally telling them what to do and

helping them in a much more direct way

in the kind of commanding control

way that makes that team go faster

if you have a team of rockstar ninja

10xs or whatever silly tone we use to

describe really experienced developers

don't micromanage them just remove the

blockers and

get out of their way so different levels

of maturity

you know different types of teams with

different levels of maturity need

different leadership styles

even with the immature team the

inexperienced team you still need to

give them some time and space

so that they can start to understand and

solve their own problems and therefore

become more mature so that's the other

thing to to kind of bear in mind here

and the reason i bring left this up is

because teams often ask me should we

have one person doing the architectural

or should we have many people

you know should we share the role out

amongst the entire team and it's up to

you

my advice and a good starting point is

to do pair architecting

and this is what i used to practice

myself when i uh built software for

consulting companies back in london all

those years ago

so it used to be myself and another

person typically another architect but

not always

um you know two heads to bed and one etc

etc

in order to do that you need your

collaboration skills and this really

points to having good soft skills in

general so this is

an aspect to the software architectural

that we don't talk about enough in the

industry

but really this is kind of the make or

break stuff if you

if you can't lead people well if you

can't collaborate well if you can't

influence a team well

you're going to have a really hard time

doing the architectural so i would urge

you if

especially if you're moving into your

first architecture roles to put some

time

and effort into learning some of that

soft skill stuff

let's not forget the tech stuff should

architects write code

my opinion on this is most definitely

yes and my preferred approach here is

the architect's right production code

this is definitely what i do as far as

possible

the reason i like this approach is

because then you as an architect

have a pulse on the code base you can

see what's going on

you can see that people are following

the guidelines that we've all agreed to

collaboratively

and you can make sure the code base is

going in the right direction

if you're a bit more hands-off that's

much much harder to do

most of the good software architects i

know are also good software developers

so again they have a good technical

background that they might be

specialists in building java server side

apps or dotnet apps or rubric apps or

ios apps or oracle database driven apps

so they have some deep specialism but

they also have a broader range of

design knowledge architecture knowledge

knowledge about non-functional

requirements and cross-cutting concerns

and logging and operability and all that

sort of stuff

and this is super important because if

you're designing software you need to

understand technology in order to assess

trade-offs

unfortunately there's no perfect silver

bullet solution to

any problem so you know any decision we

make is going to have us have trade-offs

and if you don't have the pre-requisite

technical skills again you can't answer

these two questions i

outlined before so the software

architecture role

it can be done by one or many people but

it's multifaceted it requires good

tech skills and good non-tech skills

four my favorites uh you don't need to

use uml

this is one of the things that for some

reason scares people off doing a

software architectural

when i do these talks in front of a live

audience i i ask people

how many people here use uml and

typically it's in the kind of one out of

ten ratio there are a few exceptions

this

varies country to country cultures

culture but generally it's about one out

of ten people so not a huge number of

people these days using uml

why i've heard every excuse you can

possibly imagine

um it's too complicated it's too

detailed the tooling sucks

you'll be seen as old-fashioned or in

the case of this guy he said it's a very

elaborate waste of time

that might be true if you overuse uml i

mean uml is just a language

it's just a notation you can overuse it

you can under use it it's entirely up to

you

what is the recommended advice these

days in terms

of diagramming and presenting

your designs in a visual manner well the

answer many people give you is

just use a whiteboard

and that's that's okay you know that's a

decent piece of advice

but unfortunately it provides absolutely

no guidance

so one of the things i i typically do

when i'm allowed to travel and we're not

in a

pandemic is i get to travel around the

world and i run

architecture carter's architecture

workshops design workshops

where we get people into groups we give

them some requirements and we say go

away for like an hour and a half and

do some design and draw some diagrams to

illustrate and showcase your solution

and the diagrams look like this

autumnally so this is boxes and snow

lines this is my favorite this is like

the airline route map

so that green blob is amsterdam skipple

or london at the heathrow it's like a

big airport

lots of routes around the world this one

here doesn't even tell you anything

about the business domain it just says

business logic in the middle well this

one has no tech choices

this one is a bunch of c-sharp things

floating around a database of these

components or modules or microservices i

have no idea

this one is like an adventure game start

at the top

go down follow the different arrows no

matter which path you choose you always

die and end up in the trap on the

left-hand side it's rather unfortunate

this one here has a couple of unlabeled

users that i call stormtroopers they're

just

faceless anonymous clones attacking this

reporting service

or you get a mess now i've got

gigabytes and gigabytes and thousands of

photos

uh kicking around on on hard disks from

my workshops over the past 10 years and

they all look like this

and people often say well what happens

if you let these groups use a tool and

not pen and paper well guess what the

same thing

happens just in a tool and you can see

this yourself if you go

to google and you do a search for

software architecture diagram you get

the same garbage but it just looks nicer

we've got nice colors and fonts and then

shading things but

we've got different size boxes for

unknown reasons we've got acronyms

unlabeled lines

it's just a mess the reason i put so

much focus on diagrams is because

if your diagrams don't make sense you

can't answer these two questions

right you can't have the right

conversations to even start answering

these two questions

so i think teams need a ubiquitous

language to communicate effectively and

i'm not talking about a ddd domain

driven design ubiquitous language i'm

talking about

a visual ubiquitous language to describe

software architecture

now we could use uml i mean ul is a

perfectly good ubiquitous language for

describing architecture but nobody wants

to use it

for a whole bunch of reasons so

something i came up with a number of

years ago it's called the c4 model

and it's a set of hierarchical diagrams

that

you can use to describe different levels

of abstraction

in your software systems yet c4 stands

for context contains components and code

and the easiest way to think about this

is it's like diagrams as

maps so if you go into google maps

and you start a very high level you know

you're flying over the landscape of 30

000 feet the lower you go the more

detail you see so it's same thing with

the software architecture diagrams we've

got different levels of diagrams that

show you

different levels of detail and those

different levels of diagrams allow you

to therefore

have different conversations and tell

different stories with different

audiences

the c4 model does not prescribe any

particular notation so it's notation

independent you can use boxes and lines

and that's what most people tend to do

you can also use uml or csml or

archimedes

i do see teams occasionally do this but

um typically these boxes and lines

and if you're going to have boxes lines

you need a diagram key that's the

the most important thing here so really

the c4 model is about having

a common set of abstractions and a

variable of varying notation

you can find more information about that

on c4model.com

one of the questions people always ask

me is what tooling do you recommend

and something i was pleased to see in

the thoughtworks

tech radar a couple of weeks ago that

the new version that came out is that

diagrams as

code got a mention it blips on the radar

in trial

as well as the techniques so this is

where you're creating diagrams using a

textual

format uh like a domain a domain

specific language or maybe

actual programming language code itself

so when we were in lockdown deep in like

april may time

because i had nothing much to do i built

a domain specific language it's called

the structurizer dsl

and it's it was specifically designed to

support the stifle model

and it lets you create c4 model diagrams

with quite a succinct

domain specific language it also

supports things like cloud architecture

diagrams because lots of people seem to

be wanting to draw those sorts of things

these days with all the amazon icon sets

and stuff like that

the most powerful feature about the

structurizer dsl and the structurizer

dsl

is accompanied with uh the

structuralizer command line interface

and both of these things

are open source and available on github

the

the most powerful thing about

structurizer dsl is you create a single

file

a single source file that contains

essentially it defines a model of your

software system from different levels of

abstraction

and then using the structurizer cli the

command line interface

you can then generate multiple diagrams

from that single source file and you can

also generate those multiple diagrams in

multiple

formats so you can use multiple

rendering tools

to essentially render those diagrams

so in this slide here i've got a single

source

file and that's been rendered using

plant uml

mermaid iliograph and my own

structurizer tooling

so that's a really nice way to get a

bunch of diagrams very quickly and try

out lots of tools without actually

getting locked into any of them

so that's my thoughts on diagramming uh

the last thing i want to very briefly

talk about

is that a good architecture enables

and gives you agility so one of the

things we've

kind of heard over the past couple of

decades is that you've got this agile

thing you've got this architecture thing

and

they're somehow different and they're

competing and that's actually not the

case

from my perspective they're actually

complementary

what is agile about you have a number of

different ways to think about agile for

some people it's about moving fast

and embracing change and getting

feedback and delivering value quickly

and and ready for me that's the process

or mechanical side

of agile software development and in

essence really it's just

incremental and iterative development

done really well and really rapidly

for other people agile is more about a

mindset of continuous improvement so

whenever just doing stuff all the time

without looking at what we've done how

we can improve it

and i think this is really what we we

want to be

kind of more aligning ourselves with

from that perspective then one of the

things i like to

say to teams says well think about

agility which is the ability to move

fast

as a quality attribute and think about

where you need that agility do you need

that level of agility across your entire

code base

or maybe do you only need agility in

certain parts of your code base that

represent

particularly volatile parts of your

business process for example

once you have that in mind you can then

figure out how to support

the appropriate level of agility so do

you go monolith you go

microservices you go a hybrid approach

maybe have most of your stuff in a

monolith with some stuff

around the outside of your monolith as

microservices because that's

more volatile and that's we need more

agility maybe

a good architecture buys you agility

so a good architecture enables agility

what do i mean by a good architecture

it's kind of subjective but for me a

good architecture is really

it's really talking about something

that's well structured

and highly modular and this kind of

makes sense doesn't it if you've ever

worked on a code base that's a horrible

big ball of mud

when you change something over here all

this stuff down here breaks and you're

not really sure why

that slows you down on the other hand if

you've worked on

a software system that's very well

structured and when you make a change

that

changes isolated into a small block

small unit

of your code base that clean structure

allows you to move much faster

you don't get that characteristic for

free though

you don't get agility just by hacking

out some code and kind of hoping for the

best so you need to put some thought

into this

george fairbanks has a great book on

software architecture called just enough

software architecture

and in that book he says this a good

architecture rarely happens through

architecture in different design

what's architecture in different design

it's basically just

choosing a solution it's making

decisions because

that's what we've always done in the

past so i see that a lot especially big

companies

or people are making decisions because

of trend hype

and fashion and i see this a lot

these days especially with things like

microservices

and serverless based architectures so

you're going to see a new team like

we're going to build a new system and

we're going to use microservices we're

going to use functions as a service

and we're going to stick everything else

in kubernetes like why and now because

why not

that's not a good way to make decisions

a couple of years ago a couple years ago

more won that five years ago i threw

this tweet out

and i said if people can't belong this

properly please don't adopt

microservices because it's not going to

help you

and i still see this today i still i see

large organizations and they have these

legacy 10 15 year olds

java co bases and they're just horrible

big balls and mud the horrible

monolithic applications and they think

the only way to fix this is to go

microservices and what they do is they

they start essentially from scratch

with a view to rewrite their monolith as

a collection of microservices

they have the same mindset and what they

basically end up with

is a distributed version of what they

had before because they don't realize

they need to take a different design

approach

and then at two years down the line like

oh this is really slow and brittle and

we have to lock that deploy everything

up like i know

you're thinking about this the wrong way

so you need to put some thoughts into

what you're doing

so that tweet got a bunch of retweets

which i was quite impressed with

but then i got completely outclassed by

the architect clippy

i see you have a poorly structured

monolith would you like me to convert it

into poorly structured set of

microservices

no so again just make sure you think

about these decisions before we make

them

you know significant decisions are the

things that are hard to change

so that's me five things every developer

should know about software architecture

thanks for listening

you