BTD12: The Architect Elevator: Connecting Penthouse and Engine - Gregor Hohpe

very good so with this introduction I'm not sure I have a lot more to say actually so I'll do my best thanks for for crowding in so we're gonna talk about architects and architecture and architecture it's a little bit of a strange animal right yes three different people what architecture is and you probably get at least three different answers and a lot of people will also say that architects also kind of special animals so when we as IT geeks think about architects and a first character that often comes to mind is this one right the

chief especially the chief architect right so this is the person who knows everything who makes all the decisions who has the ultimate authority there's one catch though and that is you know this architect is actually not a human being this architect is a computer program right because we know the matrix yeah this is part of the machines so this doesn't work extremely well there's another very strange architecture picture a picture figure that's made it into the movies and that is Anthony Royale of the very strange movie high-rise right and this is you know the ultimate

persona of having an ideal almost like an illusion that they're building and it goes totally absolutely awfully wrong and haywire so definitely some similarities here with some architects when people see me as architect though they think more about this guy right it's like the mad scientist and it has a little bit to do with the haircut it also has a little bit to do with the car I have forehead and I think a little bit of math science and architecture is actually actually fairly well placed so all jokes aside though I want to talk a

little bit more about what different view I have of what architecture and being an architect in a modern or large IT enterprise means and in order to do that we first need to understand what's actually going on in a large-scale modern IT so let's start with that right how does the role of IT fundamentally change first I have a tiny bit of a soapbox I need to get on and that is the word digital now we always talk about digital transformation digital disruption digital just giants digital revolutions right everything seems to be digital these these

days the catch with is actually then we made things digital like 30 years ago probably replaced letters with email we replace paper calculations with spreadsheets replace our watches with these funny things that never show the time unless you push a button right so those are the things we're done with making stuff digital right will replace the tape with the CD right we've been there we've done that so it's no longer about making more stuff digital it is actually about really understanding how we can use the digital technologies to fundamentally change the model this is can

be the model how we go to market the model how we make money the model how we interact with our customers so the digital world is a little bit of a misnomer we're not looking to make things digital anymore we're looking to change the model how we operate and think about our business thanks to digital capabilities a perfect example of that is here's a digital product very nice Microsoft Encarta you know it's a encyclopedia right and it was actually much better than any paper encyclopedia right it's like more content more up-to-date more search ability multimedia

stuff in there easier to carry right so better than any paper encyclopedia in all regards classic digital product now who uses Microsoft Encarta Oh interesting right I did use right that's a great product but somehow this came and went and of course the answer to what do we use instead is fairly obvious that is Wikipedia right and this is the difference between making something existing digital and changing the model right Wikipedia realized that with a global network and a global browsers and all these kind of capabilities you can fundamentally change what it means to be

an encyclopedia right it's no longer the people in lab coats like a few authorities that write down whatever they can but rather it becomes a collaborative model and this is a perfect example of making things digital versus changing the model thanks to digital capabilities now translating this into IT though we find that there's a lot of assumptions built in the current way IT operates because IT corporate IT also became big by making things digital yeah what did ite always do I D took an existing largely manual process yeah I've worked for an insurance organization for

a long time you have new customers you have risk calculations you have claims you have payouts right you have all these kind of processes that basically already existed and then I teammate them digital and they were faster and better and cheap and all these kind of things and to be honest I D has done pretty well for itself doing that where many large organizations have IT budgets and the billions of euros basically making things digital but as we already learned it's not about making existing things digital it's about changing the model there's a catch though

because the IT is so used to making things digital then they've work on a model where it's always an as is and a to be right and we call that a project right like we know where we are we want to be we make a business case right and up here is is something different that's not the project this is the giant sigh of relief because finally the project is over hold on my clicker my my ultimate weapon is failing me know what's happening ah there we go all right I'll try right this is the

big sigh of relief because finally we're back to normal and back to normal means there's no more change right we package the change ever so tightly into these projects with all the controls and steering committees and budget reviews like anything we can imagine and the big celebration is actually when the when the first user usually uses the product right we celebrate before actually anybody really uses it because we're done with change now the digital world as I might have hinted is working slightly differently because we're not making existing things digital we're looking to change the

model the question is of course what's the new model the short answer is well no one knows because we're innovating and then means we need to actually pair for an environment of constant change and as we see this this isn't this is not a play of words the left hand side basically assumes that normal is no change on the right hand side changes normal it's a constant change and it becomes hard make business cases because you don't have a clear to be state and that requires IT to work fundamentally different all right in the war

