Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020
Summary
TLDRThe 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
🏛️ 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.
🔍 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.
🤼♀️ 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.
📈 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.
🚀 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.
Mindmap
Keywords
💡Software Architecture
💡Agile Manifesto
💡Iterative and Incremental Development
💡Minimum Viable Product (MVP)
💡Evolutionary Design
💡Technical Leadership
💡Architectural Decisions
💡Risk Storming
💡C4 Model
💡Diagrams as Code
💡Agility
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
Ver Más Videos Relacionados
Five things every developer should know about software architecture by Simon Brown
Cosa significa avere un Mindset Agile?
Lecture 11: Evolutionary Model
Visualising software architecture with the C4 model - Simon Brown, Agile on the Beach 2019
Project Based Internship Klinikgo Health System Analyst - Company Coaching Video 1
SE 12 : All SDLC Models Revision | Software Engineering Full Course
5.0 / 5 (0 votes)