Thinking Like an Architect by Gregor Hohpe

Summary

Highlights

• Architects act as IQ amplifiers for their teams 🤓.
• Architectural thinking transcends job titles 💡.
• Effective architects connect different corporate layers 🏗️.
• Models and metaphors help make complex decisions manageable 🔍.
• Architecture creates options, aiding agility in uncertain environments 🌟.

Key Takeaways

• Architects boost IQ by creating a collaborative environment 🤓.
• Being an architect is a mindset, not just a title 💡.
• Connecting organizational layers prevents isolation and enhances decision-making 🏗️.
• Using models and metaphors simplifies complex decisions 🔍.
• Architecture and Agile can coexist effectively, both thrive in flexible environments 🌟.

Overview

Thinking Like an Architect by Gregor Hohpe Transcription

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