left hand side we were in the business of guessing well and guessing right and we're gonna build this thing we sort of anticipating a big return because you make something better and if you replace something existent that's actually kind of doable because you know what you're what you're aiming for on the right hand side it is not about being a good guest there on the right hand side it's about being a fast learner and again those two things are basically exactly the opposite of each other and I call the left hand side the economies of

scale because when you run this project the bigger you are the wider you can deploy the results generally the more returns you get on the right hand side its economies of speed because if you need to learn fast it's the faster you can move you're the better off you are now there's a very important nuance here as well and is is you will find that the people on the left-hand side speak in absolutes they're speaking budgets and timelines right it's gonna take six months they're gonna take that many million dollars the server's gonna cost 50

thousand euros they speak in absolutes the folks who are here if you're in constant movement if you're always changing absolutes are no longer than meaningful because the next second it's gonna be different so you realize that the folks on the right-hand side speak in relatives they speak and burn rate the speaking consumption and if you think about it why for example the cloud model is so successful is because the cloud model speaks that language right cloud is not moving service to another data center I mean Google and Amazon's data centers are pretty nice but they

didn't exactly invent the data center area data centers and servers everything before right so it's not about building another data center of what cloud really did is change the consumption model right it's not 50,000 euros for a server it's three dollars an hour and you realize that the folks on the right hand side who think in burn rates and consumptions because they live in constant change that for them the cloud model is a totally natural fit and making an upfront investment for them doesn't fit very well and that's why all organizations that are thinking in

the right hand-side model are essentially in the cloud because that's the way they grew up so I have a relatively long list you're not gonna read through this but the economies of scale versus economies of speed are basically diametrically opposed by the exact opposite of each other on the left-hand side you know what you're gonna do you can make a nice plan variance is unwelcome you're optimizing right and the right-hand side you are doing exactly the opposite you're experimenting you actually want disturbance you want variance you're testing hypothesis right failing is fine because it's learning

et cetera and here we think in rates and consumptions on the left-hand side we think in absolutes so that as contexts about how the role of an architect changes and how the role of IT changes the old IT that is basically automating existing things is important but important has two dimensions right important is how critical it is that it exists but also how much of a differentiate is it for your diffe business and the classic IT is important in a sense is like electricity right if the lights go out right now then I can a

little bit of a hassle we sit in the dark nobody likes that that's IT if you're glad is there but where the electricity comes from doesn't make a lot of difference where the IT comes from doesn't make a lot of difference so in the new model right if you're experimenting if your new business models you know come out of the IT then the IT becomes a differentiator the way I it explains this when I worked at on the ants I often said hey guys we had 127 years to find all business models that didn't depend

on technology and you know what we did a pretty good job at it so I'm pretty sure we found them all but if you use that logic right all new business models that are coming now are gonna be IT enabled right now the answer and other insurance companies know this very well and that means IT is a substantial differentiator for them so that's the context right digital world the so-called digital world not about making digital things but about changing the model fundamentally questioning sort of how the IT operates change is now normal as opposed to

abnormal and the role of IT becomes a differentiator as opposed to just being a parity or commodity so in this environment now our architects are living and I feel that the role of the architect in that environment also completely changes and what I see as the most important task of the modern architect is to be a connecting element and that's what the architect elevator is if you look at traditional organizations they just have a lot of different levels so Penn Towers up there then they're still sort of the upper management you know the upper middle

management the middle middle management the lower middle management the upper lower management and you know down here is the working student writing software right it's like the intern here the intern the intern doesn't have anybody to pass it on to so they actually write the software and at the end of the day that worked okay for them because yeah we know this model is kind of if there's a nice separation of concerns right so the CEO doesn't have to worry about where the intern is sitting writing the software down there which in turn it is

however if there's movement in the system like we already said right it's economies of speed all this layering leads to some issues right it takes time for things to travel and you have translation errors you get the telephone game right you know CEO says something by the time it ends up at the working student right it might be something completely different so if those things are out of whack basically nothing else can save it right the most efficient and the most well-run IT project isn't any good if it's not actually connected to the penthouse in

the business strategy so you need to get this connection right otherwise nothing else can save you can help you right so we need to connect the penthouse and the engine room and now we have to deal with many different layers and that means we need to look at technology but we also need a look at organizations interestingly what we find out is that complex technical systems don't behave all that different from complex organizational systems so architects have an edge there because they know how to deal with these systems and I'll give some examples now the

elevator doesn't imply telling every flow of what they want to hear and the story is completely different now that doesn't help either right that's called like charlatan I guess right that's not architect elevator so you need to share the same story but in a different way right you need to make it connect and translate it on the different levels but it's God I have the same basis you make up different stuff on different floors you know that doesn't make any kind of connection so what this looks like in reality what does an architect like this

