Lesson 167 - Architecture vs Design
Summary
TLDRIn this episode of Software Architecture Monday, Mark Richards explores the nuanced differences between architecture and design in software development. He introduces a spectrum of decisions rather than a binary distinction and provides criteria to determine the nature of decisions, such as their structural impact, strategic vs. tactical nature, effort involved, and the significance of trade-offs. Using examples like choosing microservices and design patterns, Richards illustrates how these criteria can help identify who should make certain decisions and their overall system impact, offering a practical tool for developers and architects to navigate their responsibilities.
Takeaways
- đ Architecture and design are not binary but a spectrum of decisions, with varying degrees of impact and responsibility.
- đ The first criterion to differentiate between architecture and design is the involvement of structural aspects of the system, such as component organization and coupling.
- đ Strategic decisions typically involve more people, take longer to make, and have a broader impact, whereas tactical decisions are quicker and involve fewer people.
- đȘ High effort decisions are more likely to be architectural, while low effort decisions tend to be more design-oriented.
- âïž Trade-offs are inherent in software architecture, with significant trade-offs usually indicating an architectural decision and less significant ones leaning towards design.
- đ€ Determining the nature of a decision helps in identifying who should be responsible for making it, either the architect or the development team.
- đ Understanding the impact of a decision is crucial; architectural decisions generally have a higher impact on the system compared to design decisions.
- đ The example of choosing microservices as an architectural style demonstrates a high-impact, strategic, high-effort decision with significant trade-offs.
- đ The use of a strategy design pattern is an example of a tactical, low-effort decision with less significant trade-offs, typically a design responsibility.
- đ The decision to break up a payment service into separate services is a gray area, requiring analysis of structural change, strategic/tactical nature, effort, and trade-offs.
- đ The criteria provided can act as a tool to determine the responsibility and impact of decisions, helping to avoid conflicts and ensure appropriate decision-making roles.
Q & A
What is the main topic of the lesson in the provided video script?
-The main topic of the lesson is the difference between architecture and design in software development.
How does Mark Richards define the difference between architecture and design?
-Mark Richards explains that the difference between architecture and design is not a binary decision but a spectrum of decisions that lie between architecture and design.
What is the first criterion mentioned to determine if a decision is architectural or design-related?
-The first criterion is whether the decision involves some structural aspect of the system or is merely about the source code.
How can you differentiate between strategic and tactical decisions?
-Strategic decisions tend to involve a lot more people and take weeks to months to make, while tactical decisions can be decided with one or two people within an hour or a day.
What does the level of effort criterion indicate about a decision?
-The higher the effort required, the more architectural the decision probably is.
Why is the significance of trade-offs an important criterion in differentiating architecture from design?
-Significant trade-offs usually indicate architectural decisions, while less significant trade-offs are typically associated with design decisions.
Why is it important to understand whether a decision is architectural or design-related?
-Understanding this helps determine who has the responsibility for making the decision and the overall impact of the decision on the system.
What is an example of a decision that is clearly architectural?
-Choosing to use microservices for a new system is an example of a decision that is clearly architectural.
Can you provide an example of a decision that is clearly design-related?
-Choosing to use the strategy design pattern for a part of the code is an example of a decision that is clearly design-related.
What is an example of a decision that falls in the middle of the spectrum between architecture and design?
-Choosing to break up the payment service into separate services for each payment type is an example of a decision that falls in the middle of the spectrum.
How can the criteria discussed help avoid conflicts between architects and developers?
-The criteria help determine who should have the ultimate responsibility for a decision, avoiding stepping on each other's toes or making decisions that one shouldn't have the responsibility to make.
What is the overall impact of architectural decisions compared to design-related ones?
-Architectural decisions tend to have a higher impact on the system compared to design-related decisions.
Outlines
đ Understanding Architecture vs. Design
In this segment, Mark Richards introduces the topic of differentiating between architecture and design in software development. He emphasizes that the distinction is not binary but exists on a spectrum, and provides criteria to determine where a decision lies on this spectrum. The criteria include the structural aspect of the system, the strategic versus tactical nature of the decision, the level of effort involved, and the significance of trade-offs. Richards explains that understanding this spectrum is crucial for determining responsibility and impact, suggesting that architects and developers should collaborate but also know who should ultimately make the decision.
đ Criteria for Architectural Decisions
This paragraph delves into the criteria for making architectural decisions. Richards uses the example of choosing to use microservices for a new system to illustrate how to apply these criteria. He discusses the structural aspect of such a decision, its strategic nature, the high level of effort involved, and the significant trade-offs associated with microservices, such as fault tolerance and scalability versus complexity and potential performance issues. The paragraph highlights how these factors position the decision firmly on the architectural side of the spectrum, indicating that it should be made by an architect with input from the development team.
đš Design Decisions and Their Impact
In contrast to architectural decisions, this section examines design decisions, using the strategy design pattern as an example. Richards explains that such decisions are more about how source code is organized and written, are tactical, require minimal effort, and have less significant trade-offs. This positions the decision on the design end of the spectrum, suggesting that a development team or individual developer should be responsible for making this type of decision, albeit with collaboration from architects and other stakeholders.
đ€ Navigating the Gray Areas of Decision Making
Richards presents a scenario where the decision to break up a payment service into separate services for different payment types is analyzed using the established criteria. He discusses how this decision involves structural changes, is more tactical than strategic, requires a moderate level of effort, and involves significant trade-offs, such as potential impacts on performance and data integrity versus benefits like agility and extensibility. This analysis places the decision in a gray area, more towards the architectural side, indicating that while it may not be solely the architect's responsibility, it is significant enough to warrant careful consideration.
Mindmap
Keywords
đĄArchitecture
đĄDesign
đĄSpectrum
đĄStructural Aspect
đĄStrategic
đĄTactical
đĄEffort
đĄTrade-offs
đĄResponsibility
đĄImpact
Highlights
The difference between architecture and design is not binary but a spectrum.
Decisions can be categorized by their structural aspect, involving the system's organization or source code.
Strategic decisions usually involve more people and take longer to make compared to tactical decisions.
High effort decisions are more likely to be architectural, while low effort suggests a design focus.
Significant trade-offs are characteristic of architectural decisions, whereas less significant ones lean towards design.
Understanding the difference helps determine responsibility for making decisions between architects and developers.
Architectural decisions have a higher impact on the system compared to design decisions.
Using microservices is an example of an architectural decision due to its structural and strategic nature.
The choice of design patterns is a design decision, being tactical and involving low effort with less significant trade-offs.
Breaking up the payment service into separate services is a decision with significant trade-offs, falling more on the architectural side.
Most decisions will fall in the gray area between architecture and design, requiring careful consideration.
A tool is presented to help determine the responsibility and impact level of decisions in software architecture.
Collaboration between architects and developers is essential, but ultimate responsibility depends on the decision's nature.
The criteria provided can help avoid conflicts and ensure that decisions are made by the appropriate party.
The importance of understanding the spectrum between architecture and design for effective software development.
A spectrum slider is introduced as a visual tool to gauge the nature of decisions in software architecture.
Lesson 167 concludes with the practical application of the criteria to distinguish between architectural and design decisions.
Transcripts
hello everyone and welcome to software
architecture Monday my name is Mark
Richards and in this lesson number 167
we'll take a look at the difference
between architecture
and Design
you can get a listing of all the lessons
I do and software architecture Monday
from my website at
developer2architect.com lessons
so is there a difference between
architecture and design and it turns out
that there is however here's something
very interesting
the difference between architecture and
design is not a binary decision but
rather a spectrum of decisions that lie
between architecture and Design
so let me show you some criteria that
you can use to determine where in this
spectrum your architecture or your
decision actually lies the first
criteria is whether your decision
involves some structural aspect of the
system
or is it merely about the source code
now when I say the structural aspect
it's the organization of the source code
into components and the coupling between
those components or in distributed
architectures
it might need to be the deployment units
uh the communication between those
deployment units as well as the
communication and types of data and
databases you have these all form the
structural aspect of the system
another criteria that you can use is
whether the decision is strategic or
Tactical
now one way to determine whether it's
strategic or Tactical
is to say for example how many people
need to be involved in this decision and
how long is it going to take to make
this decision things that are strategic
tend to involve a lot more people and
take weeks to potentially months to make
the decision whereas things that are
tactical in nature can be decided with
one person maybe two people within an
hour or a day and so it's a good way of
determining whether something is
strategic or tactical the other
kind of criteria is whether the decision
involves a lot of effort
or fairly straightforward minimal effort
the longer or larger or higher the
effort more architectural that decision
probably is and finally the last
criteria is about the trade-offs
everything in software architecture has
trade-offs every decision we make has
trade-offs pros and cons
what's the significance of those
trade-offs is it fairly significant or
less significant
significant trade-offs usually are more
on the architecture side of the spectrum
whereas less significant trade-offs
usually more in terms of design
so you might be asking Mark why does
this really matter and it's two reasons
I can give you the first is that this
helps determine who has the
responsibility
for making the decision now both here
the architect as well as the development
team should always collaborate to get
additional information to get thoughts
ideas opinions maybe there's something
we're missing so I'm not really talking
about the collaboration piece but really
after that collaboration who ultimately
has the responsibility for that decision
and then second
is knowing when you make a decision
what's the overall impact
things that are architectural in nature
tend to have a higher impact
than ones that are design related
so with all this
and nine now let's actually take a look
at some examples I'm going to show you
two extreme examples and then we'll see
one that's right in the middle of the
spectrum so for example right here what
about choosing to use microservices for
the new system and this is an
architectural style we saw a couple of
lessons ago
well let's go through our criteria to
see whether it's architecture and design
you see because you might say oh well
that's obviously architecture
but why is it obviously architecture
is choosing to use microservices more
about the structure of the system or
more about how we code
and in this case it's definitely more
about the structure of the system it's
an architectural style that we happen to
be using
it's the decision to use microservices
more strategic in nature or is this a
quick tactical decision how many people
are involved and how long will this
decision take
you might guess uh weeks to months and a
lot of people are going to want to be
involved in this decision so it tends to
be more strategic
up the level of effort
High effort or low well those of you who
have experienced microservices know this
is pretty high effort and finally what
about the trade-offs are there
significant trade-offs or less
significant trade-offs and here it turns
out there's a lot of significant
trade-offs with microservices for all
the superpowers we get with great fault
tolerance
great things about scalability
elasticity we pay the price
with high cost very complex systems and
also sometimes a lack of performance
these trade-offs tend to be fairly
significant especially when we start to
talk about physical bounded contexts and
data and it's like okay you've convinced
me they're significant
can see that is why this is on the far
end of the architecture side of the
spectrum
but let's do a different kind of
decision you choose to use the strategy
design pattern for a part of your code
well is this structural in nature or
does this have to really do with how we
write source code and clearly this is
how we organize and write our source
code in class files
is this a strategic decision that
involves a lot of people and a lot of
planning and Analysis or is it fairly
tactical something you can make a
decision in a hour or less well it turns
out this is a fairly straightforward
decision it's fairly Tactical
what's the level of effort here compared
to something like building out a
microservices ecosystem has fairly low
effort and finally there are trade-offs
but how significant are those pros and
cons of choosing to use the strategy
design pattern in it and it turns out
they're less significant and so this is
why this falls on the far end of the
design Spectrum a development team or a
developer would have the responsibility
for making this the decision whereas if
you saw with the micro Services piece an
architect really should have that
responsibility for that decision even
though
they should always collaborate with
others such as development teams
business stakeholders and and so on
well these two were quite obvious but
let's take a look at another kind of
decision and this is choosing to break
up the payment service into separate
Services one for each payment type and
so we take credit cards gift cards
Reward Points uh World pay all these
kind of different payment methods
so instead of one Consolidated single
service
we're going to choose to break it apart
is that architecture or design
most
of the decisions
that you make
will fall in this category those gray
areas so let's use our criteria to see
if we can help us decide where in the
Spectrum this decision fits
is this structural or code well we're
going to have to move a lot of source
code but we are creating additional
deployment units and possibly more
communication points between those so
this is more on the architectural side
of the spectrum
is this a strategic decision
that involves a lot of people and a lot
of time or is it more Tactical
well here it's neither of those extremes
but it's probably more of a tactical
decision and we can make this decision
fairly quickly with only a few people
what about the level of effort to break
apart this service we're going to have
to create new deployment units possibly
break up the data so that might be a
consideration but largely we're moving a
lot of source code around to different
projects or workspaces
so it's more on the low effort side of
the spectrum
well you can start to see we're getting
kind of close but we've got one more
criteria
about the trade-offs are they
significant or less significant
well think about it if we break up that
payment service
we may have communication between those
which may impact performance
if we can pay with multiple payment
types we might be impacting data
Integrity because now we have to have a
distributed transaction but we get much
better agility and extensibility and
evolutionary architecture to add
additional payment types so we're much
better agility
I would say those trade-offs are fairly
important and fairly significant we
could potentially derail a part of the
system based on this decision
and you can kind of see balancing these
it falls right about here in B which is
more on the architectural side of things
and this is where a lot of your or I
should say most of your decisions will
lie so you can see by using these
criteria we can kind of use this slider
bar to really determine should I
as a developer
be making this decision
or is this something an architect should
probably make
and conversely me as an architect should
I be making certain decisions or defer
those to a development team and this
kind of tool helps avoid stepping on
each other's Toes or making a decision
that we probably shouldn't have the
responsibility to make
so this has been lesson 167 uh the
differences between architecture and
design and kind of a little tool that
you can use to go through this criteria
to really determine whose responsibility
is this decision even though we do
collaborate who should have the ultimate
responsibility and how important
is this decision in terms of the overall
impact of our system
so thank you so much for listening and
stay tuned in two weeks for the next
lesson in software architecture Monday
Voir Plus de Vidéos Connexes
5.0 / 5 (0 votes)