Lesson 167 - Architecture vs Design

Summary

In 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

00:00

🏛 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.

05:01

🛠 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.

10:03

🎨 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.

Keywords

💡Architecture

Architecture in the context of software refers to the high-level structure of the system, including the organization of components and their interactions. It is a fundamental concept in the video, as it discusses the differences between architecture and design. For instance, the script mentions 'architecture' when discussing the decision to use microservices, which is a structural choice impacting the overall system.

💡Design

Design, in software development, pertains to the detailed planning and creation of individual components or features. It is juxtaposed with architecture in the script to illustrate the spectrum of decisions. An example from the script is the use of the strategy design pattern, which is more of a design-level decision, focusing on how source code is organized within classes.

💡Spectrum

The term 'spectrum' is used to describe the range of decisions between architecture and design. It is a key concept in the video, as it highlights that decisions are not strictly binary but exist along a continuum. The script uses the spectrum to guide viewers in determining the nature of their decisions, as seen when discussing the criteria for evaluating decisions.

💡Structural Aspect

A 'structural aspect' refers to the organization of the source code into components and the relationships between them, including coupling and communication. The script emphasizes this as a criterion for differentiating architectural decisions from design decisions, such as when discussing the choice to use microservices versus a monolithic approach.

💡Strategic

Strategic decisions are those that are long-term and involve extensive planning and collaboration among many stakeholders. The script uses 'strategic' to describe decisions that take weeks to months and require input from multiple people, such as the choice to implement microservices architecture.

💡Tactical

Tactical decisions are more immediate and can be made quickly, often by a smaller group or even an individual. The script contrasts this with strategic decisions, using the example of choosing a design pattern, which can be a tactical decision made within an hour or a day.

💡Effort

The 'level of effort' refers to the amount of work required to implement a decision. The script uses this as a criterion to distinguish between architectural and design decisions, noting that decisions requiring more effort, like setting up a microservices ecosystem, tend to be more architectural.

💡Trade-offs

Trade-offs are the pros and cons associated with a decision, and they are a central theme in the video. The script discusses how significant trade-offs are typically associated with architectural decisions, such as the trade-offs involved with microservices, which offer benefits like fault tolerance and scalability but at the cost of complexity and potential performance issues.

💡Responsibility

Responsibility in the script refers to who should make a particular decision—whether it's the architect or the development team. The video emphasizes the importance of determining responsibility to ensure appropriate collaboration and decision-making, as illustrated when discussing the criteria for decision-making.

💡Impact

Impact denotes the effect a decision has on the overall system. The script discusses how architectural decisions tend to have a higher impact than design decisions, which is why it's important to understand the nature of the decision being made, as seen when evaluating the choice to break up the payment service into separate services.

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