do here's some examples right it starts with business and IT strategy as I said if those don't line up nothing else can help you you know you're always looking to make a change because you're really trying to get these organizations to be more digital faster moving angeline etc complexity is probably your biggest enemy in this right the IT stuff we have is complicated and complex so making that connection isn't easy so you need to be a good communicator you know secretly the architects will always like everybody else to know how complicated our stuff really is

because we want the other people to suffer a little bit with us all right well it happens right that doesn't work very well here right you go out and make it easy to understand you got to make it simple but not simplistic right and then down here in the engine room is also a lot of good stuff to do you know Christophe talked about resilient systems taking friction out lean agile kind of things yeah and keeping up with the technology so in the end I measure the value of an architect really by how many floors

can they cover all right so the more floors you can cover the more valuable you are in this context now somebody might say but don't why don't we flatten this building right the digital the so-called digital companies they busy live in a bungalow right they don't have all these layers all right so one idea would be why don't we just flatten this thing down a little bit and done done we don't need we don't need all this elevator it kind of stuff now the problem is if you take a high riser and blow it up

you don't get a bungalow you get a pile of rubble right so so that doesn't work so the next best thing you can do is be the connecting element because you're not gonna get rid of all those floors as easily sounds great but in reality there are some challenges there are some dangers of writing the elevator and that is because this has been working for decades like this the system has optimized itself in a certain state and that state can be described as follows management lives and an illusion well they think all the years we

have too late as docker kubernetes we go to the cloud they're using spark and flink and beam and whatever alright they he all these great kind of things out of the engine room and they've quite happy living in that illusion right no because sounds great right they never go they never actually look what it looks like right never open the hood meanwhile IT actually injures a fair amount of freedom because you know what all the middle management has no idea what they're doing anyway right so they actually do get to play with Apache beam and

fleeing its bark and all the other stuff right and nobody actually sort of expects a lot from it because you know there's no connection well how can this actually work while the answers we're easy there's like 12 levels of ignorance that's what makes the miracle function right they are see we call this decoupling all right it's one of those architectural trades something crystal spoke about right it's loosely coupled now in this case decoupling is not exactly what we want now yeah our freshly minted elevator architect comes in and says haha cape on right as I'm

just gonna zoom across these levels right from beginning to end now the problem is you can make all three parties equally unhappy right all right because you take the illusion right you take the freedom and well I don't know what you do with them but they're definitely not gonna be they're not gonna be happy right once you zoom out though right yeah so he gives them a real answer if you're a little bit mean right so but you can see that from a systemic perspective right you give them transparency that's actually a good thing but

they're not happy about losing the illusion initially right you give them some governance which is actually also helpful but initially they're not gonna be happy because they enjoy the freedom and I don't think these guys are gonna be very happy you know having getting every irrelevant shown because they need to really find their place what that tells us though is they're dealing bringing change into these complex systems is not an easy task right because they're locally optimized themselves into a state where once you bring a connection in there you make them all equally unhappy until

people can actually see that something better comes out and that's my change in transformation is actually so difficult to do that's the key role of the architect right if you want to change to be digital right that not we need to crack now what does that look like right what does one of those architects look like and I'm just gonna give a few glimpses right I have a whole book and website and other stuff so I'm gonna give a few glimpses of you know sort of what's going on with the architect up in the penthouse

so that the mid-levels and the the engine room one thing that architects can do in the penthouse is they can look at the organizational structure and actually understand the digital maturity of this organization based on the orc structure because they have their architectural thinking and apply this to organizations and one very interesting aspect is where does a CIO report in to because ultimately the IT rolls up into a chief information officer yeah it's not an easy job may also evil people always say it's called careers over but I don't like that too much right so

there's some jokes about the CIO titles but it's actually quite tough job right because it's obviously cheaper more digital innovative you know deliver faster they see no business has ever complained that the IT is too fast or too cheap right so lot of pressure now interestingly when I see an AI all reports to a chief financial officer that means that the far zoomed of view of the ite as a cost view right because what does a CFO largely care about right I see of all rights the checks or rather not right so because they need

to control the spend and the cost and that means the key vehicle the key lever you actually have is cost-cutting and if cost is the main metric the right thing to do yeah not the thing we like but the right thing to do is to outsource it right if it's cheaper done somewhere else and cost is your main metric then that is the logical right thing to do now the question is is that the right assumption right and you'll find that other organizations they have a chief operating officer I sometimes call them the chief optimization

