00:00:01
[Music]
00:00:08
systems are nominal initialize Genesis
00:00:12
sequence well welcome back I have a
00:00:15
feeling we've seen each other before so
00:00:18
um thank you for sticking it out for the
00:00:20
evening sessions where I want to talk a
00:00:23
little bit about what it means to be an
00:00:26
architect Architects are a sort of funny
00:00:28
animals right so some people who believe
00:00:31
Architects are sort of the most
00:00:32
important people make all the decisions
00:00:35
usually a little bit more gray hair the
00:00:37
the WIS this folks and then likewise
00:00:39
there's other folks that say hey it's
00:00:41
just you know people up in the Ivory
00:00:42
Tower drawing pictures and not adding
00:00:46
much value and the other part is you
00:00:48
know some people have Architects on
00:00:50
their business card but you many of them
00:00:52
I wouldn't consider good Architects and
00:00:55
vice versa some of the best Architects
00:00:57
I've met are not actually called
00:00:59
architect by title so we should think
00:01:01
about this okay what is with this
00:01:04
architect thing because we already talk
00:01:07
about what is architecture and there's
00:01:09
many different versions of what
00:01:12
architecture is and so of the easy
00:01:13
answer is Architects are the ones doing
00:01:16
architecture but then we on the wiser if
00:01:18
that is hard to Define so my pitch today
00:01:22
is that it is not what's on your
00:01:24
business card is not what your title is
00:01:26
It's not what you sort of think you is
00:01:28
but architect is really really much more
00:01:30
of a state of mind it's a sort of way of
00:01:34
thinking or a way of looking at things
00:01:38
and to sort of undo this whole notion of
00:01:40
The Architects being the ones who like
00:01:43
you know somehow smarter wiser should be
00:01:46
making all the decisions my opening
00:01:50
statement is really that the Architects
00:01:53
are not meant to be the smartest people
00:01:55
in the room right how can it be that one
00:01:58
person is sort of smarter than the
00:02:00
others even if they are little bit more
00:02:02
removed from the projects to make
00:02:04
matters worse right and then they're
00:02:06
somehow supposed to make all the
00:02:07
decisions right seems a rather silly
00:02:10
idea but Architects can do one thing and
00:02:12
that is make everybody else a little bit
00:02:16
smarter explore more options expand the
00:02:18
solution space improve decision
00:02:21
discipline help people see things that
00:02:22
they maybe didn't see before help them
00:02:25
not fall into the same pitfalls that
00:02:27
other people have fallen into so that
00:02:29
way I think Architects actually add more
00:02:32
value because they scale they contribute
00:02:35
to the team as a whole and end up being
00:02:38
an IQ booster for the entire team and
00:02:42
what I want to share a little bit about
00:02:44
today is well how do you do this how do
00:02:47
you become an IQ booster for your teams
00:02:50
and make everyone a little bit smarter
00:02:53
and I go through a list of ways that I
00:02:56
think this can be done I don't claim
00:02:57
it's like a a comprehensive precise list
00:03:00
precise list but these are things that
00:03:03
I've seen work throughout my career so
00:03:05
consider it a toolbox a set of ideas
00:03:08
right give it a try it may work for you
00:03:11
and you might and likely will find new
00:03:13
ones and that would be fantastic so the
00:03:17
first one that Architects do or the
00:03:20
first way Architects make everybody else
00:03:23
smarter is by connecting levels and an
00:03:26
easy way to look at this is to ask the
00:03:28
question Now who is the most valuable
00:03:31
architect so I worked for a large
00:03:33
insurance company some years ago and I
00:03:35
had the great title of Chief Architect
00:03:38
right so it's like oh that must be the
00:03:40
most important architect right it's
00:03:42
almost like the guy in The Matrix right
00:03:44
it's like the Chief Architect on the
00:03:46
other hand if that Chief Architect
00:03:48
doesn't do much but just draw pictures
00:03:50
which have little connection to reality
00:03:54
they don't really add a lot of value and
00:03:56
likewise if you're fantastic developer
00:03:58
and you write the most am implementation
00:04:00
of a certain algorithm but it's actually
00:04:03
not connecting what the business needs
00:04:05
right then in the end you also have very
00:04:08
little impact so my point of view is
00:04:11
that it's not really which level you're
00:04:13
operating at but it's much more about
00:04:16
how many different levels can you spend
00:04:20
because you will find many folks who are
00:04:22
good at a certain level and that's great
00:04:25
but being able to connect through these
00:04:27
different levels making sure you know
00:04:29
your te technology choices your
00:04:30
implementations your it strategy all
00:04:33
those kind of things relate back to the
00:04:35
business strategy being able to share
00:04:38
tradeoffs and decisions with business
00:04:41
people or Executives right the folks who
00:04:43
never quite understand what we do right
00:04:46
we quite honestly also don't make it
00:04:48
quite easy for them to understand
00:04:50
because we use funny words and languages
00:04:54
making this connection is extremely
00:04:58
important and value valuable and what I
00:05:00
find is then also there aren't so many
00:05:03
people around who can do this so
00:05:06
immediately this sets you apart my
00:05:09
experience there is right if you're able
00:05:11
to talk and make sense across the
00:05:14
different levels the audience will
00:05:16
actually be quite appreciative they tend
00:05:18
to say like oh finally somebody who
00:05:20
makes sense and understands what's going
00:05:22
on in the engine room but they're easy
00:05:24
to talk to and they don't dumb things
00:05:27
down right because you know up at the
00:05:29
leadership level you have some of the
00:05:31
smartest people in the organization when
00:05:33
you talk to Executives so the worst
00:05:35
thing you can do is dumb things down but
00:05:37
you need to translate them in a way that
00:05:40
is relatable to them and they can
00:05:42
understand the decisions and the
00:05:43
trade-offs that we're making because
00:05:46
those decisions and tradeoffs might
00:05:48
Define the future success of the
00:05:50
business right on one hand that is great
00:05:52
that means we as developers we're not
00:05:54
sitting in the basement somewhere doing
00:05:56
random things right what we do has a
00:05:58
direct impact on the business business
00:06:00
but it also gives us a lot of
00:06:02
responsibility and accountability right
00:06:03
we got to make sure that we actually do
00:06:07
things that go into the direction that
00:06:10
it links to the business strategy and
00:06:13
supports the business so the reason this
00:06:16
connection is so important is because
00:06:18
organizations are usually layered right
00:06:21
there are different layers of management
00:06:24
different kind of
00:06:25
specializations and the problem that
00:06:27
leads to is that upper management lives
00:06:30
in a happy illusion right they heard
00:06:32
you're using kubernetes and blockchain
00:06:33
and llm so it must be doing a
00:06:36
fantastically good job and vice versa
00:06:39
you know folks uh folks who wrri in code
00:06:41
enjoy their freedom because let's be
00:06:43
honest you know the management chain
00:06:45
doesn't know so exactly what you do so
00:06:47
you have a lot of choice now how is this
00:06:50
possible well this's is isolation layer
00:06:53
in middle management that forms this
00:06:56
Loosely coupled architecture in this
00:06:59
case is not a good thing this is Loosely
00:07:01
coupled because if the two things are
00:07:03
disconnected right you have the point
00:07:06
where the things we do don't add value
00:07:09
and the strategy we don't actually
00:07:11
understand or even know so both
00:07:12
directions this doesn't work so the idea
00:07:16
of Architects connecting levels is very
00:07:19
much fix this problem and as Architects
00:07:22
we like models so I want to explain how
00:07:25
this came about using a model even in
00:07:29
the keynote I joked a little bit about
00:07:31
Architects see more than other folks so
00:07:34
here are the proverbial four boxes and
00:07:37
three lines and some people might say
00:07:39
okay how interesting can this be while
00:07:42
in reality this can be very interesting
00:07:45
to architect so why do we do layering
00:07:47
it's one of the most fundamental
00:07:49
patterns we use all the time right we
00:07:51
have like front ends and back ends and
00:07:53
different layers different abstractions
00:07:55
right because it gives us a lot of
00:07:58
benefits of there we go oh my clicker
00:08:01
here so it gives us a lot of benefits
00:08:03
right so one thing does one thing well
00:08:05
one box does one thing we have
00:08:07
separation of concerns separation of
00:08:09
responsibility we have clean interfaces
00:08:12
we have clean uh dependencies and that
00:08:15
affords us some nice stuff like
00:08:17
replaceability it's easy to take one
00:08:19
piece out if you have clean dependency
00:08:22
so many benefits to be had but
00:08:25
Architects are in the business of making
00:08:27
tradeoffs where there's light there's
00:08:29
shadow where there's a plus there's also
00:08:32
a minus layers can also lead to overhead
00:08:36
right and we see this in Technical
00:08:38
Systems I've seen this where sort of
00:08:40
every layer talks to the other layer
00:08:42
with XML and then the whole system
00:08:44
doesn't do much except you're parsing
00:08:45
XML and doing garbage collection right
00:08:48
so there are certain overhead yeah seen
00:08:50
this real life it was an architecture
00:08:52
decision to use to require XML between
00:08:54
all layers right there you go right so
00:08:57
it can introduce latency it can bring
00:08:59
its own complexity if you have 20
00:09:01
different layers people start arguing
00:09:02
which layer something belongs into and
00:09:05
the last one you know well is so let's
00:09:07
say you have a system where you have a
00:09:08
front end a backend FR for front end a
00:09:11
business logic layer API layer object
00:09:13
relational mapping layer and a
00:09:15
persistance layer and you want to add a
00:09:17
field to the screen so what you do you
00:09:20
add the field to the front end the back
00:09:21
end for front end the business logic
00:09:23
layer you know the API layer the object
00:09:25
relational mapping layer and the
00:09:26
persistance layer so you have change
00:09:28
propagation through these layers that is
00:09:31
not great so well classic pattern some
00:09:34
Goods some bads now the way Architects
00:09:37
see more is the things on the left are
00:09:40
different than the things on the right
00:09:43
so if you squint a little bit sort of
00:09:44
the ink plot kind of test if you look
00:09:46
very carefully they're not out of the
00:09:49
same mold in a way and somebody once
00:09:52
made the gave me the answer says oh the
00:09:54
left is the theory and the right is the
00:09:56
reality and that was a very clever way
00:09:58
of putting it right it's like hey the
00:10:00
left is Powerpoint and the right is sort
00:10:02
of the runtime how this actually comes
00:10:04
to haunt you so what happens is and
00:10:06
there was a clever way of putting it the
00:10:08
more sort of architectural way of saying
00:10:10
it is the left is largely structural
00:10:14
these are structural consideration
00:10:16
separations interfaces dependency it's
00:10:19
more static right and that is good but
00:10:22
the right hand side is much more Dynamic
00:10:25
operational and that gives us a hint
00:10:28
that the more change you have in the
00:10:30
system so the more the dynamic Parts
00:10:33
play a role the things on the right hand
00:10:35
side start to outweigh the benefits on
00:10:38
the left hand side so if you have a slow
00:10:40
changing system the left hand side wins
00:10:43
if you have a right if fast changing
00:10:45
system the right hand side ways you it
00:10:47
starts to drag things down so this leads
00:10:50
us to some interesting um insights the
00:10:53
one thing is organizations have so many
00:10:56
layers because they used to benefit and
00:10:58
now we live in the world full of
00:10:59
uncertainty and change so now they're
00:11:02
suffering from this and you they cannot
00:11:04
easily collapse layer so hence the
00:11:06
architect elevator second Insight we're
00:11:09
gaining is much of what I just talked
00:11:11
about almost everything I just mentioned
00:11:14
doesn't really have anything to do with
00:11:16
a technical system or an organizational
00:11:20
system right we kind of flip back and
00:11:22
forth between the different domains take
00:11:24
replaceability right in an
00:11:26
organizational system that is called
00:11:28
Outsource say I can take some Department
00:11:30
out and give it to somebody else so what
00:11:33
we learn here is that organizational
00:11:36
systems and Technical Systems actually
00:11:38
behave similarly and that is very
00:11:41
interesting for you guys as as it as
00:11:43
technology Architects you know a lot
00:11:46
more about organizational architecture
00:11:48
than you might realize give you a simple
00:11:51
example right trying to build a highr
00:11:53
put system I think I joked about this in
00:11:54
a deep dive is you when you try to build
00:11:57
a high throughput system the worst thing
00:11:59
you can do is have a synchronization
00:12:00
point right because stuff Waits and
00:12:02
synchronizes so that is a throughput
00:12:04
killer in organization that is called
00:12:08
meeting and it's also a throughput
00:12:10
killer right so it's exactly the same
00:12:13
and that is very helpful because in the
00:12:14
end you do need to understand
00:12:17
organizations right if you want to do
00:12:18
things like devops and alile ways of
00:12:21
working and all these kind of things
00:12:22
that we do you do need this knowledge
00:12:25
about organizations but you're already
00:12:27
extremely well equipped about it and
00:12:30
that's the idea of the architect
00:12:32
elevator you can't collapse the
00:12:33
skyscraper into a bungalow so the next
00:12:35
best thing is you can write the elevator
00:12:38
the key thing is not telling each level
00:12:41
what they want to hear or making up
00:12:42
different stories but actually finding
00:12:45
ways to connect the message across the
00:12:48
different layers and here's a perfect
00:12:50
example of this long time ago I blocked
00:12:52
about this where let's say you have a
00:12:55
conversation between you know folks in
00:12:57
the engine room and they like things on
00:12:59
the left hand side they say hey here's
00:13:01
all the cool stuff my sort of digital
00:13:03
new way of building software right I
00:13:06
have high levels of automation I'm fast
00:13:09
I release frequently and I have tight
00:13:11
feedback loops right like fantastic
00:13:13
stuff that's what we all like then a CIO
00:13:16
will say okay that sounds really nice
00:13:19
but to be honest when I talk to my boss
00:13:21
right probably the CEO the member of the
00:13:23
board someone right they have different
00:13:26
things for me right they say hey make
00:13:28
sure this stuff is is secure nobody
00:13:30
wants to be in the newspaper make sure
00:13:32
it runs nobody wants to pay for it
00:13:34
that's not running and if you can spend
00:13:36
less money that is even better and then
00:13:39
they could argue for a long time so the
00:13:41
architect elevator is about not saying
00:13:44
different things on different levels but
00:13:45
showing people how they actually connect
00:13:49
right so how do you get a good security
00:13:51
posture by doing things manually heck no
00:13:54
right high levels of automation make
00:13:56
sure you have consistent patching levels
00:13:58
also so never assume everything is in
00:14:00
good order unless you actually have
00:14:02
observability and feedback and you do
00:14:05
this quickly what is the best way to get
00:14:08
high availability at low cost it's not
00:14:10
by doing warm standbys right that's the
00:14:13
silliest way but you do it by having
00:14:16
Automation and feedback Cycles Auto
00:14:18
scaling up Auto scaling down so the
00:14:21
things on the left are exactly what
00:14:24
makes the things on the right possible
00:14:26
and that is the architect elevator that
00:14:28
you show people look there is a
00:14:30
connection here this all makes sense and
00:14:32
you can have this conversation across
00:14:35
many different levels in the
00:14:37
organization these models are very
00:14:39
powerful and yes it's about connecting
00:14:41
the dots not telling entirely different
00:14:44
stories so metaphors and models help you
00:14:47
get this vertical mobility to make sense
00:14:50
to Executives right you're talking to
00:14:53
very smart people so not inviting them
00:14:55
into the thought process is actually a
00:14:58
very bad thing because it frustrates
00:15:00
them you you have smart people there who
00:15:02
basically you talk mumbo jumbo they
00:15:04
can't really think with you and it's
00:15:06
underutilizing resources of your
00:15:08
organization right you have some of the
00:15:09
most accomplished people in the
00:15:11
organization right and they can think
00:15:13
with you that in a way is a waste and I
00:15:17
always remind people when you go to
00:15:19
upper management and you say hey I have
00:15:21
this fantastic IDE idea and you talk
00:15:24
like you know kubernetes hem charts
00:15:26
serus
00:15:27
containers and then you say okay $3
00:15:30
million I need funding basically what
00:15:33
the other side is hearing is trust me
00:15:36
right it's like because they have no
00:15:37
idea really and they may still trust you
00:15:39
but it's a thin a very thin layer of ice
00:15:42
that you're walking on so give them more
00:15:45
insight share your tradeoffs the
00:15:47
decisions your thoughts and a powerful
00:15:50
way to do that is through metaphors and
00:15:52
you'll see this throughout my talks now
00:15:56
sometimes Architects are made fun of for
00:15:58
draw drawing pictures I actually think
00:16:01
drawing pictures is very important for
00:16:04
Architects and we'll see more of this
00:16:06
because pictures are models the
00:16:07
abstractions is the best tool you have
00:16:10
to tackle complexity so pictures are
00:16:12
really good but when you think about the
00:16:14
kind of pictures that IT architects
00:16:16
would draw you know this kind of stuff
00:16:18
comes up I this just like an internet
00:16:20
search right what is an IT architecture
00:16:22
diagram it's all these boxes kind of
00:16:25
things now having you know comparisons
00:16:28
between ITR Architects or software
00:16:29
Architects and building Architects is
00:16:31
always a slippery slope but I think in
00:16:34
this case we can learn something and
00:16:36
what we learn is that famous building
00:16:39
Architects are not drawing the
00:16:41
blueprints right there's engineers and
00:16:42
many other people the blueprints are
00:16:44
very valuable needs to be done but
00:16:46
there's other people doing this the
00:16:48
famous Architects they sketch and the
00:16:51
first reaction you might have is like oh
00:16:53
I could have drawn this or my
00:16:55
three-year-old could have drawn this or
00:16:56
my cat maybe could have drawn this but
00:16:58
the answer is no they probably could not
00:17:01
have because the sketches capture the
00:17:04
essence of what is going to be done the
00:17:08
the ultimate form of abstraction like
00:17:11
you need to understand the context you
00:17:12
need to understand the purpose of the
00:17:14
thing that you're building you
00:17:16
understand the site that is here the
00:17:17
materials there's actually a lot more in
00:17:20
there than it might seem sketches are
00:17:23
very powerful in a way drawing a
00:17:26
blueprint is very mechanical like you
00:17:28
know most many people can do that making
00:17:31
a good sketch is actually much harder
00:17:34
and is the signature of a good architect
00:17:36
and if you're worried that this has
00:17:38
nothing to do with reality if I had a
00:17:40
little bit better Photoshop skills right
00:17:41
I can probably get this to match up that
00:17:44
what was actually built in the end um
00:17:47
actually looks very much like this this
00:17:49
is the ghai museum in Bilbo Spain so as
00:17:53
Architects we want to be good at drawing
00:17:57
but with a focus on sketches capturing
00:18:00
the essence not making these big
00:18:02
tapestries but making something that
00:18:05
really expresses what we do very related
00:18:08
to this is I keep saying Architects see
00:18:11
more than other people and I mean this
00:18:14
in a positive way I don't mean you other
00:18:16
people are not as clever it's just like
00:18:17
sort of a different way of looking at
00:18:20
things right and part of that is seeing
00:18:22
more dimensions and my favorite sketch
00:18:24
for this is this where you have two
00:18:26
people arguing with each other and one
00:18:29
person says oh this is obviously a
00:18:31
circle and the other person says this is
00:18:33
obviously a rectangle and they go back
00:18:35
and forth and back and forth this is a
00:18:38
little bit like I mentioned in the
00:18:39
keynote when one person says hey we need
00:18:41
to speed up the project timeline and the
00:18:43
other person says oh but we can't
00:18:45
compromise the quality right they assume
00:18:47
these are like two different things and
00:18:49
as an architect you can say hey look
00:18:51
this is actually a cylinder this is like
00:18:53
three dimensions you can speed up the
00:18:56
timeline and still me your quality bars
00:18:58
for example example by having automated
00:19:00
testing more frequent releases having
00:19:02
the testers more integrated with the de
00:19:03
team whatever it may be you see more
00:19:06
dimensions in the solution space you're
00:19:08
not stuck on this you know Circle versus
00:19:11
rectangle discussion and that is
00:19:13
extremely helpful it gets people out of
00:19:16
this rut and I'm sure many of you have
00:19:18
seen these kind of debates where it's
00:19:20
like back and forth and back and forth
00:19:22
and you can step in you don't tell them
00:19:23
what the answer is but you show them
00:19:25
that there's more dimensions and that
00:19:27
way they can come to a good answer
00:19:30
you're expanding so that the big way of
00:19:32
saying is you're expanding the Sol the
00:19:34
available solution space for them so
00:19:37
that they can come to a better solution
00:19:39
and that is one way you make them
00:19:42
smarter right one way I do this an
00:19:44
example I I often use used to work for
00:19:46
AWS and my proudest achievement at AWS
00:19:49
was that I got to give a talk at
00:19:51
reinvent that has the word lock in in
00:19:53
the title not easy to do for a cloud
00:19:55
vendor right is their least favorite
00:19:57
topic so somehow I was able to sneak
00:19:59
this in and one way I showed that we see
00:20:02
more Dimensions when we talk about lock
00:20:04
in we talk about switching cost right if
00:20:07
I need to go somewhere else how
00:20:09
expensive is that going to be but that
00:20:11
is only one dimension the other
00:20:14
dimension is how much benefit do I
00:20:16
actually get right and immediately
00:20:18
you're having a more interesting
00:20:20
discussion you talk about R am I getting
00:20:23
commensurate value for higher switching
00:20:24
cost or not obviously having high
00:20:27
switching cost for low value makes no
00:20:28
sense right the cell phone cell phone
00:20:30
providers used to do that where you
00:20:33
couldn't take your number to another
00:20:35
provider right they were artificially
00:20:36
locking you in even though you weren't
00:20:38
getting much value the regulator stepped
00:20:40
in and we got number portability the
00:20:42
interesting ones on the right hand side
00:20:44
accepted locking right am I willing to
00:20:46
accept a higher switching cost for more
00:20:49
value old friend of mine Adrian kov many
00:20:52
of you probably know you from from from
00:20:54
Netflix and also from AWS he had a very
00:20:57
nice way to explain the the top right
00:20:59
quadrum he would go to the audience and
00:21:01
say who here is worried about looking
00:21:04
well the hands go up of course right you
00:21:06
should think about lockin and then he
00:21:07
says well who here is married and then
00:21:11
everybody looks at the hand and was like
00:21:12
well yeah kind of worked out not so bad
00:21:15
right so in the end there are benefits
00:21:17
to long-term relationships right think
00:21:20
about it along to Dimensions so those
00:21:23
are simple examples where suddenly you
00:21:25
get a different kind of conversation you
00:21:28
get out of this fud of like oh we can't
00:21:31
be locked in the vendor is locking Us in
00:21:33
it's like no it's switching cost it's
00:21:35
just money you know money isn't free but
00:21:38
there's a bank right we can think about
00:21:40
it we can think about how much value we
00:21:42
get against it and it's a simple
00:21:44
economic decision right there is no no
00:21:47
fuzziness here no funniness no fud
00:21:49
nobody goes to jail by being locked up
00:21:51
as an architect you made everybody else
00:21:54
a little bit smarter and to take this
00:21:56
even further right the the dimension of
00:21:59
switching cost itself which is just one
00:22:01
of the two Dimensions we shown that
00:22:03
alone breaks down into many different
00:22:05
dimensions right I wrote about this in
00:22:07
Cloud strategy right this could be we
00:22:10
normally think about the switching cost
00:22:12
of switching a vendor but switching a
00:22:14
product also cost even switching a
00:22:16
product that you build yourself is not
00:22:19
free so one funny example I like to site
00:22:22
is I always jok that the least favorite
00:22:25
um feature at AWS was the extend ended
00:22:28
version support on eks right the
00:22:31
kubernetes elastic kubernetes service
00:22:33
right why would you need extended
00:22:36
version support why isn't everybody on
00:22:39
the latest version of kubernetes and we
00:22:41
charge people for it ads make you pay if
00:22:43
you want the old version you pay extra
00:22:46
the answer is very simple switching cost
00:22:49
even going from one version to another
00:22:51
of an open source project is not free
00:22:54
you have other things to do there's
00:22:56
opportunity cost you might need to test
00:22:59
you might have many of those clusters
00:23:00
I've seen people with 200 eks clusters
00:23:03
right so there you have it right you
00:23:05
have switching cost you have Lo in into
00:23:08
a specific version of an open-source
00:23:11
product so that gives you a much
00:23:13
different way to think about this
00:23:15
doesn't mean lockin isn't real right of
00:23:17
course it costs money but it gives you a
00:23:19
different way to have this conversation
00:23:22
and that way you made everybody a little
00:23:24
bit smarter you get out of this this fud
00:23:27
Factor
00:23:28
now here comes an interesting one
00:23:30
Architects sell options and this came
00:23:32
out of a conversation I just had with
00:23:34
top level Executives people who reported
00:23:36
to the CEO of one of the largest global
00:23:39
insurance companies that very fancy
00:23:42
offices and they asked somebody what do
00:23:44
Architects do and people came with this
00:23:46
usual like the components and
00:23:48
relationships and decisions and this was
00:23:50
the head of former head of asset
00:23:52
management right insurance and I can see
00:23:54
his eyes glaze over and sort of in the
00:23:57
spur of the moment I said we sell
00:23:59
options and immediately the person like
00:24:01
oh what do you mean because that is
00:24:05
something that they can relate to right
00:24:07
they're Financial people so they know
00:24:08
options trading very well so what I
00:24:11
explained and I hinted at this on the
00:24:13
keynote a tiny bit is as Architects we
00:24:15
can give you options options are things
00:24:18
that you can do but you don't have to
00:24:21
options defer decisions into the future
00:24:24
so for example as an architect I can
00:24:27
give you the option to add or remove
00:24:29
Hardware capacity later right and by
00:24:32
that I defer the capacity decision from
00:24:34
right now where I would have to make a
00:24:36
wild guas I can defer that decision into
00:24:39
the future and that is valuable because
00:24:41
in the future I am smarter it becomes
00:24:44
much easier to make a decision in the
00:24:45
future because I'm no longer guessing
00:24:47
the future is right there so deferring
00:24:50
decisions has value and I can do this
00:24:53
with options so classic example that I
00:24:56
hinted about how do I get the op to
00:24:58
allow people to use different languages
00:25:01
the answer for us is very easy standard
00:25:03
interfaces standard apis so what I have
00:25:06
done here I have given up some options
00:25:09
right I can't have 15 different
00:25:11
protocols right I locked this down I
00:25:14
gave of one option I harmonized this
00:25:16
thing but in return I gained other
00:25:19
options and that's an interesting
00:25:21
architecture maneuver right I give up
00:25:22
some things I gain other things in
00:25:24
return so I should think about when is
00:25:27
this valuable am am I net net gaining or
00:25:30
am I net net losing very interesting
00:25:32
discussion right this is about
00:25:35
architecture decisions right this is
00:25:37
selling and I call this options trading
00:25:40
now I hinted at metaphors right when you
00:25:42
translate something into people's domain
00:25:45
if you bring technical decisions into
00:25:47
their domain they can immediately think
00:25:50
along with you and in this case my
00:25:53
conversation it went immediately here
00:25:57
now to fin IAL people this is horribly
00:26:00
obvious and this gives you a little bit
00:26:02
of appreciation how complex our domain
00:26:05
is right because when we talk technical
00:26:07
stuff to business Executives it looks
00:26:09
exactly what I'm doing to you right now
00:26:12
it's like isn't this utterly obvious and
00:26:14
many of you might think probably not so
00:26:17
much for financial people it is because
00:26:20
it's the black schs formula of options
00:26:22
pricing so when I told this gentleman
00:26:24
head of asset management that architect
00:26:27
sale option immediately came to the
00:26:29
conclusion that he said oh I like that
00:26:31
metaphor and I know that the higher the
00:26:34
level of volatility the higher the level
00:26:37
of uncertainty the more valuable the
00:26:40
option becomes that to them was
00:26:42
perfectly normal they know this stuff so
00:26:45
they're thinking along with you and for
00:26:48
you and that's extremely powerful it's
00:26:51
easy to understand plausibility let's
00:26:53
say with a scalability example right if
00:26:56
if I give you the option to add capacity
00:27:00
that option is more valuable if the load
00:27:03
is unknown right if I buil something for
00:27:05
10 users I don't need the option to add
00:27:08
capacity or remove capacity in the
00:27:10
future because that doesn't happen if
00:27:12
I'm building a mobile app or some
00:27:14
e-commerce or black Fridays or whatever
00:27:16
right something that is very volatile
00:27:18
that option is valuable right and that
00:27:21
holds in this metaphor it's a little
00:27:23
Sigma Square there right they got a
00:27:25
Nobel prize in economics for this Sigma
00:27:27
Square the volatility so with ra
00:27:31
increasing volatility the value of
00:27:33
options goes up and here comes the
00:27:35
kicker if architecture is selling
00:27:37
options that also means the value of
00:27:39
Architecture is going up and we do live
00:27:42
in a very fast moving very uncertain
00:27:44
world so the value of architecture goes
00:27:47
up two more quick comments here the one
00:27:50
thing is remember I said architect sell
00:27:53
options I didn't say we donate options
00:27:56
right I we say it creates options it
00:27:57
should we sell options we're not giving
00:27:59
them away how do people pay for options
00:28:02
and Brian actually this morning the
00:28:04
keyword again had the the the best word
00:28:06
for it we largely pay for it with
00:28:08
complexity and that is the real cost
00:28:10
right money can be had there's a bank
00:28:13
where we can get a loan there's no place
00:28:14
to deposit extra complexity you can't
00:28:17
get rid of it unless you invest more of
00:28:20
it so let's say this adding capacity
00:28:22
later right I need scale out I need a
00:28:24
load balancer I need automation right I
00:28:27
will have more moving parts to get the
00:28:30
option to add Hardware at will at any
00:28:33
time right it's you know the clout makes
00:28:34
this easier but fundamentally it's more
00:28:37
complex so you pay with complexity and
00:28:40
that's how you make this trade-off right
00:28:42
is it worth getting this option
00:28:44
volatility is high probably yes I pay
00:28:46
with complexity does does it not have to
00:28:48
change you probably I don't buy this
00:28:52
option second part that this leads to
00:28:54
very interestingly so what I just
00:28:56
basically told you is that the higher
00:28:58
level the level of uncertainty the
00:29:00
higher the level of volatility the more
00:29:03
valuable architecture becomes and we
00:29:06
have another word with starting with a
00:29:09
that we use a lot and that is the word
00:29:13
agile and often they're seen as at
00:29:16
opposites at of each other right
00:29:18
Architects are portray is these like
00:29:19
rigid bean counter kind of people with
00:29:21
all the rules and making the boxes all
00:29:24
exactly square and the agile people a
00:29:26
little bit more sort of Lucy goose right
00:29:28
living in the day kind of that's kind of
00:29:30
the this the kind of weird image we have
00:29:33
and they seem to be opposed to one
00:29:35
another right you will have some people
00:29:37
who come to you as an architect and they
00:29:39
will say hey I love what you're doing as
00:29:41
an architect this is really valuable but
00:29:43
you know I am agile so see you later
00:29:47
right I don't need you now here comes
00:29:49
the kicker why are people doing agile
00:29:52
methods if they knew everything and
00:29:54
nothing ever changes you don't need to
00:29:56
be very agile you write it all down you
00:29:58
cut it out you deploy it once you're
00:30:00
done so the reason we do Agile is
00:30:03
because we have volatility we have
00:30:05
uncertainty like hold on this is exactly
00:30:08
why we have architecture so both agility
00:30:12
and architecture thrive in environments
00:30:16
that deal with high levels of volatility
00:30:18
high levels of change and high levels of
00:30:21
uncertainty so they actually Thrive both
00:30:24
in the same environment there's
00:30:25
absolutely no cont ition here so that
00:30:29
nice thing is I sometimes say
00:30:31
architecture is the engine or the gas
00:30:33
pedal my car metaphors right and agile
00:30:35
is the steering wheel right the one
00:30:36
makes sure you keep moving and the other
00:30:38
one makes sure you're moving in the
00:30:39
right direction and both are needed to
00:30:42
actually get to the destination so yes a
00:30:45
little bit of laugh for architecture and
00:30:50
Agility one way that Architects tackle
00:30:53
complexity so complexity is the biggest
00:30:55
enemy in this thing in brain you I could
00:30:57
not have had a better segue than than
00:30:59
from Brian in the keynote complexity is
00:31:01
the problem so how do you tackle this
00:31:04
one way you do this is by zooming in and
00:31:07
zooming out right seeing things at
00:31:09
different layers of abstraction and our
00:31:11
world is not like sort of like a camera
00:31:13
zoom kind of thing it's much more like
00:31:15
these mandle broad sets right if you
00:31:17
look at things from different layers you
00:31:20
see very different things one of my
00:31:22
favorite examples is you know there was
00:31:25
this study of um um how much you can get
00:31:28
paid as an architect if you have a
00:31:29
certain Cloud certification right was a
00:31:31
different Cloud vendors professional
00:31:33
something rather certification you can
00:31:35
make this much money somebody who's a
00:31:37
developer will decide oh this cloud is
00:31:39
really good because I can get certified
00:31:41
in it and I get a higher salary the CIO
00:31:44
will look at they say hold on this Cloud
00:31:46
doesn't have enough qualified people so
00:31:48
I won't find folks to work on it and if
00:31:50
I find them they're very expensive so
00:31:53
probably this is not my favorite Cloud
00:31:55
so two people at two different levels to
00:31:58
the opposite conclusion from the same
00:32:00
piece of data and that's exactly this
00:32:03
they see different things at different
00:32:05
levels and understanding this right this
00:32:08
is the elevating action understanding
00:32:10
this makes you much more effective in
00:32:12
these kind of communications because you
00:32:15
can anticipate how other people at other
00:32:17
layers think but it's not just about the
00:32:20
organization layers it's also the system
00:32:23
as most applications we build today
00:32:26
they're distributed right they like
00:32:28
either distributed in themselves or they
00:32:30
call other apis or their SAS services or
00:32:33
they call cloud services right it's
00:32:35
extremely rare you will build anything
00:32:37
that lives in isolation yet most of the
00:32:41
time when we build systems we look at
00:32:43
the boxes and what's inside the boxes we
00:32:45
have a lot of tools and methods that
00:32:47
deal with the boxes but the lines are at
00:32:50
least equally important and the more
00:32:53
pieces you have the lines become more
00:32:56
important than the boxes so look at
00:32:58
these two very elaborate systems built
00:33:01
out of the components a b c and d and I
00:33:03
show you the right hand side has the
00:33:05
same components a b c and d there's no
00:33:07
trick here but it has different lines so
00:33:10
would you think that these two systems
00:33:12
have different characteristics that is a
00:33:15
trick question because the answer is
00:33:17
obviously yes right the left Lan
00:33:19
layering we already had right and this
00:33:21
sounds a little bit like you know I'm
00:33:23
belaboring the most simple architectural
00:33:25
thoughts but it leads to interesting
00:33:26
insights the is layering so it has all
00:33:29
the characteristics of layering easy to
00:33:31
replace a component but a little bit
00:33:33
higher latency from a to d and if B goes
00:33:36
down a no longer talks to D the right
00:33:39
hand side is exactly the opposite
00:33:40
shorter path less latency more
00:33:43
resilience if B goes out a still talks
00:33:45
to D but harder to replace because more
00:33:47
dependencies so long story short they
00:33:50
have exactly the opposite
00:33:51
characteristics built from the same
00:33:54
pieces so how you put things together
00:33:56
matters you need need to zoom out and
00:33:58
look at the system as a whole I often
00:34:01
say Architects are like shifts right
00:34:03
having good ingredients right buying
00:34:05
high quality AB Cs and D's is good but
00:34:08
the meal comes from putting it together
00:34:11
and that's what we as Architects do so
00:34:14
we need to see end to end a lot of folks
00:34:17
are optimizing locally and that makes
00:34:20
sense right that's like their realm of
00:34:22
responsibility that's what they control
00:34:24
that's probably what they get rewarded
00:34:26
by they make sure they build a really
00:34:27
nice a and somebody else builds a really
00:34:29
nice B they're looking at one thing at a
00:34:31
time so you need to balance this off as
00:34:34
an architect by looking at the system
00:34:36
end to end and make sure we are not
00:34:38
stuck in a local Optimum but actually
00:34:41
get much closer to a global Optimum
00:34:44
because what we learn here is the sum of
00:34:46
local Optima is rarely on never a global
00:34:50
Optimum you need to have both viewpoints
00:34:52
you look at one thing at a time but you
00:34:54
need to zoom out and look at the gestal
00:34:57
understand the system as a whole and
00:34:58
this could be the technical system or
00:35:00
even including the organizational system
00:35:02
right you need to understand the whole
00:35:04
thing because that really defines the
00:35:06
characteristics right that defines how
00:35:09
this system works if you want an example
00:35:11
out of operations right it's the classic
00:35:13
one all lights are green nothing is
00:35:16
working right each box is perfectly fine
00:35:18
but the system as a whole is not
00:35:20
functioning and anybody who spend time
00:35:22
in operations has been in that situation
00:35:25
everybody says hey my database is fine
00:35:27
my server is fine the front is fine
00:35:29
everything is fine but somehow is not
00:35:31
working so we need to zoom out and
00:35:34
understand that decision as all so I
00:35:36
want to get back to the pictures a
00:35:38
little bit I hinted that sketches are so
00:35:40
powerful because they are models models
00:35:44
are one of the best tools that
00:35:46
Architects have we have the metaphors
00:35:48
and we have the models and they actually
00:35:50
closely related so here are two models
00:35:56
of our solar system system and this is
00:35:59
sort of the days of Copernicus was like
00:36:00
the 1300s or 1400s I need to actually
00:36:03
look it up where basically the church
00:36:05
have the idea that hey the Earth must be
00:36:07
in the center of everything because
00:36:08
that's where we are right you know a
00:36:10
little bit self-centric it's called a
00:36:12
geocentric officially right you say hey
00:36:14
we must be in the center of things and
00:36:16
if you use that model the planets move
00:36:19
in relatively odd paths including some
00:36:22
surprisingly sharp turns if you use a
00:36:25
different model you know the helos
00:36:27
Centric model hey the sun is actually
00:36:29
the center of our solar system suddenly
00:36:32
everything makes sense so again that
00:36:35
leads to some very interesting insights
00:36:38
a both models are wrong right the sun
00:36:41
isn't this little yellow dot that's
00:36:43
that's on there and the planets don't
00:36:45
move actually in circles right it's much
00:36:47
more complex so it's not accurate in a
00:36:49
way but expresses the essence of what
00:36:52
we're after it helps us reason about
00:36:55
what we need to reason about that's why
00:36:57
we have the model we don't draw a onet
00:36:59
to one scale model of our solar system
00:37:01
right so in the essence it is it is
00:37:03
wrong the other thing is that what you
00:37:05
realize once you have the right model
00:37:09
the decision is sort of obvious like it
00:37:11
all makes sense it seems horribly simple
00:37:15
now that is a good lesson for Architects
00:37:17
I say once you choose the right model to
00:37:20
think about your system the answer is
00:37:22
obvious and this could seem a little bit
00:37:24
anti-climatic it's like oh it's so
00:37:27
obvious you you feel a little bit
00:37:28
unaccomplished almost right because it
00:37:30
should be harder but that means you
00:37:32
found the really good model to think
00:37:34
about your system because of the answer
00:37:36
just pops out and that is perfect right
00:37:39
there's always smart people who've made
00:37:41
nice quotes about this right all models
00:37:43
are wrong they're not reality right last
00:37:46
time I went on the hike I did not see
00:37:48
the contour lines on the mountain right
00:37:50
and the highways are not painted red and
00:37:52
orange but even you know George Bock you
00:37:54
know if you read the second part of the
00:37:56
quote is he said is the simple and
00:37:58
evocative models those are the most
00:38:01
helpful ones not the tapestries right
00:38:04
the more you can abstract away the more
00:38:06
you're getting out of the model you're
00:38:08
not trying to draw reality you're trying
00:38:10
to make a better decision so the more
00:38:12
abstraction you can have the simpler
00:38:14
model you can use the better you're
00:38:16
going to be at making that decision so
00:38:19
these tapestries look nice but they're
00:38:21
not actually the most useful models
00:38:24
because they're not really abstracting
00:38:27
much so here are four models of a system
00:38:31
that we know all fairly well that's
00:38:33
called planet Earth now the question is
00:38:36
which one of these models is the best
00:38:39
model now that is once again a trick
00:38:42
question because the best model depends
00:38:46
on the question you're trying to answer
00:38:48
so the topographical map on the left top
00:38:50
left that helps you decide quite a few
00:38:53
things you want to go for a hike but you
00:38:55
don't want to climb steam Hills you want
00:38:57
to build a ski resort so you do like Ste
00:38:59
pills um you're building a house and you
00:39:01
don't want it to be in the flood zone
00:39:02
very good you're building a dam you're
00:39:04
trying to see what actually gets flooded
00:39:06
and where to put the dam perfect map
00:39:08
right so the model can answer many many
00:39:11
questions the other models answer
00:39:13
different questions what's the fastest
00:39:14
way to get from A to B I always talk
00:39:17
about the top right one that is meant to
00:39:20
explain the US elections but I'm not
00:39:22
sure you even models have the
00:39:23
limitations right it's a it's a
00:39:26
political map right supposed to help you
00:39:28
understand things like elections and the
00:39:30
bottom right right used to work for
00:39:32
Amazon people who build distribution and
00:39:34
fulfillment centers they find these
00:39:36
population density Maps very very
00:39:38
helpful in combination with transport
00:39:41
Maps so the best model depends on the
00:39:43
question that you're looking to answer
00:39:45
right we're not in the modern art museum
00:39:47
we're not drawing these pictures because
00:39:48
they look you know for fun we draw
00:39:51
pictures so we can make better decisions
00:39:53
and answer questions so next time
00:39:56
somebody says show me your architecture
00:39:59
a very valid counter question is well
00:40:02
what question do you have in mind what
00:40:04
are you looking to answer because the
00:40:07
model right the architecture nobody sees
00:40:09
the real architecture they're going to
00:40:11
see a depiction of the architecture
00:40:13
right they're going to see a model of
00:40:14
this architecture and which model you
00:40:16
should show them really depends on the
00:40:18
question you have there is not one
00:40:20
universal there's not like a show me the
00:40:22
architecture it's like no what what are
00:40:25
you looking for what are you trying to
00:40:26
decide what you you're trying to
00:40:28
understand and based on that you can
00:40:30
select the best model so the model isn't
00:40:34
good or bad it is suitable to answer the
00:40:37
question you have it's suitable to help
00:40:39
you make a better decision so couple of
00:40:42
insights right these tapetes look
00:40:44
impressive but they're actually the
00:40:46
least useful model the only question
00:40:48
they usually answer is why does
00:40:50
everything take so long and why is it so
00:40:52
expensive but people kind of already
00:40:54
knew that so that is not adding a whole
00:40:56
lot right the other one I want to
00:40:58
highlight is sometimes people feel when
00:41:00
I have a lot of uncertainty have a lot
00:41:01
of moving Parts a lot of variables I
00:41:03
don't know how many users I'm going to
00:41:04
have and I don't know what the business
00:41:06
is going to do people feel like the
00:41:08
model cannot work because they feel like
00:41:10
I cannot capture this thing it's just
00:41:12
like too fluid that is actually when
00:41:15
models add the most value because they
00:41:18
force you to make assumptions you go
00:41:20
based on scenarios we have a low medium
00:41:23
high user scenario you can share this
00:41:25
with Executives say hey I evalue ated
00:41:27
this along three scenarios here's my
00:41:29
architecture for these three right which
00:41:31
one do you want do you think this is a
00:41:33
reasonable tradeoff so if you have more
00:41:36
uncertainty the model actually helps you
00:41:39
better because it gets you out of this
00:41:40
rut of like I don't know right it gets
00:41:42
you into rational thinking so so that's
00:41:45
when models really shine is when you
00:41:47
have high levels of uncertainty because
00:41:50
you it forces you to make assumption and
00:41:53
put some stakes in the ground and last
00:41:56
right a good model depends on on the
00:41:57
question you have or decision you need
00:41:59
to make we're not producing abstract
00:42:02
art so now we talked about Dimensions
00:42:05
right is all very visual we like
00:42:06
pictures models Dimensions the other one
00:42:08
is Shades of Gray right is our
00:42:11
processors are largely binary right and
00:42:14
our software maybe is binary the rest of
00:42:17
this world is not binary including most
00:42:19
of the architecture we're talking with
00:42:22
everything has Shades of Gray so I've
00:42:24
gone public by saying you can EAS
00:42:27
identify the worst Architects by the
00:42:30
people who always speak in absolutes oh
00:42:32
this must be like this everything must
00:42:34
be in a container everything must be
00:42:35
like this it can never be like that
00:42:37
right they go in these extremes that is
00:42:39
actually the signature of a not so good
00:42:42
architect and you know one thing I
00:42:44
learned on social media strong opinions
00:42:46
always get more likes so that is
00:42:48
pre-program still nevertheless this was
00:42:50
sort of my one of my most um successful
00:42:53
posts right it is not about spoing out
00:42:57
AB solutes it's about understanding
00:42:59
tradeoffs so I come back to this lockend
00:43:02
story because I wrote quite a bit about
00:43:04
it in the end the switching cost and
00:43:06
lock in is also a Continuum there's
00:43:10
amount of money that you can invest to
00:43:13
reduce the switching cost right that has
00:43:15
a certain cost and return the switching
00:43:18
cost goes down and what you're doing is
00:43:20
you minimizing the sum of those two
00:43:23
right what you invest right now and the
00:43:26
potential switch ing cost that you would
00:43:28
have multiplied by the likelihood that
00:43:30
you actually switch so basically the way
00:43:32
I explain this to people is you know
00:43:34
let's say that moving to another Cloud
00:43:36
just for argument sake would cost you a
00:43:39
million euros right because there a lot
00:43:41
of effort cost you a million bucks right
00:43:43
then you say okay I have a 5% chance
00:43:46
that this will happen in the foreseeable
00:43:48
time Horizon I say 5 years or whatever
00:43:50
eight years whatever sort of the
00:43:51
lifespan of the stuff is that you build
00:43:53
5% chance on do so that means you carry
00:43:56
a 50,000
00:43:57
liability again translating things into
00:43:59
money is kind of magical because it
00:44:01
takes all the F out now it's 50,000
00:44:04
right it's not like 10 billion and then
00:44:06
you say hey can I invest money to bring
00:44:08
this down from 50,000 to 10,000 by maybe
00:44:10
using managed op Source U being smart
00:44:13
about how I package my code like you
00:44:14
know things that I can do and yeah I can
00:44:17
do that doesn't cost me much and boom
00:44:18
this goes down great decision so it's a
00:44:21
spectrum like lockin is not a switch
00:44:23
it's not like same as coupling it's not
00:44:25
like things are like coupled and coupled
00:44:27
or locked in or unlocked right these are
00:44:29
all Spectrum these are shades are gray
00:44:32
and your job as an architect is you know
00:44:34
you you won't calculate the absolute
00:44:36
mathematical minimum but you have sort
00:44:38
of this this feeling that it's unlikely
00:44:41
that the best decision is on the far
00:44:43
ends it's rarely on the extrema so you
00:44:45
kind of sort of check where you are
00:44:47
basically on the right hand side of this
00:44:49
picture is being overinsurance
00:44:55
side is being naive right he like oh
00:44:58
whatever right so both of them are not
00:45:01
good so it's Shades of Gray is always a
00:45:04
a a spectrum and often the optimum
00:45:06
answer is in the middle if you follow
00:45:09
this you can even do more fun things
00:45:10
right the money you're investing right
00:45:12
now is more expensive than the return
00:45:15
you're getting in the future because
00:45:17
discounting rates inflation so you can
00:45:20
set a discount rate right if this cost
00:45:22
me $100,000 now that is more expensive
00:45:25
than getting $100,000 000 back in the
00:45:28
future if your startup company costing
00:45:30
you $100,000 right now may put you out
00:45:32
of business so you can take these models
00:45:35
much much deeper and you can see how
00:45:37
powerful is this is to get out of this
00:45:39
food now we can have a much deeper and
00:45:42
much more rational discussion about this
00:45:46
and that is one way as Architects you
00:45:49
make people smarter so quick recap right
00:45:52
what have we seen organizations are
00:45:53
layered because it used to work well for
00:45:55
them right it's easy to say oh they were
00:45:58
stupid they do things badly it's too
00:45:59
much overhead no no they're quite
00:46:01
successful right they got there there're
00:46:03
sometimes 150 years old or older like
00:46:06
many banks insurance company so it used
00:46:08
to work for them but now it's becoming a
00:46:10
hindrance it's not because they're Dumbo
00:46:12
anything it's just the environment has
00:46:14
changed so what do we do we help them by
00:46:17
connect the different levels we like
00:46:19
pictures but not the blueprints we like
00:46:22
sketches because they give better
00:46:23
abstraction more opinion like a better
00:46:26
viewpoint that you as an architect bring
00:46:29
getting people out of this a versus B by
00:46:31
showing more Dimensions very powerful
00:46:33
right you don't tell them what to do
00:46:35
right it's not about you answering all
00:46:37
the questions but you help them come to
00:46:40
a better answer options good for many
00:46:42
ways you defer decisions that is great
00:46:45
to do as an architect because in the
00:46:46
future you're always smarter but it's
00:46:49
also at the same time a useful metaphor
00:46:51
especially for folks in the financial
00:46:53
industry and it led us through the
00:46:54
inside that architecture and agile not
00:46:57
at all opposites we talked about zooming
00:46:59
in and zooming out and the model
00:47:01
basically we talked about all around
00:47:02
everything I showed is a model there is
00:47:05
no universally best model there is no
00:47:07
universally best architecture picture it
00:47:10
really depends on what question you're
00:47:12
looking to answer what decision you're
00:47:14
looking to make and yes you some things
00:47:16
in our field are binary but it's only
00:47:18
the very low level things nothing that
00:47:21
architecture deals with is binary it's
00:47:23
always a spectrum and often it's a
00:47:25
spectrum across different dimension and
00:47:28
that's what makes architecture fun right
00:47:30
it makes it challenging but it also
00:47:31
means right we we add a lot of value we
00:47:34
do an interesting job because we see
00:47:36
things in a slightly different way and
00:47:39
by doing that we make everybody else a
00:47:41
little bit smarter so again if you like
00:47:44
this kind of stuff this kind of way of
00:47:46
thinking this is largely what the
00:47:47
architect elevator is about and what I
00:47:50
have done is really use that way of
00:47:52
thinking when I wrote my other books so
00:47:55
basically I applied this way of
00:47:57
architecture thinking to different
00:47:58
domains right like Cloud platforms I'm
00:48:01
probably going to write something about
00:48:02
API and that again has helped me as an
00:48:05
architect sort of have the meta level
00:48:07
discussion right like what is does it
00:48:09
mean to think like an architect but at
00:48:11
the same time I can map that to the
00:48:14
specific domains and the specific
00:48:17
problems and with that I hope you got
00:48:19
some inspiration out of yeah I didn't
00:48:22
really tell you what an architect is and
00:48:24
that wasn't the purpose of the talk but
00:48:26
I hopefully convey to you that it's a
00:48:28
very interesting role to play and the
00:48:30
key thing you can do is you can be an IQ
00:48:33
amplifier you can make everybody else a
00:48:35
little bit smarter and I find that to be
00:48:38
a very fulfilling and important role so
00:48:41
please be happy Architects thank you
00:48:44
[Applause]
00:48:58
all systems are nominal initialize
00:49:00
Genesis sequence
