What is architectural thinking in software development?

Architectural thinking involves seeing and solving problems with an architect's perspective, considering trade-offs, business drivers, and high-level solutions.

How can developers benefit from thinking like an architect?

Developers can create more effective and well-built systems, make informed decisions, and accelerate their career growth by adopting an architect's perspective.

What are the three core components of thinking like an architect according to the video?

Understanding business drivers, expanding knowledge breadth, and analyzing trade-offs are the three main components.

Why is understanding business drivers important for architectural thinking?

Understanding business drivers helps translate them into architectural characteristics like scalability or performance, ensuring the system meets business needs.

What is the '20-minute rule' suggested in the video?

The '20-minute rule' suggests spending 20 minutes daily on self-education regarding technical knowledge to broaden one's knowledge breadth.

Why should architects avoid over-evangelizing technologies?

Over-evangelizing hides trade-offs associated with a technology, which can lead to overlooking potential disadvantages or context in decision-making.

What are architecture characteristics?

Architecture characteristics are elements such as performance, scalability, and fault tolerance, which guide system architecture to support business needs.

How can technical breadth affect an architect's ability to solve problems?

A broad technical knowledge enables architects to see more solutions to problems, leading to more appropriate and effective system designs.

How to Think Like an Architect - Mark Richards

00:58:31

https://www.youtube.com/watch?v=W7Krz__jJUg

Summary

TLDRThe video discusses the importance of thinking like a software architect for developers and other software practitioners. It explains that architectural thinking isn't limited to architects only but involves a perspective that helps in creating more effective software systems. Thinking like an architect involves understanding business drivers to determine architectural characteristics (e.g., performance, scalability), expanding one's breadth of knowledge beyond current expertise, and being capable of identifying and analyzing trade-offs in software architecture. The presenter uses examples such as decision-making in event-driven architecture to illustrate common trade-offs between scalability, performance, data integrity, and so on. Practical advice such as the '20-minute rule' for self-education on technical breadth is shared, and the potential pitfalls of over-evangelizing technologies, which can obscure important trade-offs, are discussed.

Takeaways

💡 You don't need to be an architect to think like one, and this mindset helps build better systems.
🌥️ Different people view the same problem from different perspectives, highlighting the importance of an architectural viewpoint.
🔄 Everything in software architecture involves trade-offs, making decision-making complex and contextual.
📊 Understanding business drivers is essential to translate them into technical requirements and architecture characteristics.
🛠️ Developers should broaden their technical knowledge beyond what they know to enhance problem-solving.
⏳ Adopt the '20-minute rule' to invest in expanding your technical breadth daily.
⚖️ Be cautious of over-evangelizing technologies, as every tool or framework has its trade-offs.
🧗‍♂️ Adopting architectural thinking can set developers on a rewarding career path without changing roles.
📝 Characteristics worksheets can help identify and align architectural needs with business goals.
🎓 The transition from developer to architect involves shifting focus from depth to a breadth of technical knowledge.

Timeline

00:00:00 - 00:05:00
Thinking like a software architect offers developers advantages, such as building more effective systems and advancing in their careers. The speaker discusses the significance of viewing problems from an architectural perspective, using the metaphor of clouds being viewed differently by meteorologists, artists, and IT professionals.
00:05:00 - 00:10:00
Understanding architectural thinking is essential for all developers, regardless of their role. The speaker illustrates a scenario involving message and event-driven architecture, highlighting the trade-offs between sending full payloads and key-based events, emphasizing the importance of scalability, contracts, and potential complications like stamp coupling.
00:10:00 - 00:15:00
The speaker explains the complications of stamp coupling, bandwidth issues, and multiple systems of record in message-driven architecture. The choice between full payload and key-based events involves various trade-offs. Recognizing these allows developers to better analyze and make architectural decisions, understanding that software architecture is about trade-offs.
00:15:00 - 00:20:00
Thinking like an architect involves understanding business drivers' importance, seeing more solutions, and analyzing trade-offs. The speaker emphasizes the need to align business needs with architectural characteristics such as scalability, availability, and performance, translating business concerns into architecture requirements.
00:20:00 - 00:25:00
The challenge of architectural thinking involves translating business needs into architectural characteristics like fault tolerance and reliability. The speaker uses a translation engine metaphor, discussing how to identify which architectural characteristics are important and how they'd support business objectives like user satisfaction and time to market.
00:25:00 - 00:30:00
The speaker illustrates the translation of business requirements into architectural characteristics, emphasizing the role of architects as translators. Important business-driven characteristics might emerge from domain knowledge, requirements, and conversations with stakeholders.
00:30:00 - 00:35:00
Architecture involves a breadth of knowledge, requiring architects to be aware of diverse solutions. The speaker discusses technical breadth versus depth, encouraging expanding knowledge to understand various solutions, tools, and techniques. This can help in providing more appropriate solutions to problems.
00:35:00 - 00:40:00
Discussing the knowledge triangle, the speaker illustrates different phases in a career's knowledge base: junior developer, senior developer, etc., with a shift from deep knowledge of fewer things to broader knowledge of more things, essential for architects to see more solutions.
00:40:00 - 00:45:00
The speaker shares methods to expand technical breadth, such as attending conferences and using resources like InfoQ and ThoughtWorks Radar. The "20-minute rule" involves dedicating daily time to learning new things, contributing to growing technical knowledge and perspective.
00:45:00 - 00:50:00
Highlighting the importance of analyzing trade-offs, the speaker emphasizes understanding that all architectural decisions involve trade-offs. Developers often know the benefits but may overlook trade-offs. Thinking architecturally means balancing trade-offs against business needs.
00:50:00 - 00:58:31
The speaker advises avoiding the out-of-context trap and over-evangelizing technology by understanding contextual relevance and being aware of trade-offs. Architects must balance emotions about technologies with objectivity. This allows for effective architectural thinking and decision-making.

Mind Map

Video Q&A

What is architectural thinking in software development?
Architectural thinking involves seeing and solving problems with an architect's perspective, considering trade-offs, business drivers, and high-level solutions.
How can developers benefit from thinking like an architect?
Developers can create more effective and well-built systems, make informed decisions, and accelerate their career growth by adopting an architect's perspective.
What are the three core components of thinking like an architect according to the video?
Understanding business drivers, expanding knowledge breadth, and analyzing trade-offs are the three main components.
Why is understanding business drivers important for architectural thinking?
Understanding business drivers helps translate them into architectural characteristics like scalability or performance, ensuring the system meets business needs.
What is the '20-minute rule' suggested in the video?
The '20-minute rule' suggests spending 20 minutes daily on self-education regarding technical knowledge to broaden one's knowledge breadth.
Why should architects avoid over-evangelizing technologies?
Over-evangelizing hides trade-offs associated with a technology, which can lead to overlooking potential disadvantages or context in decision-making.
What are architecture characteristics?
Architecture characteristics are elements such as performance, scalability, and fault tolerance, which guide system architecture to support business needs.
How can technical breadth affect an architect's ability to solve problems?
A broad technical knowledge enables architects to see more solutions to problems, leading to more appropriate and effective system designs.

View more video summaries

Get instant access to free YouTube video summaries powered by AI!

Subtitles

Auto Scroll:

00:00:00
[Music]
00:00:12
you don't have to be a software
00:00:16
architect
00:00:18
to think like a software architect
00:00:21
and this gives you several advantages
00:00:24
first
00:00:26
a more effective and well-built system
00:00:29
even as a developer
00:00:31
and also a good head start on a really
00:00:35
fun and rewarding career path so that's
00:00:38
what I want to show you in this Keynote
00:00:41
you don't have to be an architect to
00:00:43
think like an architect but what does
00:00:44
that even mean
00:00:46
so I want to start by showing you
00:00:49
these clouds what are these
00:00:53
well they're clouds
00:00:55
but it's very fascinating that because
00:00:59
to different people
00:01:01
these clouds represent different things
00:01:04
to a meteorologist
00:01:07
they look up at the sky at those clouds
00:01:09
and they see all the cloud types and
00:01:11
they know what the weather patterns and
00:01:12
what to expect maybe as an artist you
00:01:16
look up at those same exact clouds and
00:01:19
you're picturing a beautiful dramatic
00:01:21
scene
00:01:23
of course all of us are nit
00:01:26
so when we look up at the sky and see
00:01:28
those clouds yeah we kind of think of
00:01:31
cloud-based deployments The Internet of
00:01:33
Things
00:01:35
what does this mean
00:01:38
when I showed you those clouds
00:01:41
everybody sees them
00:01:43
with a different eye
00:01:45
a different perspective
00:01:48
and that's what I want to show you about
00:01:50
architectural thinking
00:01:53
what does it mean to think like an
00:01:55
architect to to see a problem
00:01:59
with an architect's eye an architect's
00:02:02
point of view
00:02:04
well we're going to answer that question
00:02:05
and that's what my keynote is all about
00:02:08
first want to actually just show you why
00:02:12
thinking like an architect is important
00:02:14
regardless
00:02:17
of your role
00:02:20
so let's say we're in a situation where
00:02:23
we're doing some messaging or events
00:02:25
driven architecture and what you see
00:02:28
here on the far right hand side is an
00:02:31
order placement service and it's going
00:02:33
to send a message to payment and
00:02:36
inventory and so once I place an order
00:02:39
I have to pay for it and we have to
00:02:41
decrement inventory and of course we
00:02:42
have a database
00:02:43
and so you have a choice to make as a
00:02:46
developer hmm
00:02:49
well when I send that order
00:02:51
should I include all of that order
00:02:54
payload all 45
00:02:57
different attributes
00:02:59
or
00:03:00
should I only send just the key because
00:03:04
with a full day to payload of course I
00:03:06
insert the data I send all of that
00:03:09
message over
00:03:10
and payment and inventory have all the
00:03:12
data now
00:03:14
but I wonder I've got another Choice
00:03:17
what about key based you see I still if
00:03:21
I'm processing that order I still insert
00:03:23
that order into the database but now I
00:03:26
only send the key out in that message or
00:03:30
event
00:03:31
well payments and inventory both receive
00:03:33
that but now they have to query the
00:03:35
database in order to get the information
00:03:37
they need
00:03:40
so what do we do
00:03:42
well let's see obviously says the
00:03:45
developer the full event payloads the
00:03:48
right choice because we get much better
00:03:50
scalability and performance
00:03:54
I don't have to go to the database this
00:03:56
is one of the ways of creating scalable
00:03:58
systems and high performance systems
00:04:02
so this is the Clear Choice
00:04:05
yeah says the architect but um but what
00:04:08
about what sort of contract are you
00:04:11
going to use is it going to be a strict
00:04:13
contract with a schema or are all 45 of
00:04:16
those attributes going to be a loose
00:04:18
contract with just something like Json
00:04:19
are you going to pass an object in that
00:04:22
message
00:04:23
um and how are you going to manage it
00:04:25
how are you going to version it
00:04:27
when you make changes because you don't
00:04:29
want to break everything
00:04:31
oh yeah that's right yeah and what are
00:04:34
you going to do about stamp coupling and
00:04:36
bandwidth issues that are going to occur
00:04:38
with this and the developer says what
00:04:41
are you talking about
00:04:44
stamp coupling as a form of coupling
00:04:46
where you pass all of the information to
00:04:50
a particular service but it only uses a
00:04:53
few pieces of it maybe even one or two
00:04:55
attributes that's called stamp coupling
00:04:57
and two problems occur change and
00:05:01
bandwidth issues let me show you what I
00:05:03
mean if I change this contract
00:05:06
and change a field that payments and
00:05:09
inventory are not using well of course I
00:05:12
have to change
00:05:13
but that might facilitate a change in
00:05:16
payment and inventory as well even
00:05:19
though I don't care about that field
00:05:22
that's what stamp coupling is about but
00:05:25
there's also bandwidth issues because
00:05:26
you see that entire order is 500 KB
00:05:32
so 500 KB is being sent to both payment
00:05:35
and inventory payment only needs 350 KB
00:05:40
inventory only needs 50 KB
00:05:43
so I'm unnecessary unnecessarily
00:05:46
utilizing bandwidth I don't need
00:05:50
cloud-based environments this could get
00:05:53
quite expensive
00:05:56
oh and there's another problem by the
00:05:59
way
00:06:00
um and of course at this point the
00:06:02
developer starts getting really
00:06:03
frustrated but it keeps going what about
00:06:05
multiple systems of record because if
00:06:07
you're passing the entire payload of
00:06:09
that message over there that means every
00:06:11
one of you
00:06:13
have a copy of that
00:06:15
and you're not even looking at the
00:06:17
database where the true system of record
00:06:18
is so if I make changes to that order
00:06:21
it may be everywhere you might not have
00:06:23
the latest copy so that might produce
00:06:25
data Integrity issues as well
00:06:28
oh
00:06:30
you know so the developer says hmm you
00:06:33
know these are really good points
00:06:36
you know you've kind of convinced me
00:06:37
maybe a key based event payload would be
00:06:42
better
00:06:42
I mean after all I wouldn't have to
00:06:44
worry about stamp coupling it's a single
00:06:47
name value pair so there's really no
00:06:49
well there's still a contract but I'm
00:06:51
never going to change that I don't have
00:06:53
bandwidth issues I don't have stamp
00:06:54
coupling
00:06:56
and you're right I have a single single
00:07:00
system of record I get better data
00:07:02
Integrity you know you make really good
00:07:03
points maybe I should use the key based
00:07:06
and what happens
00:07:08
the developer now comes along or the
00:07:10
architect comes along and says yeah but
00:07:12
what are you going to do about
00:07:12
scalability and performance now
00:07:15
this is why thinking like an architect
00:07:18
is important
00:07:20
because of our first law of software
00:07:23
architecture
00:07:24
and that is that everything in software
00:07:27
architecture is a trade-off
00:07:30
and being able to think like an
00:07:32
architect and see things with an
00:07:34
architect's eye allows you to better
00:07:37
analyze these kind of trade-offs to
00:07:40
actually make the right decision to find
00:07:42
and seek out
00:07:44
those pros and cons
00:07:47
okay
00:07:49
so let's come back to thinking like an
00:07:51
architect what's involved in thinking
00:07:53
like an architect being able to apply
00:07:57
architectural thinking
00:07:59
to your daily job
00:08:01
regardless of your title or role
00:08:06
it really involves Three core things
00:08:10
the first is regardless of your role to
00:08:14
be able to understand the importance of
00:08:17
those business drivers in the
00:08:18
translation
00:08:20
to whatever those architectural
00:08:21
characteristics are
00:08:23
do you need High scalability
00:08:26
do you need High availability high
00:08:28
performance High agility High
00:08:30
responsiveness
00:08:32
what are those attributes or
00:08:34
characteristics of the architecture that
00:08:36
are important because we are
00:08:38
implementing
00:08:39
that architecture we should probably
00:08:41
know those
00:08:43
number two thinking like an architect is
00:08:46
also expanding your breadth of knowledge
00:08:51
to be able to see more solutions
00:08:54
to the problem
00:08:57
and also thinking like an architect is
00:09:00
being able to identify and analyze
00:09:03
various trade-offs these are the three
00:09:06
main components of actually seeing a
00:09:09
problem
00:09:10
with an architect's eye
00:09:13
as opposed to a developer's eye oh you
00:09:15
still have to see things with a
00:09:17
developer's eye of course especially
00:09:18
when you're faced with a particular
00:09:20
algorithm or problem or design problem
00:09:22
within your code
00:09:24
but it's also seeing the problem
00:09:26
architecturally as well let's take a
00:09:29
look at all three of these and see how
00:09:31
they all work and let's take a look at
00:09:32
what are the most foundational pieces of
00:09:35
what it means to see things like those
00:09:37
clouds with an architect's eye because
00:09:41
this is what the business is concerned
00:09:45
about
00:09:45
regardless of the type of system that
00:09:48
you're building
00:09:50
the business is concerned about things
00:09:52
like user satisfaction time to Market
00:09:54
competitive Advantage mergers and
00:09:56
Acquisitions Regulatory Compliance all
00:09:59
of these things are big concerns of
00:10:01
theirs
00:10:02
thinking architecturally
00:10:04
is translating these concerns
00:10:07
into exactly what the architecture needs
00:10:11
to support this is our language
00:10:14
we translate those into things like oh
00:10:16
fault tolerance reliability
00:10:18
recoverability responsiveness
00:10:20
performance availability
00:10:23
and that's what we need to build into
00:10:25
the architecture
00:10:28
to support those business needs
00:10:30
that's seeing it with the architect's
00:10:32
eye
00:10:33
but there's a problem here
00:10:36
because it's a problem of being Lost in
00:10:38
Translation
00:10:40
you see language of an architect is
00:10:42
talking all about fault tolerance
00:10:45
the language of the business is talking
00:10:48
all about user satisfaction
00:10:50
and the problem is
00:10:52
these two rarely meet because no one
00:10:54
knows what anybody's talking about
00:10:57
and this involves another aspect of
00:11:00
thinking architecturally
00:11:02
that brain of an architect
00:11:05
becomes like a translation engine
00:11:08
so if this is that important which it is
00:11:12
because these architectural
00:11:14
characteristics
00:11:15
become the foundational aspect of any
00:11:19
system or product
00:11:22
so if we don't know these
00:11:25
how can we possibly build a system how
00:11:27
can we possibly make decisions
00:11:31
okay so you've convinced me yeah we need
00:11:33
to know these but how do I know which
00:11:35
ones I mean I've never really thought
00:11:37
about this and I'd really like to as a
00:11:39
matter of fact on Monday when I kind of
00:11:41
go back to work I might want to start
00:11:42
thinking about these so where do they
00:11:44
come from
00:11:45
they come from one of three places
00:11:48
a lot of times they come just from the
00:11:51
domain
00:11:52
I mean the business domain for example
00:11:55
we're building a new stock trading
00:11:57
system to buy and sell stock
00:12:00
well I don't need
00:12:02
to go through a lot of analysis to know
00:12:04
that system has to be fast
00:12:07
high performance
00:12:10
High data integrity
00:12:13
so sometimes we could just extract these
00:12:15
from the nature of our business a lot of
00:12:18
times they're in requirements or user
00:12:21
stories but the user story does not
00:12:23
State we require High elasticity no the
00:12:27
user story looks like this we have to
00:12:28
support 20 to 200 000 concurrent users
00:12:31
and everything in between and it could
00:12:33
be immediate need
00:12:35
so those requirements or user stories
00:12:38
are not spelling out that exact illity
00:12:42
or architecture characteristic it's up
00:12:44
to us to interpret and know what that is
00:12:47
but it's interesting
00:12:49
in almost every system or product I've
00:12:52
worked on
00:12:53
the most valuable place
00:12:56
to find out what's important is actually
00:12:59
just using your ear and listening to the
00:13:02
business
00:13:05
let's actually do this this will be fun
00:13:07
so here's an example
00:13:10
thinking architecturally is that trans
00:13:12
translation engine that we have in our
00:13:14
mind
00:13:15
so let's say that the business says oh
00:13:18
yeah user satisfaction is absolutely the
00:13:20
most important thing we build our
00:13:23
company on user satisfaction
00:13:25
so what happens
00:13:27
we translate that to a characteristic
00:13:30
now this one's easy user satisfaction
00:13:33
ability
00:13:35
is it funny you could take any word and
00:13:37
just add the word illity after it and
00:13:39
all of a sudden you've got a new
00:13:40
characteristic
00:13:41
how about markability
00:13:44
hmm wonder what that means well that
00:13:47
one's easy too because I love drawing on
00:13:49
slides I love drawing on whiteboards and
00:13:51
so markability is the ability to like a
00:13:54
lot of drawings
00:13:56
there was one particular client
00:13:58
engagement I was on where we had fun
00:14:01
making up architecture characteristics
00:14:04
we would take the characteristics of
00:14:07
somebody on the team
00:14:08
and use their name and make an entity
00:14:10
for example take the person on the team
00:14:13
I mean who is the glue on the team I
00:14:16
mean they just bring everything together
00:14:18
so if we needed high amiability that
00:14:21
means we need High cohesion we need this
00:14:23
system to work together uh maybe you've
00:14:26
got somebody
00:14:27
um sebastiani who's maybe a a
00:14:29
perfectionist everything has to be
00:14:32
absolutely perfect
00:14:33
well that's sebastiani ability
00:14:36
the ability to have everything
00:14:37
absolutely the highest level of data
00:14:40
integrity and correctness in that system
00:14:41
it's kind of a fun exercise you should
00:14:43
try it you can make up any word but it's
00:14:46
not really user satisfactionability no
00:14:49
this requirement or need comes into our
00:14:52
translation engine
00:14:54
and out comes all those things the
00:14:57
architecture needs to support
00:14:59
performance agility so that we get bug
00:15:03
fixes Fast Fixed fast things like
00:15:06
scalability availability security
00:15:08
testability so we don't introduce bugs
00:15:10
recoverability so I don't lose my work
00:15:12
these are all things that make users
00:15:15
happy
00:15:16
and if our architectures don't support
00:15:18
these users will not be happy this is
00:15:21
that whole thing about seeing a
00:15:23
particular problem
00:15:25
with an architect's perspective
00:15:27
how about time to Market
00:15:30
that's the most important thing
00:15:32
so we feed that into our little
00:15:33
translation engine
00:15:36
and out comes all the things that the
00:15:38
architecture needs to support
00:15:40
maintainability testability
00:15:42
deployability these are things that we
00:15:46
as not only architects
00:15:48
but Developers
00:15:51
need to focus on
00:15:53
that's what we need to support
00:15:55
let's do one more mergers and
00:15:57
Acquisitions oh boy yes we're we're
00:16:00
constantly acquiring new companies
00:16:02
okay that one's easy resume ability yes
00:16:05
because my job will be replaced okay now
00:16:08
like I said you can make up any word
00:16:12
no we feed this in and what do you
00:16:14
suppose it's interesting think about
00:16:16
this one for a second
00:16:18
mergers and Acquisitions undergoing very
00:16:20
heavily in your company constantly
00:16:23
buying up other companies merging with
00:16:25
other companies you're an architect
00:16:26
you're a developer
00:16:29
what's on your mind about this let's
00:16:31
just Ponder this one for a little bit
00:16:33
hmm
00:16:34
would that matter
00:16:38
yeah it would
00:16:40
as a matter of fact a lot of things are
00:16:42
we leveraging standards it's going to
00:16:44
make it easier for us to communicate
00:16:45
with other systems that we have to
00:16:47
interoperability how open or closed are
00:16:51
our systems how scalable are they
00:16:53
because if we merge with another company
00:16:56
we possibly have just doubled
00:16:59
our customer base
00:17:01
think about that can our Systems Support
00:17:04
that extra customer load that extra user
00:17:08
load the capacities in our database
00:17:10
connection pools virtual machines
00:17:14
that's a big one on that
00:17:17
all right so this is one of those kind
00:17:20
of translation engines one of the
00:17:22
reasons this is so important
00:17:23
it's because these these characteristics
00:17:26
when we see these help us qualify and
00:17:29
make decisions this is the star rating
00:17:32
chart from our book fundamentals of
00:17:33
software architecture
00:17:35
and we can kind of utilize this if
00:17:39
and only if
00:17:41
we know
00:17:43
our characteristics
00:17:46
which architecture style should you use
00:17:48
microservices of course no
00:17:52
which of these eight should you use
00:17:55
I I I I don't know what can I base that
00:17:58
on oh what's important to you oh
00:18:01
scalability is exactly what we need we
00:18:04
have to be highly scalable
00:18:06
well this kind of chart using
00:18:09
qualitative analysis allows us to kind
00:18:11
of look for the areas that have five
00:18:13
stars that means it's really well
00:18:15
supported if the architecture doesn't
00:18:18
support scalability
00:18:21
it doesn't matter how much you do from a
00:18:24
physical operational standpoint
00:18:27
you won't be able to scale
00:18:30
so consequently we look at this chart
00:18:32
and say huh which architectures tend to
00:18:34
scale better than others and we find of
00:18:36
course micro Services event driven and
00:18:39
space-based architecture
00:18:42
are really good choices
00:18:44
the layered architecture with one star
00:18:46
is not
00:18:48
how do we know this
00:18:50
architectural thinking
00:18:53
being able to see a problem and this is
00:18:56
what an architect sees
00:18:58
I don't see class Styles I don't see
00:19:00
methods I don't see algorithms design
00:19:03
patterns oh what I see floating in front
00:19:06
of my face are all of these
00:19:08
characteristics and those are my driving
00:19:10
forces to make decisions
00:19:14
now a resource that you could actually
00:19:15
use oh and by the way yeah let's do
00:19:17
another one let's say that's constant
00:19:19
Simplicity we're a startup
00:19:22
don't have a lot of money
00:19:25
we don't want to add a lot of complexity
00:19:27
at the very very start of our life as a
00:19:30
company
00:19:31
those are our most important things
00:19:35
we do qualitative analysis We compare
00:19:37
the quality of one thing to another and
00:19:40
we find hmm
00:19:41
I'm guessing maybe we shouldn't do micro
00:19:44
Services first maybe let's start with a
00:19:48
monolith
00:19:49
any one of these three and then migrate
00:19:52
as soon as we find out if this idea is
00:19:54
going to work and we start growing
00:19:56
yeah these are guidelines these are
00:19:58
guide posts
00:19:59
so one of the tools that I could offer
00:20:02
you that you can use is this
00:20:04
characteristics worksheet and this is
00:20:06
what I use at work
00:20:08
this is what I use on my Consulting
00:20:11
engagements to help identify these
00:20:14
driving forces
00:20:16
so you can download this from my website
00:20:18
under resources and it's in PDF
00:20:20
PowerPoint and keynote format change it
00:20:23
if you want to that's fine but this
00:20:26
allows you to start looking at and by
00:20:28
the way that there's three pages because
00:20:29
they show definitions I show definitions
00:20:31
of each of these kind of core
00:20:33
characteristics and I also have a lesson
00:20:36
lesson 112 on my software development
00:20:38
our software architecture Monday to show
00:20:41
kind of how this works anyways it's a
00:20:44
really useful tool for starting to say
00:20:46
you know I think I'd like to start doing
00:20:48
that I'd like to start thinking like an
00:20:51
architect and I'm going to see if I can
00:20:53
come up with what characteristics on the
00:20:55
current product I'm working on are
00:20:58
important and are we really supporting
00:21:00
those
00:21:01
and do we have the right architecture in
00:21:03
place guess what by doing those three
00:21:05
things
00:21:06
you know what you all are doing
00:21:09
exactly the same thing an architect
00:21:12
would do
00:21:14
thinking like an architect you don't
00:21:16
have to be an architect to think like an
00:21:19
architect
00:21:20
so here's the bottom line of this part
00:21:22
one right here
00:21:23
you cannot and this is what I maintain
00:21:26
you cannot do this
00:21:29
create an architecture
00:21:32
unless you have these
00:21:35
otherwise how are you going to make a
00:21:38
decision
00:21:40
what's needed this looks like an
00:21:42
interesting design but does it satisfy
00:21:44
the needs of the application the domain
00:21:47
and The Business
00:21:50
all right that's
00:21:51
part of thinking like an architect
00:21:53
having those foundational aspects that
00:21:56
drive all the rest of your decisions
00:21:58
even at an implementation level knowing
00:22:02
these and knowing that scalability is
00:22:04
that important and qualifying it will
00:22:07
allow you to think about the designs of
00:22:09
your code
00:22:10
with scalability in mind as well or
00:22:13
availability or fault tolerance
00:22:15
okay
00:22:17
the next part though about thinking like
00:22:19
an architect is expanding what's known
00:22:21
as our technical breadth the amount of
00:22:24
things we know
00:22:26
because as an architect you see a
00:22:28
problem
00:22:29
I have to see and visualize in my mind
00:22:32
the possible solutions
00:22:34
but what if you only know one particular
00:22:37
solution it might not be the right one
00:22:40
so it turns out that this is called a
00:22:43
triangle of knowledge and there are
00:22:45
three types of knowledge that exist in
00:22:47
the world let's scope it down to
00:22:49
technology knowledge that would be a lot
00:22:51
better
00:22:52
um well way up here at the top
00:22:55
is the stuff that you know
00:22:57
these are things you do every day you
00:22:59
know them so well that you could
00:23:01
actually get up on stage here
00:23:03
and talk about them it'd be a little
00:23:05
scary but you could
00:23:07
but right below that is a bigger area of
00:23:10
knowledge called the stuff that you know
00:23:12
that you don't know
00:23:15
this means you know or are familiar
00:23:17
about something
00:23:19
but you have no idea how to use it
00:23:22
um close your programming language is a
00:23:24
good example I'm sure most if not all of
00:23:27
you have heard about closure it's a
00:23:28
programming language that uh boy you
00:23:31
gotta love parentheses if you're going
00:23:32
to use it it usually uses the atomic
00:23:34
transactional memory all this kind of
00:23:35
stuff
00:23:36
but how many of you can code
00:23:39
enclosure not it that's a good example
00:23:43
of something that you've heard of that
00:23:44
you know that you know nothing about but
00:23:47
you're familiar with it
00:23:48
but the biggest area of knowledge that
00:23:51
exists is this bottom large Blue Area
00:23:54
this is the stuff that you don't know
00:23:57
that you don't know
00:23:59
this is all the possible solutions tools
00:24:03
products patterns that would be the
00:24:06
perfect fit perfect fit for what you're
00:24:08
doing and you don't even know it exists
00:24:12
so one of the
00:24:15
well I'll call it a game of life
00:24:19
is to take stuff that you've never ever
00:24:23
heard of that bottom area of the
00:24:25
triangle stuff that you don't know that
00:24:27
you don't know
00:24:29
and move it into the stuff that you know
00:24:32
you don't know
00:24:35
how do you do this talk with people say
00:24:37
oh I haven't heard of that before what
00:24:39
is it and now you suddenly have it in
00:24:42
your second level of knowledge
00:24:44
it's going to conferences like this
00:24:47
and challenging yourself to say well I'm
00:24:49
a react programmer so I'm going to do
00:24:51
all react talks
00:24:53
now the proper way to take advantage of
00:24:57
conferences like this is to attend a
00:25:00
talk of something you've never heard of
00:25:03
it's fantastic way to learn about a
00:25:06
possible tool a technique a solution
00:25:09
that you may not use now
00:25:12
but it's in your brain
00:25:15
and you'll pull it out sometime and say
00:25:16
wait a minute I remember I was at gids23
00:25:20
and I remember I was walking along in
00:25:22
the the exposition Hall there and I was
00:25:25
like what is this product okay that's a
00:25:27
two or three minute conversation
00:25:29
you have now taken something that you
00:25:31
didn't know that you didn't know and say
00:25:34
oh now I know what it does
00:25:36
okay then
00:25:39
either something because we are all
00:25:41
technologists that pique your interest
00:25:43
something that you get really excited
00:25:45
about or your boss says starting next
00:25:47
week we shall be using closure oh
00:25:50
that's when you take something that you
00:25:52
know you don't know
00:25:54
and you move it into something now that
00:25:57
you know
00:25:58
but there's a cautionary tale here
00:26:00
everybody
00:26:02
watch out for this top part of the
00:26:05
triangle
00:26:06
because the stuff you know is the stuff
00:26:09
you have to maintain
00:26:12
and if you like working 24 hours a day
00:26:15
if you don't have kids if you have no
00:26:17
life and no friends don't worry about it
00:26:20
but if you do
00:26:22
you can't do it all because if you don't
00:26:25
maintain that it suddenly trickles down
00:26:28
like teardrops all the way back down
00:26:31
into something that now you know you
00:26:33
don't know
00:26:34
about 10 years ago it was mostly
00:26:36
programming in the Scala language I
00:26:39
started the Boston Scala users group
00:26:41
that's all I was doing at client sites
00:26:43
with Scala I loved it
00:26:46
that was 10 years ago
00:26:48
now
00:26:50
I would be lucky to be able to start a
00:26:53
scholar class file it's something I
00:26:55
chose not to maintain so it dripped back
00:26:57
down so just a cautionary tale be
00:27:00
careful okay
00:27:01
well let's do an interesting exercise
00:27:04
because of this
00:27:07
the stuff you know
00:27:09
is called technical depth
00:27:12
we all need technical depth including me
00:27:17
a seasoned architect
00:27:19
we all need technical depth but that's
00:27:22
stuff you know plus the stuff that you
00:27:24
know you don't know is considered
00:27:26
technical breadth
00:27:28
and here's the key point
00:27:31
thinking like an architect
00:27:33
starting to make more effective
00:27:36
decisions
00:27:38
create better software systems
00:27:41
and start propelling your career
00:27:43
into that Tech lead and into that
00:27:46
architect position
00:27:48
means to exactly Focus right here
00:27:53
and that's hard
00:27:55
it means focusing
00:27:57
on technical depth with a sacrifice I'm
00:28:00
sorry technical breadth
00:28:02
with a little bit of a sacrifice of
00:28:04
technical depth
00:28:05
start broadening your horizons okay
00:28:10
well let's actually play this game
00:28:12
what we're going to do is we're actually
00:28:15
now that we understand this triangle of
00:28:16
knowledge let's have some fun with it
00:28:19
let's take a look at the brain
00:28:22
of a junior developer
00:28:24
then let's take a look inside the brain
00:28:26
of a senior developer
00:28:29
then we're going to take a look inside
00:28:30
the brain of a junior architect
00:28:33
and finally a senior architect
00:28:35
this is going to be an amazing journey
00:28:38
so now that we understand that levels
00:28:40
are trying the levels of knowledge let's
00:28:42
open up the brain
00:28:44
to a junior developer
00:28:46
this is what a junior developer's
00:28:48
knowledge triangle looks like typically
00:28:50
notice what is the biggest part of this
00:28:53
triangle
00:28:54
it's the stuff that you don't know that
00:28:57
you don't know sure I am a Java
00:29:00
developer what do you do Java
00:29:03
what do you know Java
00:29:05
okay
00:29:07
notice my technical breadth is pretty
00:29:11
small
00:29:12
and that's fine that's appropriate
00:29:14
because as a junior developer I am hired
00:29:17
for my technical capability
00:29:20
on that particular technology
00:29:23
this is good this is what it should look
00:29:25
like but what happens are you ready
00:29:27
watch this as we move from a junior
00:29:30
developer to a senior developer
00:29:34
did you notice what happened to the
00:29:35
triangle
00:29:36
I want to do that again because this is
00:29:39
going to start morphing like this wait a
00:29:40
minute let me go backwards one
00:29:42
are you ready watch the shape of the
00:29:45
triangle here we go Junior developer
00:29:48
starts going into a senior developer
00:29:49
five or six years experience
00:29:52
and what do you notice happen
00:29:54
the stuff you know
00:29:56
increases
00:29:58
multiple platforms multiple languages
00:30:00
multiple patterns multiple tools
00:30:01
multiple techniques multiple Frameworks
00:30:03
the list goes on
00:30:05
and as a matter of fact that you notice
00:30:07
what part of the triangle got smaller
00:30:10
the stuff you know you didn't know that
00:30:12
you didn't know
00:30:13
but notice our technical breadth
00:30:16
still not strong
00:30:19
and that's okay
00:30:21
because we are focused on a technology
00:30:24
solution to a problem
00:30:26
but you get that big break
00:30:29
and all of a sudden now
00:30:31
yes your first opportunity as an
00:30:33
architect
00:30:34
you become a junior architect
00:30:37
you ready I'm going to transfer now this
00:30:39
is what your brain starts to look like
00:30:42
did you notice what happened as you move
00:30:44
into and step into
00:30:47
an architect position
00:30:49
what happened
00:30:50
you sacrificed some of that stuff you
00:30:54
know
00:30:55
that expertise
00:30:57
to broaden the stuff that you know you
00:31:01
don't know
00:31:02
as an architect you're starting to look
00:31:04
at 10 different caching Technologies not
00:31:08
just redis for example what are the
00:31:13
different caching tools and Technologies
00:31:14
what do they support what are the pros
00:31:16
what are the cons oh I may not know how
00:31:19
to code at any of these that's fine
00:31:21
but as an architect I know the
00:31:23
trade-offs of each of these hey which
00:31:25
one would probably be the most
00:31:27
appropriate solution for our particular
00:31:29
problem
00:31:31
now final Journey you start
00:31:34
developing your careers in architect you
00:31:37
start getting that senior architect kind
00:31:39
of position that Enterprise architect
00:31:40
and this is what your knowledge triangle
00:31:43
now starts to look like
00:31:45
notice we haven't done much with our
00:31:47
technical depth
00:31:49
but we've significantly broadened the
00:31:51
stuff that we know we don't know
00:31:55
so this is kind of one of those key tips
00:31:59
tricks to managing
00:32:02
your entire career
00:32:04
regardless of where you are in it
00:32:08
did you just graduate from school
00:32:10
cool focus on the technology that you're
00:32:13
interested in that's all you should do
00:32:16
and you could use this transition
00:32:18
to kind of map out where you should
00:32:21
probably be in these various knowledge
00:32:23
pieces
00:32:24
well Mark this is absolutely fabulous
00:32:28
this is really cool
00:32:30
I wish I had as much time as you
00:32:33
to be able to go research and do stuff
00:32:35
and kind of learn things I don't know ah
00:32:38
yeah no I'm stuck 12 hours a day coding
00:32:41
Java
00:32:42
ah let me show you how to do this
00:32:45
so isn't it interesting if we look at
00:32:47
the difference between a developer's
00:32:49
head and the way they see things and an
00:32:52
architect's head
00:32:53
and the way they see things
00:32:55
it's all about that middle area
00:32:59
the more you know
00:33:01
about stuff you don't know
00:33:04
the more you're going to be able to find
00:33:07
solutions to problems that are the most
00:33:10
appropriate solution
00:33:13
okay
00:33:14
so how do you do this
00:33:16
how do you start gaining that technical
00:33:18
depth
00:33:20
this is exciting
00:33:22
well what are the ways to do it is a
00:33:24
conferences like this or just start
00:33:27
going
00:33:28
to some of these resources that are free
00:33:32
and let me show you three that I
00:33:33
typically use the first one I go to
00:33:36
quite often is a info queue infoq.com
00:33:41
uh now I'm going to show you this in a
00:33:43
little bit but every uh about two times
00:33:46
a week I get an email with all these
00:33:48
different things that are trending all
00:33:49
these different Technologies
00:33:51
um it's a really really good go-to place
00:33:54
for architecture for all these kind of
00:33:56
things
00:33:58
technology you name it uh the second
00:34:00
place that I sometimes go to are the
00:34:02
d-zone ref cards now not necessarily
00:34:05
d-zone
00:34:07
um in my experience d-zone is kind of
00:34:09
Hit or Miss but the ref cards are really
00:34:12
useful because I don't have a lot of
00:34:14
time when I was in college back in the
00:34:17
turn of the century
00:34:20
uh I did not have time to read War and
00:34:23
Peace or Homer's Iliad or Odyssey I had
00:34:27
other things to do hang out with my
00:34:28
friends just go hiking around and stuff
00:34:30
so what did I do
00:34:33
I leveraged something called Cliff Notes
00:34:35
now here's Monarch notes but these were
00:34:37
little booklets
00:34:39
that just gave you a summary the
00:34:42
highlights of those epic novels yeah I
00:34:45
could I could read that in an afternoon
00:34:47
and so
00:34:51
so that's what I did most of the time
00:34:53
now I'm going back and reading all those
00:34:56
wonderful epic novels but at the time I
00:34:58
wasn't interested
00:35:00
and so those little tiny booklets Cliff
00:35:03
Notes Monarch notes really helped me to
00:35:06
participate in the class to really gain
00:35:08
the understanding of those books without
00:35:10
having all the details that I didn't
00:35:12
really care about
00:35:13
oh what did I just describe
00:35:17
ref cards
00:35:19
yeah these are two to six page cards
00:35:21
that talk about a particular technology
00:35:24
just the right exact level
00:35:28
for me as an architect
00:35:30
say what is it why is it here what are
00:35:34
the good things and what are the bad
00:35:35
things about it yeah so those are those
00:35:38
are pretty useful to gain that technical
00:35:40
knowledge without having to go too deep
00:35:42
oh you can study what hazelcast is all
00:35:44
about you don't have to go and code it
00:35:46
you can understand uh different
00:35:48
languages you don't have to go and code
00:35:50
them
00:35:51
you just have to understand what they do
00:35:53
why they're there how do they
00:35:55
differentiate themselves from all the
00:35:57
other 25 programming languages I could
00:35:59
choose right now yeah another place to
00:36:01
go
00:36:03
is a thoughtworks technology radar which
00:36:06
by the way just came out Tuesday this
00:36:08
comes out twice a year all these are
00:36:10
free
00:36:11
this whole stuff is all available to you
00:36:14
and the thoughtworks technology radar
00:36:16
twice a year are most of the luminaries
00:36:20
in the field Neil Ford is one of those
00:36:21
James Lewis Martin Fowler I mean these
00:36:24
are folks who have a pulse on the
00:36:26
industry
00:36:27
they show you what things are trending
00:36:29
what things aren't
00:36:31
it's a really great resource now here's
00:36:34
a little test for all of you go to the
00:36:37
thoughtworks radar you think oh I I
00:36:38
don't need that I already know what's
00:36:40
happening in the field I already know
00:36:41
everything I know everything
00:36:44
I will guarantee you
00:36:46
they'll show 20 things that are trending
00:36:48
in the industry I will guarantee you
00:36:52
maybe you've heard of four of those
00:36:56
yeah what a humbling experience it's
00:37:00
like this is something they're saying to
00:37:02
adopt and I've never heard of it
00:37:04
what is that that's something that I
00:37:07
don't know that I don't know
00:37:08
I probably should know it
00:37:11
not be an expert but just know it these
00:37:13
are three really good resources oh
00:37:15
there's a lot of other good resources to
00:37:17
use as well but these are just three I
00:37:18
can offer up to you
00:37:20
now I can go back and say huh
00:37:23
what do these look like well let me show
00:37:25
you the three levels of knowledge now
00:37:27
this might be a little hard to see on
00:37:29
the screen here but this is uh I'm going
00:37:30
to zoom in but this is a snapshot of my
00:37:32
email and this is let me Zoom it in just
00:37:35
a little bit
00:37:36
um this is what it looks like so when I
00:37:38
get my email it has a black a dark
00:37:40
header line
00:37:41
with a laundry list of buzzwords
00:37:47
and I look at that I take a look at that
00:37:48
and all of a sudden I start to see
00:37:50
things like oh plastic arm what is that
00:37:55
plastic arm is it like
00:37:57
an actual arm it's plastic
00:38:00
I've never heard of that before ha
00:38:02
something that you don't know that you
00:38:05
don't know
00:38:05
bottom level of the triangle
00:38:08
it happens to be
00:38:10
fabric based microchips
00:38:13
for all sorts of haptic sets and all
00:38:15
this really cool stuff okay how about
00:38:17
this
00:38:18
um solid.js well we can ignore that
00:38:21
right because every day another new
00:38:23
JavaScript framework comes out so just
00:38:25
forget that yeah yeah never mind yeah so
00:38:27
that that's that's Way Beyond all three
00:38:30
levels of knowledge that's stuff that
00:38:31
you could throw away okay that's the
00:38:33
trash can okay but all this other stuff
00:38:35
Apache Pinot what does that mean the
00:38:38
Apache Foundation is now making wine
00:38:40
Apache Chardonnay is really good
00:38:44
but Apache Sauvignon is also buried yeah
00:38:47
what in the world's Pino it's there
00:38:49
um stuff like this you know uh AWS
00:38:52
proton oh yeah we're we're an AWS shop
00:38:54
what's proton
00:38:56
I I I I don't know should we be using it
00:38:59
I don't know these are things you've
00:39:02
never heard of this is the value of
00:39:05
these resources you see a buzzword
00:39:07
that you've never heard of before
00:39:10
spend a couple of minutes to see what it
00:39:12
is
00:39:14
that's all you need to do
00:39:16
and now all of a sudden you say
00:39:18
proton where were you six months ago oh
00:39:22
it's been out longer than that where was
00:39:24
I six months ago
00:39:25
if they would have solved all our
00:39:27
problems we could have shaved five
00:39:29
months off our project that's the value
00:39:32
of architectural thinking of expanding
00:39:35
that breadth of knowledge
00:39:40
mark
00:39:41
this is really cool
00:39:43
but I don't have time for this
00:39:46
I wish I had as much time as you to kind
00:39:48
of just click on these and peruse these
00:39:51
and all this well let me give you a
00:39:53
little secret I don't either
00:39:56
I work between 12 and 15 hours a day
00:39:59
seven days a week
00:40:00
I don't have time for this
00:40:02
so here's my technique I kind of created
00:40:05
something
00:40:06
called what well at least what I call
00:40:09
the 20 minute rule
00:40:12
and here's what I do
00:40:15
I spend 20 minutes a day
00:40:18
just 20 sometimes more but at least 20
00:40:21
minutes a day
00:40:25
on me on my career on myself
00:40:29
to expand my technical breadth
00:40:33
oh I may go to info queue I may just
00:40:35
create a list of words I've never heard
00:40:37
of and that's going to queue up for
00:40:39
tomorrow which I may look at two or
00:40:41
three of those
00:40:42
now here's the other secret though
00:40:47
when do you do this
00:40:48
oh launch that'd be a good time yeah how
00:40:51
many of us get to take lunch seriously
00:40:53
no yeah after after work this would be a
00:40:57
good time to do it uh-huh
00:40:59
yeah how many of you have families
00:41:01
yeah you get home after a hard day and
00:41:03
your spouse goes here I'm going out
00:41:07
and you look at your child and go what
00:41:09
did you do today
00:41:10
yeah you're not going to spend 20
00:41:12
minutes learning about proton no
00:41:15
here's the trick
00:41:17
first thing in the morning
00:41:20
now
00:41:21
let me qualify that
00:41:23
what's the very very first thing you do
00:41:26
when you wake up in the morning and but
00:41:27
by the way I'll answer that first you
00:41:30
get that blessed cup of coffee or tea
00:41:33
yes
00:41:34
okay what's the very very very next
00:41:38
thing you do
00:41:39
when you sit down at work whether it be
00:41:41
at your home office or whatever
00:41:44
email check email and your day is over
00:41:49
you start getting involved it's like oh
00:41:51
it's like oh no I've got a meeting in 10
00:41:53
minutes oh we've got a production outage
00:41:54
right there oh yeah never okay so
00:41:58
my day looks like this I get that
00:42:00
blessed cup of coffee or tea
00:42:04
and then I spend 20 minutes enjoying
00:42:07
that nice hot beverage well I work on me
00:42:12
my career
00:42:15
my architectural thinking my technical
00:42:17
breath
00:42:18
if I could spend 30 awesome but 20 is
00:42:21
good
00:42:22
most articles are designed for seven or
00:42:24
ten minutes my videos of software
00:42:27
architecture Monday on purpose are 10
00:42:28
minutes so you can do other things
00:42:30
during the 20-minute rule as well try it
00:42:33
out
00:42:34
try it out because if you can't spend 20
00:42:37
minutes in the morning on yourself
00:42:41
then there's other problems that we need
00:42:43
to discuss I'll be in the speaker's
00:42:45
Lounge after the thing
00:42:51
well there's one other aspect so give it
00:42:53
a try give it a try download that
00:42:56
architecture characteristics worksheet
00:42:58
give it a try just see if you can start
00:43:00
to think about what are the
00:43:02
characteristics that's architectural
00:43:04
thinking
00:43:06
um expand your technical breath
00:43:08
these are easy things that are free
00:43:11
okay there's one more element that we
00:43:13
can talk about and that's analyzing
00:43:15
trade-offs this is another thing of
00:43:17
thinking like an architect I need to
00:43:19
channel my friend Rich hickey who
00:43:22
created closure
00:43:23
and here's a quote that's quite
00:43:25
controversial but it's quite funny and
00:43:28
sometimes sometimes quite true and he
00:43:30
says this
00:43:33
developers know the benefits of
00:43:35
everything
00:43:36
and the trade-offs of nothing
00:43:39
and I've seen it I mean it's not always
00:43:41
true I have worked with development
00:43:43
teams and developers who do know about
00:43:46
trade-offs
00:43:47
but a lot of us get excited about a
00:43:49
particular technology a framework a tool
00:43:52
a language
00:43:54
and we only see the good stuff we don't
00:43:56
see the bad stuff
00:43:58
yeah so let's see about analyzing
00:44:01
trade-offs because this is another way
00:44:02
of thinking like an architect okay
00:44:05
so here's our first law again and we
00:44:07
keep bringing this up because it's so
00:44:09
important
00:44:10
everything in software architecture is a
00:44:13
trade-off
00:44:14
and the structural aspect of software
00:44:17
architecture and the structural aspect
00:44:20
of Building Systems
00:44:21
there are no best practices
00:44:26
how can you possibly say you should all
00:44:28
focus on performance
00:44:30
oh we don't care about performance no
00:44:33
that's not a best practice you should
00:44:34
always use microservices yeah we're a
00:44:37
small startup shop
00:44:38
I mean challenge yourself
00:44:40
Neil and I have that's how we came up
00:44:42
with the law yeah now I qualified it to
00:44:45
say the structural aspect because there
00:44:47
are some best practices in architecture
00:44:50
one of them
00:44:52
always collaborate with your development
00:44:55
team and stakeholders yeah if you don't
00:44:57
it'll fail
00:44:58
yeah that's a best practice but it's the
00:45:00
process part of architecture I use
00:45:03
architecture decision records to justify
00:45:05
my architecture decisions that's a best
00:45:08
practice
00:45:09
but within a structural aspect
00:45:12
no there's none
00:45:14
so follow-up question in our second book
00:45:17
architecture the hard parts and that is
00:45:20
okay then
00:45:22
so what happens when there are no best
00:45:23
practices
00:45:25
this everybody is why architecture is
00:45:29
hard
00:45:33
it's because
00:45:34
we don't have that many guideposts
00:45:36
because it's all 100 contextual
00:45:40
so how do we make decisions this is one
00:45:43
of the things an architect does this is
00:45:45
architectural thinking analyzing
00:45:47
trade-offs well not surprisingly how did
00:45:50
them do we make a decision A or B uh
00:45:54
I guess we could flip a coin no I have a
00:45:56
better idea understand the business
00:45:58
drivers first
00:46:00
what's important to the business and
00:46:02
they say time to market the most
00:46:05
important thing we've got a lot of
00:46:06
important things but that one's way up
00:46:08
at the ceiling
00:46:09
all right all right so we understand
00:46:11
that do you remember the first section
00:46:14
what do we do with that information
00:46:17
yeah exactly doesn't matter if you're
00:46:19
not an architect
00:46:21
you say huh so they need speed to Market
00:46:23
well I wonder what that means that kind
00:46:25
of translates to architectural
00:46:27
characteristics about maintainability
00:46:30
testability the ease of incompleteness
00:46:32
of testing and also deployability the
00:46:35
ceremony of deploying our software the
00:46:37
frequency and the overall risk
00:46:40
it's all three of these that give us
00:46:42
time to Market oh it doesn't matter how
00:46:44
fast you can find the change and make it
00:46:46
as a developer if it takes you six weeks
00:46:48
to test
00:46:50
good luck
00:46:53
if you're wondering by the way
00:46:56
um
00:46:57
if you don't believe me about these
00:46:58
three
00:46:59
what is the fastest possible way
00:47:02
in the world to get your changes
00:47:04
released to your customers fastest way
00:47:07
in the world
00:47:11
don't test
00:47:13
make the change release make the change
00:47:15
release make change release
00:47:18
yeah is that time to Market
00:47:20
no that's killing your company
00:47:24
yes so the point is it's all three of
00:47:27
these we need that ease of and
00:47:29
completeness of testing because as we
00:47:30
move faster we want to make sure we're
00:47:33
not introducing more and more and more
00:47:34
and more bugs into the system we will
00:47:37
lose it doesn't matter how fast we can
00:47:39
be it's all three of these
00:47:41
we take this information
00:47:43
and then we do this huh
00:47:46
I have a decision to make what do I do I
00:47:49
look at the pros and cons
00:47:51
and I try to boil them down and simplify
00:47:54
them
00:47:55
and this is what it ends up to be
00:47:57
performance versus maintainability
00:48:00
that's what it boils down to single
00:48:03
service three services single Services
00:48:04
faster three services this is gives us
00:48:07
better maintainability pick one it's
00:48:09
almost like cap theorem we can't really
00:48:10
do both of these
00:48:12
well how do we make a choice obviously
00:48:14
performance
00:48:15
oh I better not get on that soapbox
00:48:18
thank God pre-optimization of
00:48:20
performance could even be a keynote oh
00:48:22
boy yeah because think about it as a
00:48:24
developer
00:48:25
we want things to be fast
00:48:28
that's what our primary focus is on our
00:48:30
mind
00:48:30
that's seeing things with a developer's
00:48:32
eye a developer's perspective we want
00:48:35
fast code
00:48:38
seeing things with an architect's eye
00:48:40
says yeah we got to make our code fast
00:48:43
but hold on a second
00:48:45
what's most important to the business
00:48:48
well if we can tie them back to the
00:48:51
architecture characteristics we see that
00:48:53
maintainability is actually on that list
00:48:56
and if we tie it back to the business
00:48:58
need we see that time to Market would be
00:49:01
much better if I can make maintainable
00:49:03
code in other words break apart my
00:49:05
services
00:49:06
and so do you see
00:49:08
by going backwards now
00:49:10
I can actually make a decision and say
00:49:14
that's why we're going to break apart
00:49:16
our services
00:49:18
it's going to be slower
00:49:20
but time to Market is more important to
00:49:22
the business
00:49:23
that's what the architecture has to
00:49:25
support that is modern trade-off
00:49:28
analysis this is now seeing decisions
00:49:31
that you need to make with an
00:49:33
architect's eye and architect's point of
00:49:35
view
00:49:36
okay well let's try this out
00:49:39
let's actually show I want to show you a
00:49:41
couple of tips the first pro tip is this
00:49:44
watch out for something called the out
00:49:46
of context trap as a matter of fact this
00:49:48
is out of context anti-pattern when
00:49:51
we're starting to analyze trade-offs
00:49:53
let me show you what I mean
00:49:55
so
00:49:56
I'm wondering of a query I can't decide
00:50:00
whether I should use a shared library or
00:50:03
a shared service
00:50:05
for all my shared functionality this is
00:50:07
a developer decision something a
00:50:10
developer is probably going to make
00:50:12
where do I put all of those calculators
00:50:14
that are shared all of my utilities my
00:50:17
utility.cs my utility.java my utility.py
00:50:20
what do I do with all that code hmm
00:50:24
well I don't know oh wait a minute I
00:50:27
just attended gids23 and I attended this
00:50:30
keynote about analyzing trade-offs
00:50:33
that would be a good start
00:50:37
so let's actually do this
00:50:39
so what I'm going to do is create a
00:50:41
scorecard
00:50:42
and I'm going to start looking at the
00:50:44
pros and cons of each of these
00:50:46
so
00:50:47
heterogeneous code that's the first one
00:50:49
which works better well heterogeneous
00:50:52
code does not work well with shared
00:50:54
libraries because if I've got five
00:50:56
platforms I've got five copies of that
00:50:59
shared Library five copies of the code
00:51:01
but with a shared service
00:51:04
doesn't matter if you're even in a
00:51:05
Mainframe call me it's in one place
00:51:08
oh score one for shared service ah but
00:51:12
what about high code volatility our code
00:51:14
changes all the time
00:51:16
well in a shared Library what's going to
00:51:18
happen
00:51:19
I'm going to continue to version until I
00:51:21
reach that Max version number that's
00:51:22
supported and all of you even if you're
00:51:25
not using the utility are going to have
00:51:27
to retest and redeploy
00:51:29
and rebuild
00:51:31
every single week
00:51:34
that's a lot of churn oh that's not
00:51:36
going to work but what happens with a
00:51:38
shared service that code changes all the
00:51:40
time yeah it just changed the podium
00:51:42
yeah I just changed the podium yeah you
00:51:44
guys all just use it
00:51:47
okay what about the ability to version
00:51:49
things though
00:51:52
shared library now has a check mark this
00:51:55
gets a plus one yeah it's hard diversion
00:51:58
runtime changes
00:52:01
but I converge in a dll or a jar file or
00:52:04
a gem
00:52:05
that's not hard
00:52:07
actually it is
00:52:08
fallacy number nine of distributed
00:52:10
computing
00:52:12
what about overall change risk
00:52:14
yeah if I make a change to that Podium
00:52:16
that's our shared service right there
00:52:17
and I really messed something up
00:52:21
I've just now broken every single one of
00:52:23
you
00:52:24
because it's hard to version that's a
00:52:26
runtime change in production once I
00:52:29
deploy that service all of a sudden boom
00:52:31
boom boom boom everybody's like hey why
00:52:33
are you all leaving the uh tutorium uh
00:52:36
oh because that change made the speaker
00:52:38
go away and uh and also you can't hear
00:52:41
me is or the microphone and so it's a
00:52:44
lot more risk
00:52:46
But Eric but with shared libraries I
00:52:49
have backwards compatibility I have
00:52:50
agility
00:52:51
then cat needs a change immediately okay
00:52:53
then cut type type type here you go
00:52:55
version 2.3.4 done
00:52:58
I gave that to him just now
00:53:01
the rest of you YouTube 2.4.2
00:53:05
backwards compatibility and Agility
00:53:08
because now we have to start now all
00:53:10
changing at some point but what about
00:53:13
the operational characteristics things
00:53:15
like performance things like fault
00:53:17
tolerance scalability
00:53:19
these are all bad in a shared service
00:53:24
at this Podium fell to the ground no
00:53:26
longer available neither are any of you
00:53:29
yeah all of a sudden if all of you and I
00:53:32
think I did this yesterday on stage here
00:53:33
all of a sudden ask me a question all at
00:53:35
once
00:53:36
I'm going to get overwhelmed and just
00:53:38
curl up on the stage and to a ball and
00:53:41
start crying
00:53:42
um yeah these are the problems it's
00:53:44
going to be slow to go all the way from
00:53:46
the front there especially with all
00:53:47
these Pathways to ask me a question if
00:53:50
you want to ask me a question to
00:53:51
communicate with me you have to actually
00:53:52
come onto the stage and shake my hand
00:53:54
that's going to take forever
00:53:57
not with a shared Library
00:54:00
do you see a clear winner here
00:54:04
yeah count up the check marks and we
00:54:07
find this is why using a shared library
00:54:11
is a best practice
00:54:15
hopefully now you know I'm teasing
00:54:18
because there is no such thing as a best
00:54:20
practice
00:54:21
this everyone is an anti-pattern
00:54:25
avoid it like the plague this is called
00:54:29
the out of context trap what's my
00:54:31
context me Mark Richards personally this
00:54:35
is my context well we have Services
00:54:37
written in four different languages so
00:54:39
we're using polyglot programming and
00:54:41
we're not really concerned about
00:54:42
performance or scalability no our
00:54:45
biggest issue and our product right now
00:54:47
is managing changes
00:54:50
to Shared functionality that occur
00:54:52
frequently that's my problem
00:54:55
oh what happens if we go back to the
00:54:57
scorecard
00:55:00
that's plus two to zero
00:55:04
yeah that's how we make the choice
00:55:07
we apply the context
00:55:09
and now a shared service is better even
00:55:12
though it has more X's I don't care
00:55:14
about those X's now a lot of you
00:55:17
probably use scorecards and you do
00:55:19
waiting so you say well this one's
00:55:21
weighted higher than this one well go
00:55:23
ahead and do that but if you don't care
00:55:25
about it wait it at zero
00:55:28
and then count it up because it has no
00:55:30
bearing for our context
00:55:33
so that watch out for this kind of of of
00:55:35
problem okay here's another Pro tip
00:55:40
but this one's hard
00:55:43
try to avoid not try to avoid there is
00:55:46
no try it's do or not do
00:55:49
avoid over evangelizing any particular
00:55:52
technology framework solution something
00:55:56
you found
00:55:58
we get all excited about something oh I
00:56:02
found I found grpc Google's remote
00:56:05
procedure call
00:56:06
it's the best thing I've ever seen I
00:56:08
could get 10 times more than 10 times
00:56:11
better performance in our system our
00:56:13
system's too slow I found the solution
00:56:15
grpc oh 10 times performance increase it
00:56:19
is it's wonderful it's exciting it's
00:56:21
great
00:56:22
try to avoid that
00:56:25
why
00:56:26
because of the first law of software
00:56:29
architecture everything in software
00:56:31
architecture
00:56:32
is a trade-off
00:56:34
and the problem is
00:56:36
you all get very excited about it and
00:56:38
what have I just done by evangelizing
00:56:42
I have just hidden
00:56:44
all of the trade-offs
00:56:46
and they're there
00:56:48
no one's finds them no one sees them no
00:56:51
one knows they're there because we're
00:56:52
all excited because I evangelized
00:56:54
something I got excited about it I made
00:56:56
you excited about it
00:56:58
this is a very dangerous thing you know
00:57:02
why architects
00:57:04
are always grumpy
00:57:05
they always have a frown they're always
00:57:08
walking around like this
00:57:10
because we can't get excited about
00:57:12
anything
00:57:13
because everything has a trade-off it's
00:57:15
a very depressing place to be yes oh
00:57:20
all right
00:57:21
um
00:57:22
so that everyone is architectural
00:57:24
thinking that's seeing things with an
00:57:28
architect's eye an architect's point of
00:57:30
view which will help you start
00:57:33
accelerating your career
00:57:35
into kind of that architect position
00:57:37
because you're already acting the role
00:57:40
you're already doing it
00:57:42
get the practice now
00:57:44
before all of a sudden you get handed
00:57:47
the golden keys of architecture and say
00:57:50
I'm not sure what I'm supposed to be
00:57:52
doing here and now I'm way over my head
00:57:55
practice it now but even if that's not
00:57:58
your career aspiration
00:58:00
maybe you want to know what we stay a
00:58:01
developer that's cool too
00:58:03
but now using this stuff you can create
00:58:06
more effective
00:58:07
and more efficient
00:58:09
and more correct
00:58:11
software Solutions as a developer
00:58:16
all right wonderful well thank you all
00:58:19
so much
00:58:20
thank you
00:58:20
[Music]