officer right because they're gonna make sure that the other whole shop runs quite well and that is a big step forward right because here you're looking invest in the IT and gather River not return on investment the way to explain the difference is here you don't take your car to Illinois you change because it costs money here you very much do take your car to an oil change because the return on investment is extremely high so as a big step forward a big difference yan there's a lot of things about harmonizing rationalizing bringing the IT

centrally in the group getting more standards all these kind of things and that is to harvest the economies of scale right if you have too much fragmentation you don't get the economies of scale if you harmonize standardized rationalize you can do that it's a big step forward now interestingly on the on the right hand sides I get my my weapon here working let me see oh interesting is that what Christophe also complained about oops yeah exactly technically all right let's see how I get this back working so if you're looking at the right-hand side of

the equation it starts to look a little bit different so often we have a CDO which is sort of the CIOs ultra ego right a chief digital officer and it's a dangerous game right because they're supposed to be sort of the CIO then does the old IT in the CDO does the new IT and that leads to also very strange dynamics but it's often sort of an escape maneuver and often they bring people in-house and try to be more agile right so on the end they're trying to do good things as long as they don't

create a lot of conflict between the two and then ultimately you find enterprises where the IT is part of the board like any other function right they report to the CEO and that means that they don't see IP IT as like a sort of little thing machinery in the engine room but they CIT is an equal function to the other things to sales distribution product etc IT is an integral part of what they do and in the end they also take this big distinction between IT and business out right and you see quite a few

CIOs who actually do change reporting lines and it's almost always in the right hand side direction I know quite a few large enterprises I worked with where they used to be here and they moved here often times they also move here many organizations have a CEO etc so there's definitely movement in the system so a modern architect can understand these kind things right they're not random they're not sort of haphazard you know this is really a sign of how the organization ultimately thinks about the IT and as I said earlier if things are not lining

up up here then nothing else works right if you have folks who are only interested in cost and you try to sell them your continuous integration and coping ideas and spinnaker and all these kind of things right if you try to sell speed to somebody who cares about cost that is not gonna work right so if you want to write the architect elevator you can do one of two things or both I really do you need to adjust your message - based on where you are but at the same time you're also trying to change

the way people think you're trying to nudge people over but if you try to sell speed to people who care about cost then has the classic effect of the architect saying our management doesn't get it nobody listens to me right they don't understand yeah this is the classic complaints you're gonna get but in the end you're just trying to sell something they are not interested in and you can either make them interested in it or you can sell them something different otherwise you're gonna be complaining for an awful long time so this is one great

example about how architecture of thinking applies to businesses up in the penthouse I have another one and this is probably my most architectural slide all architects well this design it's a who said architecture is difficult right so go you know architecture always has boxes and lines we'll hear more about that later so this fulfills our definition of architecture it has boxes and lines and this is a very common pattern we know right in computer science and architecture this is called layering in fact many people say that computer science is the field where every problem can

be solved by one more layer of abstraction right so we like making layers and that's not because there's so much fun but because they're actually useful your layers separate concerns write the abstract details they make clear dependency our dependencies only flow one way so if I want to replace something it's easy to take a piece out and as easy to put another piece in the interfaces are well-defined so if I change the implementation behind it the interface doesn't have to change and the other parts don't have to change either a lot of great benefits now

if you think about it though these benefits of I to organisations just equally well right it's like separations of concerns right it's like I don't know all the financial tax codes right the finance department does that right there's a separation of concern what do we call replace ability outsourcing are we taking a layer out and replacing it with a different implementation trying to keep the interfaces intact that is a classic outsourcing and as most people know is if there's too many dependencies if there's too many lines going on that makes you outsourcing generally not work

terribly well so having clean dependencies and clean interfaces helps outsourcing so organizational and technically this is actually exactly the same and interestingly these are the reasons why large organizations live in the skyscrapers they did layering because these things work well for them themselves for them they have a giant organization to run so separating concerns and abstracting details you know they do like to outsource or replace or bring external sin right so they actually benefit enormous ly from this layering and that's why they have so many layers now every architect knows there's no free lunch well

there's a blank spot on the right hand side and that is of course the downsides right now if anything comes in it has to go through four layers or ten layers or 20 layers right anybody who works in a large organization knows that has seen that right so there's runtime latency and it leads to another very big problem people will start optimizing within their layer but we all know that a sum of local optima is not a global optimum all right you fall in the trap of optimizing locally and the way you notice that is

let's say you want something from this department they have a giant spreadsheet you need to fill out with all the information cuz it makes the implementation more efficient right because they get all the stuff they need and one fell swoop so they optimize locally but cause the giant cost and the next box that they don't see all right and those are in a technical system is exactly the same thing every developer knows all I want to do is add a single field to my screen and I need to make the change in the UI the

UI framework the application server the persistence mapping framework the database the backend service the API have you right all I'm trying to do is they on add one field and I need to make a change in six layers and it takes me forever every developer has seen that and in organizations that is exactly the same thing now if you you know use your architect thinking one more layer if you look at the stuff on the left-hand side and the stuff on the right-hand side they're slightly different it feels a little bit like one of these

IQ tests like what doesn't what doesn't fit in this series of terms right so so you know don't take it but do take it with a grain of salt but the things on the left-hand side and the right-hand side are different the things on the dev left-hand side are more structural considerations right they're like bringing order it's talking about dependencies it's a Turan is talking about the static structure of it the design of it these things almost all of them talk about the behavior the performance right latency propagation optimization overhead so the left hand side

things talk about static design and the right hand side things talk about dynamic behavior and now we know how organizations became happy with layers in the past because things were slow moving and when things are slow moving these runtime overhead considerations don't really harm you because it's slow you have time you have resources right so you enjoy the bennet the structural benefits and as the world gets moving quicker and quicker this starts to flip and that's why we have the famous consultant speak of delayering right we trying to take layers out or we're trying to

write the architect elevator right because we're starting to realize that as the world moves more and more quickly these runtime disadvantages actually come to bear more strongly and outweigh these advantages and that is absolute classic architecture thinking both apply to technical architecture as well as to organizational systems rather than architects can do that they're usually just a little bit too shy because the organization's deal with people and all the other complicated stuff right so so they'd rather still stay in their technical domain but in the end the forces and sort of the the balance of

this is totally the same last thing the architects in the penthouse learn is that optimizing the pieces doesn't necessarily improve the system so here's a classic example how fast how fast can these cars go pretty fast probably almost 300 kilometres an hour how fast do they go Wow 20 maybe 25 30 if you're lucky now the obvious question is you know does putting more horsepower in the engine make a difference fairly obvious no right however if you look at many organizations then look a little bit like this right they go and say oh we need

to hire better people right which is exactly the same like all we need to put more horsepower and the engine right but in the end it's not the people it's the system that makes things go slow right and again this is a very important architectural kind of thinking because it's easy to come in and say well you know in this organization nothing really moves right I'm sure these people only oh maybe they don't work all that hard or and you know maybe they're not up to date on the latest kills right and on closer look

you tell you find out they're all actually Ferraris all right they're just stuck in the giant traffic jam because the thing has a million layers right and it's all locally optimized each car is fantastic but it's not globally optimized right somebody needs to put some more lanes in and to be honest somebody needs to also teach them how to drive in lanes where that will help as well right so so apparently purchasing power and driving skill are orthogonal orthogonal dimensions coming to the mid-levels right going here thinking like an architect in the mid levels right

so so now we're talking a bit more about IT and there's a very sad message for most architects when it comes straight from the chief architects and his people actually don't care about the architecture why do they not care because to be honest they don't see it right you use estancia architecture right you have all these nice pictures on your wall like people don't look at that they just see whether your system is performant easily maintainable doesn't have any downtime right they see the capabilities that your architecture gives the system all right and interestingly those

capabilities come from how the system is put together here we have two systems they consist of the components a B C and D yeah easily illustrate this architecture beautiful architecture diagram and you know we can easily guess that the system on the left-hand side and the system on the right hand side has very different capabilities right this is classic layering as a long runtime but it's easy to take element C out and replace it with something else well the right-hand side is exactly the opposite I can go from A to D quickly but if I

want to deal with C or and it has all these kind of dependency so they're basically exactly the opposite of each other so that leads to a few insights and the one inside is architecture without lines is meaningless so if somebody brings you an architecture picture and it doesn't have any lines you can say hey Gregor told me Oh without lines this is not any useful so how I'll invite everybody to give that challenge to architects you have right if there's a picture without lines it shows the ingredients but it doesn't show how it's put

together and unless you show how it's put together you don't know what the system behavior is and you know what the users only care about the system behavior not so much about the ingredients right if you go to the restaurant the menu has a list of dishes it doesn't have a list of ingredients right buying good ingredients is helpful but you know good restaurants buy nice ingredients but mostly good restaurants are known because they have a great chef so we need architects to be good chefs not you know the guys who run down the supermarket

aisle all right the architect needs to be the chef who puts things together in the right way and that's what makes the good architecture and that likewise means if you ask somebody says what's your architecture and they say like Oracle WebLogic or whatever do you also realize that that is not very meaningful right you could still listing merely the ingredients right it's like what are you having for dinner oh I'm having grain and tomatoes and it's like well word cuz you like a pizza maybe right or you know pasta the tomato sauce or some sandwich

right it could be many things right people don't do that so don't allow IT architects to get away with just listing ingredients people want to see the meal not just the list of ingredients because that's what the users care about second one in our mid-level here that we have is the role of architects is often seen as as dealing with the so-called non-functional requirements right we have the developers deal with functional requirements they build the features and then we have some of the architects right there's the view that the architects deal with all the ility

so classic model and most people have probably seen this now I wish the life of the architects was that easy because unfortunately or maybe luckily because it makes it more interesting is the architects in my view much more deal with the non requirements now they're not called non requirements because they're not required they call non requirements because their requirements that were never stated context tacit assumptions things that somebody knew I expected but they were not written down anywhere somebody also expected this to run in the cloud but you know they didn't really say that because

you know they they thought that's obvious and then six months later they think it's obvious that it needs to run in a hybrid cloud right there are all these kind of things that nobody actually ever really said or articulated that's actually the main world of the architect all right so I can text don't just deal with non-functional requirements they also largely deal with non requirements right we need to we need to guess we need to understand context we need to talk to the business we need to anticipate right those are all things architects need to

do makes the job of the architect quite interesting right as I said the elevator is quite an exciting place to be now Christoph already and the I joked a little bit that half of Christoph's talk was referring to the previous talk and the other half he referred to my talk so he made his life a little bit easy now very clever right that's how you get to be a chef you know it's like you you defer you delegate right he delegated you delegate very nicely so he delegated one topic to me and then it's a

topic to explain how architects are selling options right this is black Scholes you know the guy's got like a Nobel Prize for economics for this if I'm not mistaken right so pretty clever people what is an option right an option is you acquire the right to make a transaction in the future and known parameters right so aliens talk is like 180 euros or something now you can buy yourself an option to buy aliens stock in one year for 200 euros right so you buy yourself ability to make a decision in one year to buy the

stock or not right and obviously there has a value for a couple of reasons the one thing is well when the one year comes making the decision whether you want to buy the stock or not is trivially obvious right and one year if you can buy a stock for 200 well if the market price is 220 you know you don't you don't need to understand this formula at that point to decide that if you can buy it for 200 and sell it for 220 you have money in the bank all right so deferring decisions almost

always has a value because if you defer it by the time you need to make the decision you have more information you can make a better decision and therefore these options have a value and they also have a price now there's a very interesting element in this formula is this little Sigma if you haven't noticed there's a sigma square actually rights like double important was like sigma square is like wow all right and Sigma square is the volatility all right and as you can easily imagine deferring a decision has more value the less you know

about the future right if aliens stock has always been 100 in 80 euros for all the 128 years they've been in existence maybe the chance that it goes to 200 next year is kind of low you cannot just assume it's the same as before versus if things are all over the map right deferring the decisions has more value right the more uncertainty you have being able to defer and making the decision later is more valuable right so in volatile environments option prices go up now let's translate that back into the I t1 is a perfect

architectural option a very great example of an architectural option is scaling out Hardware right everybody knows server sizing is kind of a difficult exercise because you have an application and need some hardware and you're trying to guess how much hardware needs now life is sometimes a little bit unfair because you only have two choices in the end either it ends up being too small or too big well one or the other if it's too small the application won't run if you put too much hardware you wasted money not a very happy exercise now what can

architects do for you they can give you the option to add hardware as we call that elasticity cloud scale-out architectures right we have many names for this like technical names but what we're really doing is we're giving you the option now this is great because once the application is running you can see how many users are there right we deferred the decision making the decision is now very easy right so now I know how much hard way and even more two more servers oh great right oh it's a little bit too many to service less

very very easy now coming back to our friend Sigma here right the the friend Sigma is of course in the scaling example as well if I'm building an application it has only ten users if one gets sick it has nine fair enough right but basically I know there's always ten users for this system buying this option of elasticity and scaling isn't all that valuable right it's intuitive right because there's little uncertainty versus if I'm building an online system where I have a hundred users today and have a million users the next day and I have

Black Friday and holidays about all right you can imagine you know there's volatility Sigma right you can see that this architecture option becomes much more valuable and that's the nicest compliment I've actually received from a from upper management aliens to form a head of asset management he said aha if architecture sells me options I really like the metaphor and he says I know that the value of options increases with volatility we live in very volatile times both from a business and a technical environment so I should invest more into architecture all right so is this

one of the nicest compliments you can get for be an architect and who would have thought that that comes out of showing people a black Scholes formula right so the world is interesting right so if you connect many different dots sometimes interesting things happen well that brings us closer to the engine-room right and there's a lot of stuff here so I'm actually not gonna talk about so many things right because lot of things going in the engine room so I'm only gonna pick out one or two things funnily something that Christoph already talked about but

I think I have nicer pictures so because Christophe talked about I'm gonna make that cursor go here because Christophe talked about traditionally we built robust systems where he had a whole talk about resilient systems and to be honest right robust systems are not bad right we all need to remember that when we bring something new it's easy to fall into the trap of saying well we made something better and that makes the old thing worse architecture it's not a Hollywood movie it's not there it's not the battle between good and evil between right and wrong

it is just these things largely used to be good and often are still good but they have certain limitations right and the things we do on top of it helped us overcome some of those limitations so building robust systems is not wrong at all who wants to build a flaky system right so making robust systems is good they basically build so that they don't break the problem with robust systems is of course what happens if they do break and always say that's like a German car I hope nobody offended here right German cars are built

to not break vmw is a fantastic car but they're your breaks and you have to take it to the shop right the bill is gonna be very very high right so that is robust architecture right resilient architecture would be if you can more easily replace some pieces so here it's about making things not fail he is about making things recover quickly and as Christoph already said both are part of the same equation you know if you become really good at failure recovery right I actually have a lot of old cars so I'm fairly good at

failure recovery hangers that do fail a lot right if you're really good at failure recovery if something fails a bit more often isn't all that bad if it's back up and running in ten seconds you know what that's why I always have starter cables in my car as I say a battery's dead and your starter cables so I become more resilient Ryan a dead battery is no longer a problem for me what's important to realize though is that these things are largely done out of the infrastructure better network better storage better servers Hardware redundancy your

hair this is all done oven out of infrastructure this is largely done out of the software you know this is like middleware software defined infrastructure containerize sort of auto deployments right this comes out of very different world and while these things always look so easy in the slides you realize that for the people working on it it's a massive shift right you have the poor guys in infrastructure battling it out because they're sort of feeling there they're the last bastion of off Daisy establishing uptime not realizing that the other folks have a whole different logic

of dealing with it right they've overcome the limitations right basically these guys are making thicker and thicker and thicker walls until there's normal room to live in and the problem is if somebody comes to the bigger Rock yet it will still go through your big walls and somewhere else right and the fairy tale is always behind the mountain or something I think right somewhere behind the mountain there's people who just built differently and that is a big transition that's what we call transformation right it's it's not a linear extension it's a different worldview right it's

a different way of looking at the world because it has different tools now once you resilient you can do something pretty clever you can inject disturbance right and Christophe already talked this a little bit if you can overcome failure very easily injecting failure is actually not a bad thing it turns out it's actually a good thing because more failure you inject the better you become at this recovery right so these people actually intentionally inject failure now careful don't do that if you're here right if you're honey you don't want to inject failure so I always

warn people in your management read about the chaos magnet so they should run the chaos monkey right bad idea if you if you and this kind of IT architecture right because it's gonna take all your stuff down right so these things have a natural sequence but there's like a couple of great examples of this kind of of these kind of systems and again it's not just hardware an application base it's really system based it includes mindset and people and the way you operate right it's a it's another ballgame two great examples I have for injecting

disturbance what do the fire men do when there's no fire okay they play cards and polish the trucks right but if they're not near polishing the cars and play at the bumpers you know and playing cards they set fire right and here's some firemen setting fire pretty big fires like a kerosene fire they set fire right they inject disturbance in the system they create failure now they're doing this in the staging environment not in a production environment and that's okay right I have no problem with that right but they're basically injecting disturbance because the last

thing you want if your house is burning and the fireman comes alcohol that's a fire you don't want right do you want people who can deal with disturbance and the other example of course is the human body we do the same thing we are very resilient organism and we get immunizations we take shots right immunizations are injecting disturbance into our system to make us more resilient well we are essentially also what we like to call anti fragile and I always like to draw these analogies write large scale IT architecture is very much like the real

world I just feel somewhere along the line the computer scientists have decided that because their stuff is digital their world is different than the real world right somehow they they dreamt up that in our world everything is always consistent and binary and transactional and all these kind of things and you know what in reality it isn't and trying to build a system that pretends it can be perfect in a world that is not perfect is never gonna make you happy so a lot of architects now realize that system architecture is much more like the real

world stuff goes wrong you know stuff fails things are unknown things are inconsistent but luckily you know what because the world has been like this for a couple of thousand years we know how to deal with this kind of stuff right it's just like we need to get out of our 0 and 1 illusion we need to get back into building systems like the real world build systems so that was a pre nice run through you know digital world architects riding the elevator all right busting the illusion on the top floors unfortunately right and riding

down the elevator to the different levels of course what we want to do is we want to bring change right the reason we write the element up and down is because we want to influence how this organization works and as I said we can't just collapse it right so the next best thing we can do is connect it now change is tricky business right and one of the biggest fallacies you can make is when you see an organization where things are slow and inefficient and maybe break a lot you might just say hey probably it's

pretty obvious people are doing the wrong thing right I know how it's done well and I look they're probably doing it the wrong thing doesn't work that way most organizations where things aren't working very well each person is doing exactly the right thing classic example so let's say you have an organization with this high friction well are we all no friction I need to fill out this other report you need to make this request another steering committee meeting another budget reporter and we all know what friction looks like TPS reports right so lot of examples

of friction so if you have high friction doing something cost more money I think you somehow need to deal with all this stuff your company your business nothing is free right now if everything doing something costs more money what is the absolute right logical thing to do well if you're spending more money you should have more oversight and control the right thing to do you know how the story continues all right if you add more controls you're adding more friction to the system so let's say for argument's sake that the minimum cost you can have

for project it's a hundred thousand euros and I'm not even thinking that it's such an unrealistic number if you're thinking to make a real proper project that writes one line of code and deploys it to the web server HelloWorld may have all the overhead of applying for the budget approval security reviews all that kind of stuff cost you a hundred thousand right some people might actually think oh I want to work there so it might be worse right might be worse our people gonna ask for a hundred thousand euro projects not really right because they

would be paying a hundred thousand euro overhead right they would be paying a hundred percent tax so what did they do what is the right logical thing to do you make million dollar projects I bet I get two million right you sort of anticipate everything else you might want down the line because you're already paying this project overhead so why not make a bigger project it's the right thing to do and you can see how the story continues right because now we have all the projects a million euro projects now minion Europe is a lot

of money so you should have a few more steering committees and a few more budget checks and a few more reports right and you can see that every person is doing exact we the right thing but in the end this system is going into a negative spin now that leads to a couple of consequences the nice thing is it also works the other way around so there's hope right so if you get things to be low friction people help each other they make smaller projects so it works also in a positive direction however you need

to first keep things from spinning the long way before you can get them spinning in the right way and stopping it from spinning the wrong way is not as easy as saying let me look who's doing something wrong because you will find everybody is doing it right so you need to fix the system not just the pieces and again that is architecture right the we all know this every system in Minister knows this right you're looking at you're monitoring your systems monitoring all servers are green nothing is working right that's exactly the equivalent or and

you look at the dashboard or all servers up there likes tricity CPU is available right but the website is down is exactly the same effect it is between the pieces where these kind of problems happen and that's why architects deal with a non requirement so and this stuff wasn't written down on you on there so leave you with a last message before lunch and change looks like this people on a little hill here I'm they actually pretty happy on this little hill the new ways you know the highly qualified consultant or new hire come in

and say I am from your consulting company XYZ or cloud provider ABC I know a different world I know over here there's a mountain of gold everything is better on the mountain of gold everything is fully automated everything runs in taco containers everything is infinitely elastically scalable you only pay for what you use it's globally elastically load balance right there's a mountain of gold it's paradise milk and honey floors right everything is great then you say let's go and then people realize oh the you know they need to get off the little hill and they

get into the swamp because people you know their stuff doesn't run in a container they don't know kubernetes so well you know maybe their own little network isn't so fast to connect to your global network right you know they're trying DevOps and being agile but they get into a giant mess right it's like they all end up in this little swamp and we have a difficult problem because people say like you made it worse and unfortunately they're right right you made it worse for them because yeah being on that little hill was actually better than

going through the swamp so that's why change is so hard so you need to prove to people you need to show to people that this actually exists and you need to be honest to them that it actually will get worse before it gets better now very smart people of course say well why don't we stay why don't we stay here you know life isn't actually so bad on our little hill well there's one problem that's called the digital revolution and the digital revolution is like global warming now some people still convinced that doesn't really exist

most of us have seen this right global warming brings rising ocean levels well things need to be faster release cycles global products near all that kind of stuff right the water the water level rises and now going from the mountain of more going from a little hill to the mountain of gold is no longer swimming exercise no longer walking through the to the mud exercise but it's actually a swimming exercise so I want to leave you with two words of wisdom right and the first one is it always gets worse before it gets better but

the second one is the worst thing only becomes worse you're better off going now thank you very much they go well thank you very much for this very inspiring talk oh thank you thank you sorry where's the camera thank you [Applause]