thank you thank you very much it's actually my third time here with busy hour and this year I'm particularly happy because as Dave alluded to I'm in the middle of a major transition neon not only in terms of companies but also all my things are in a container hopefully right now crossing the ocean as I'm moving from Munich to Singapore so I'm very pleased to be able to actually make it down here while I'm in sort of an InterContinental move as you can see from an affiliation right I'm also in a professional transition so most I want to talk about today is about my five-year experience as a Chief Architect at Allianz so a little bit over five years ago I was hired as the head of Enterprise architecture and to be honest I didn't even really know at that time what Enterprise architecture was and this whole head-off thing also confused me because I was always never sure what do all the other body parts do if I'm just the head of this thing right so I had a lot of questions but over time and over five years I realized that he has much fun as we make out of Enterprise Architects and architecture it is actually an extremely interesting and valuable function especially for companies who are undergoing a rapid change which these days is many of the large organizations so I came to conclude that Enterprise architecture really has sort of two major major problems or challenges and the first one is really people think of it the Enterprise Architects all the people who just sit in the Ivory Tower right they draw pretty pictures you know give great speeches you know boxes and lines diagrams and if something really goes wrong they say well you know implementation issues right so so that's problem number one and unfortunately sometimes this perception is actually reality I've seen Enterprise architecture departments like this I don't call this Enterprise architecture right this is I call this sort of you know looking good you know based on other people's work this is not what Enterprise architecture is is about the Second Challenge is that many Enterprise Architects believe they're this guy right so it's like you know this is you know the Chief Architect makes all decisions you know designs has to complete overview Etc and the ironing of this is that in a large organization that can be a little bit political or also risk-averse actually other people sometimes also like the Chief Architect to look like this because it's kind of Handy if somebody else makes all the difficult decisions all the big decisions right because if something is wrong while it was that guy and not me right so this is another very unfortunately very popular anti-pattern that sort of distorts what Enterprise architecture is is really about so what I don't do is like debunk this a little bit right and explain what I think the real role of Enterprise architecture is and why that is such a valuable thing to do so first we need to understand that you know as as Enterprise Architects we generally think about the I.T side right most folks here if they carry the title Architects will be IT architects you know like software Architects Cloud architect infrastructure Architects but of course you know that is only part of the business right usually I.T costs money and the money comes from somewhere else it comes from the business right the vast majority of us will be working for business so if we start talking about architecture and sort of building and designing systems the interesting thing is well who does that for the business side right there must be somebody who also designs and Architects the business and in fact there's a whole discipline and recently there's more events and writing about it called business architecture but in many organizations you will find very few people who have the title business architect and that is because those folks are usually the senior business Executives right there will be division heads division leads vice presidents Chief Operating officers those are the folks who design and architect the business and I often feel like there's actually a nice symmetry on it they architect the business and we architect the I.T to support that business and then the Enterprise architecture is really that makes sure that this matches together because the most nice and elegant ID solution doesn't make any sense if it doesn't have the alignment with the business right this is where everything starts or falls apart it also means that the organizations where the business and the business architecture are very close to each other you don't need a whole ton of Enterprise architecture unfortunately or luckily depending how you look at it that is usually not the case right so you need Enterprise architecture so that as a glue as a connecting element let me move that cursor out of the way there hold on oops there we go right so in the end it's about you know the the ultimate role of Enterprise architecture is to make sure that connection is in place now when we talk about Enterprises and how things work in a large Enterprise we'll often like the things about value chains right the value chain is to make sure that a series of individual activities ultimately lead to value for the business and I think using that meta for Enterprise architecture is is quite appropriate right there's a lot of things you could be doing right and many other other folks at the conference you know Jeff Patton Etc talked about generating user value and impact and I don't think it's any different for Enterprise architecture so when I saw the the the steps here or the pieces of Enterprise architecture this is not a recipe right it's actually a fairly complex domain but I rather think of it as a value chain right these are the pieces that have to come together in order to make Enterprise architecture valuable for the business there's a young Enterprise architect in the audience the the other property we have about value chains the reason it's called a chain is that if one piece is missing the chain breaks right this is the the sort of the the special and sometimes unhappy property of chains right so that they have a weakest link so basically in the end you need to be aware of the fact that you need all these pieces for this whole thing to work and function together so what I'm going to do in the first half of my talk sort of run through this and explain a little bit what this looks like in a real extremely large Enterprise right it's all being Allianz being a large insurance company 145 000 people I mean 130 billion euros Revenue in that order of you know 11 billion profit all over the planet right very large and complex organizations so let's start with the beginning and you know it sounds terribly obvious but if you want to do Enterprise architecture and come up with an I.T strategy well the very first thing you should do is understand the business strategy and you'll find that in large organizations this is a not trivial and B it's extremely interesting right and I've done this in my past yeah I traveled through Asia with Allianz to understand how do the markets differ where are the growth markets where's the revenue generated generating Revenue doesn't necessarily mean it's the most profitable division how do they have different business lines and products across different countries and regions so for example it turns out in Asia it's a lot of life insurance that they have only Malaysia does Allianz have a significant Property and Casualty business different distribution channels distribution networks sometimes insurance is sold through banks sometimes through agents sometimes who brokerage right this has a big impact ultimately on uit architecture because as we'll see architecture is a lot about making assumptions and building flexibility in your system so only by understanding the business can you have a feeling for what flexibility actually provides value to the business and if you think the the business itself is not interesting enough the organization will certainly be in these large organizations International organizations they will be holding companies there will be business divisions case there's a lot of country divisions because usually Insurance licenses are issued by by country but then there's also Global business lines right that that do business around the globe because they deal with large corporations or travel insurance that doesn't that makes little sense to have in a single country so you find that sort of modeling the organizational domain at the end almost has the same complexity as the business domain the good news about this you might sort of Wonder is like well you know isn't this somebody else's job right why do I as architect have to worry about this and I said first right because this is where the story starts if this misaligns right everything else won't make up for it and B you'll find most interesting most businesses are actually really interesting right so when you think about insurance you know most people don't go to work for an insurance company because it's so exciting right insurance is you know pretty stable pretty boring in my case the company was like 127 years old right it's kind of sort of business as usual but once you dig a little bit deeper you find that most businesses are really much more interesting and much more Rich than you expect so for Give an example in Insurance case it's not about sort of buying homeowner insurance and then if your bicycle gets stolen they won't pay anyway because there's a fine print somewhere in the insurance policy right but they ensure large for example corporate installations aircraft all dwelling platforms those kind of things and you start to read realize that in those cases if something goes massively wrong the customer doesn't want just the money the customers want crisis management right and this can be technical crisis management or this can be reputational right like things go wrong you know people poison food Etc all this stuff has happened companies are insured against that they need crisis management so insurance companies know a lot more than just sit and wait and pay money later right they actively help the customers manage major crises right because ultimately they have a vested interest because you know the the quicker this off the problem the less the damage is afterwards or to give another example Allianz has folks who do turbine engineering for like power stations you're like why would an insurance company employ people like this well it's very easy if you're trying to ensure a major industrial installation they don't just like send you an insurance form and like fill out your name and your coverage right they go and have a close look at what you actually have and they will do safety inspections right so they basically review your drilling platform your power stations whatever you have and they will have their own demands right they will have their own conversations about does this meet their safety expectations because otherwise they won't insure you so in the end you'll find and this is true for most other business domains once you sort of Peel back the awning a little bit it is much richer much more interesting than you would have thought and insurance is a great example so this is where it starts right you need to understand what your business does so you can make a matching I.T strategy but before you get there there's a very important step and this is often forgotten and that is what does your business actually think of the it now that seems a very trivial question right so of course it is the one who runs all the hardware software Etc but from a business point of view right they might have very different views why does it exist in most large Enterprises what it exists because it automated manual processes right Insurance used to be very paper-based right claim forms and contracts and stuff so it automated that but that is largely done right they all have a finance system they have a claim system an accounting system right and it's like that stuff is just there and it has a relatively High run cost and a large company like Allianz some of this is in the billions of dollars right here so big money so they look at it largely as a cost center right if they can keep this running for less money they will be quite happy right so just about making it spend less money because you know largely what it was meant to do they already did now interestingly often you can read in an organization what this view is and I'll talk about the other ones in a second is by the reporting line of the CIO so usually in an I.T organization the CIO the Chief Information officer is sort of the most important person in it it's also a very difficult job so many people joke that it stands for career is over right or people say the most important thing in the CRS contract is the severance package right because CIO is supposed to cut cost B on the brink of Technology support the business yada yada they don't have an easy job now interestingly in many organizations the CIO even though it's such a stressful job don't report directly to the CEO right so and often they will report to the CFO the Chief Financial Officer now what does a Chief Financial Officer do well that person basically writes the checks to simplify a little bit so they look at cost they don't look so much at Opportunity so if you look at an organizational chart and the CIO reports to the Chief Financial Officer that is an indication that they think of I.T largely as a cost right and we come to this the way you start selling things to the business very much depends on this view so let's see what some other stages are so the cost part is one and here whether you like it or not if it's just about cost The Logical conclusion is to Outsource the I.T because you know you can get the same thing for cheaper if that's all you have sure you should do this you know it's like electricity out of the the plug right if you can get it for two cents less a kilowatt hour you should switch the provider and get it for Less now as I said you may like this or more likely don't like this right but if it's really a pure cost that is the logical thing to do the dangerous aspect of course is is that the correct model right are we really I.T on the left hand side so many organizations have realized that it is more than just a cost center and that there's an opportunity to save costs on other things so they automate more processes they streamline and harmonize and they see it as an asset and that might sound like a trivial distinction but it's a huge step ahead right because an asset is something that you return that you invest into and you get a return on investment right so give a simple example let's say if your car and you're purely cost driven you don't get the oil change right because it's another cost right the car will still run you know you saved 80 bucks or 100 bucks right that's if you're purely cost driven now you might say oh that is not a very clever thing to do because you understand the system and what will happen right but if you're purely cost driven that's the easiest way to save cost now in the second one there would be of course you get your oil changes because there's a very good return on investment on the oil change because your car will live much longer so this might sign like a trivial distinction but it's actually a huge step forward because it gives you the ability to invest largely those companies have the CIO reporting to the CEO it's got the chief operations officer I also sometimes say Chief optimization officer these are the people who make sure the business runs well and runs efficiently and the CIO reporting in there is a clear sign that it is a part of getting the business to run efficiently and efficient means you get a good return on investment and often this is governed by economies of scale right because these Investments you can amortize better the bigger you are right Allianz was a great example of this 145 000 people divisions all over the planet so they'll be very happy with this model because they could amortize their I.T investment very well now recently people have realized that it's purpose is not just to get the shop to run more quickly or to it more smoothly but actually to unlock new opportunities that's what digitalization is all about I always joke that Allianz is like 120 20 27 year old business that they had plenty of time to find all business models that can be done without technology right come on 127 years right so that they figured out so now going forward on new business models that they come up with are technology enabled and the use cases are fairly obvious what does Insurance do these days a lot of iot because Insurance ensures things so knowing more about these things is quite valuable so this is like telematics pay as you drive pay how you drive so basically how much you drive with your car and the way you drive with your car those things can impact insurance policies a lot of Health monitoring all these kind of things right so a lot of stuff going on there and that sort of moves I.T to the right hand side and there you have some other folks coming into play and that's all from this CDO achieve digital officer and that is usually a sign that people start to realize that technology for them is not just sort of business as usual and getting the business to run more efficiently but it's actually something that unlocks New Opportunities right and if you play this a little further often you'll have the CIO reporting to the CEO directly and that is a sign that for them it is really a big drive and enable of the business and at that point you find that people actually stop talking about I.T and business you know in seven years at Google I was before nobody ever said oh we should talk to the business right the distinction just did not exist and interestingly when I joined alian some people came to me and said well Google is a technology company we are insurance company and I always said well it's funny you would say that because Google is an advertising company right I work in Google Cloud I sure wish we were more of a technology company because you know trying to sell my cloud products 90 some percent of Google's revenues advertising so advertising and insurance isn't all that different they're both services companies it's just Google has understood how to make technology an integral part of their business model and insurance is still in the process of figuring this out last important part on the right hand side is once people realize that the value of it is bringing Innovation and new products they realize it's no longer about economies of scale but its economies of speed let's see how quickly can you get things on the market and how quickly can you iterate and this is the only reason large companies have to be so afraid of disruption right because if the world is run by economies of scale if you're 130 billion Euro organization you would not have to worry at all right because economies of scale are extremely hard to attack but the rules of the game have shifted right in its economies of speed it's about release Cycles Etc and large companies that have good economies of scale usually are slow so they have poor economies of speed and that's why they have to be so afraid of disruption and this is again where Enterprise architecture comes in in to help with that now the interesting thing is why this is so important to understand is so let's say you're an architect and you paid great attention at this event and you learned out about continuous integration continuous delivery Docker container microservices all that kind of stuff you have right and you try to sell this to your organizations at oh of course we need CI CD if your organization is on the left hand side you will just bang your head against the wall because you're selling speed to an organization that's cost driven right and of course the new technology regardless whether it's open source or not it will cost money right you need new skill set training new people new hardware Etc so the Sea of all we'll just hear oh my God right I heard this with client server I heard this with a web you know I heard this every time and every time the it just cost more money so you cannot sell speed to somebody who is cost driven now you can do two things you can change their way of the view of it right and make them understand this and that's something you should do but that takes time or you need to make sure your message lines up with their view of it so if you want to sell Docker containers let's say you don't come with a CI CD and speed angle you come with a hardware utilization angle right say oh with lightweight containers look you know more stuff fits on one machine so all this expensive Hardware we buy you know it's more highly utilized or we can harmonize our tooling we need less diverse tooling because everything looks like a Docker container so we save money there that is something a CFO or a CIO reporting to a CFO can understand but they won't appreciate the speed argument if they live in the world of cost cutting and economies of scale so it's very important to get this right because everything that follows will fall apart if this doesn't if this is not aligned and the usual symptoms of this and it's not being aligned is the Architects coming and saying oh business doesn't understand they don't fund my projects you know data one that is the usual symptoms because you're not speaking the language of the expectation your upper management has so if that is out of whack everything else won't work so let's assume we get this right now we need to formulate a strategy right and you know you see often these motivational posters you know we provide the best service at the lowest cost well that is not a strategy that's like we're going to win this race That's The Wishful outcome right that's the desired outcome that is not a strategy right the strategy is supposed to tell you well how you're going to get there what are you not doing right faster better cheaper is not a strategy right that's wishful thinking so you need to make an emphasis are we a premium provider or a low-cost provider right and if you are one or the other you're not you're not the opposite right so that's the most important you know so the first stumbling Stone in the in the strategy the other one is strategy is not reality you know it sounds obvious but I had that challenge many times as Chief Architect so one of our strategy was we containerize as much as we can right I mean you would say not maybe a very creative strategy but sort of at the high level business right right that is our I.T deployment strategy for infrastructure people raise their hand immediately and say well not every application we have can be containerized that does not invalidate the strategy right that is the gap between where you want to be and where you are and that is fine right it is not reality and the third part is equally important is you know a lot of large I.T is you know they tend to be buy versus built organizations right and they allowance as an insurance company at the end of the day so they tend to buy a lot of their technology and that's good so but what that also leads to is that there's a huge impact from the vendors right then they do the job very quickly and yeah they show all the road maps they inject all the kind of ideas they have right so it's very tempting to take the vendor product roadmap to be sort of a substitute for your strategy and I think especially in today's day and age that's fatal right you need to have your own I.T strategy and know where you want to go and you map that to what the vendors offer you and it either matches or it doesn't match and that's how you make your purchasing decision right if your strategy comes from the vendor or wonder you know their product will line up perfectly with your strategy how convenient right for the vendor not for your Enterprise right so you need to have your own view of where you want to go with this so zooming in a little bit here's an example so this is one of the earliest books on Enterprise architecture right there's a lot of stuff in there that's a little bit outdated but there's one really good diagram and it shows a high level translation between a business operating model and the kind of it that you want to have so this one I need to explain a little bit we don't need to worry about all the detail but basically it has two axes right what the business operating model looks like and the two axes differ by how highly standardized the business is and by highly integrated the business so give you an example right like McDonald's or Hotel chain they're highly standardized they're like Cookie Cutter like these franchises right like one looks like the other but they're not highly integrated because they operate fairly independently you probably have some Financial rollout at the end but each McDonald's in each hotel is basically its own business so they will be on the bottom right you see like Marriott there as an example right versus something that's more highly integrated is something that as an Enterprise has a has a long value chain but that is coordinated so like oil and gas is a great example right they do everything from like you know going through the jungle and desert to find oil until your Refinery Market I mean like an exploration they put this on a ship they have transport their refineries they have trading they have retail you know until the thing gets into the gas pump but they're highly interdependent right they integrated these things don't work independently right and you found businesses where you have neither like GE or Siemens they do everything under the sun right they're not standardized integrated and you will find some business that are both long story short the kind of I.T system at a high level architecture you want to have depends on this all right so if you have a high level of replication you can make standardized applications you can have the McDonald's french fry management application whatever they have right and a hotel management booking you know hotel management system and you can replicate that and that is a very nice thing to do for it if it's not so highly standardized all right best you can probably do is give them a common infrastructure to run on because the applications they need will be quite different likewise if it's highly integrated data integration you know Common databases data stores or generally Enterprise Integration becomes much more interesting because it provides more value to a business that has an integrated business model right so integrating the data integrating the system will provide value to them versus if they are from a business perspective disconnected you know the integration doesn't help much so this is a great example you might think this is pretty lofty pie in the sky but again if things are out of whack here the largest project right people spend tens of millions or sometimes more and integration and data lakes and you know shared data warehouses if that is not what provides the biggest value for the business you know that is a guaranteed way that these projects will ultimately tank regardless how good the technical architecture is right so this is a fantastic example where you classify the business operation model and make the translation into the matching it strategy so let's go to the next one so now you know where you want to go now you need to find out where you are and unfortunately more often than not you get a picture like this right so you might not like what you see but in the end you need to get some transparency in large Enterprises even getting this is a giant challenge right the international different divisions different organizations different vendors so getting some transparency is a huge step forward on this picture I always always joke that um this is actually a fantastically highly scalable stateless architecture because look the database is in the bottom left and there's absolutely no connection to it right so if you think you know and it's highly integrated right so it's like it matches the integrated business model right so yeah so all jokes are signed getting reality is the precondition to charting out a roadmap because if you don't have the starting point you know the vision doesn't help you you quickly wear yourself out and saying oh we should be all in the cloud containerize cicd la la la people will get very tired people want to know how you're going to get from here to there in Melbourne there was um Simon was giving a talk about um what is it like to be a CTO and he basically he said yeah what what is dope for management you know what does management always want to see and his answer was they want to see a plan right and we as Architects or sit folks we're very much geared to like showing the the target State we are there to show Solutions look it's all going to be fantastic right I have my Docker rice Jenkins farm and this and that you know docker everything will be fine and management will go like he went to another I.T conference again right and heard all the fancy stuff yeah let me leave me alone so management wants to see a plan they want to see a roadmap so when you make this translation right when you go to the Target picture on the road map it works well to show before and after and even I made that mistake many many times we like to show only the after version because that's what we generally paid for but for management you lose them very quickly also it makes for a much better storyline it makes for a bit more suspense if you say look this is where we are here's the problem here's where we want to go and here's what's going to be better so this is a real example it might seem like a very simple example but it's a real example we're saying what is our biggest problem you know bigger problem biggest problem is that the application are in silos and I'm not talking about the data isolation here right I'm talking about its duplication each of them have their own runtime automation their own tool chain their own testing Frameworks their own monitoring Frameworks right e each large application in this insurance business came with all the bells and whistles and that has two problems you know the one thing is you know this is huge duplication you know this costs money and B none of this provides any business value right you don't sell a single insurance policy because of your monitoring framework right like any other monitoring framework will largely be be as good so the key part of the strategy is to move the things of the bottom stack into a common runtime platform so common tool chain common deployment common runtime platform because at the end of the day that's not where the differentiator is and let the applications focus on functionality not on runtime infrastructure and then you can see in the third step that this is also preconditioned to break in these applications down into smaller maybe you want to call it microservices but into smaller pieces because on the left hand side well with a lot of money you can still kind of get away with it it's not a clever thing to do but if you just bankroll it you'll be fine on the right hand side you know if you don't do this for three applications but for 20 30 100 or more services each of them having their own deployment testing monitoring Etc framework runtime framework right that will just grind you to a halt now if you look at this and say like oh you know this is actually fairly you know I don't want to say trivial almost right this this makes a lot of sense there's the nice quote and I actually looked it up it's from blast Pascal there's a famous quote that says I was going to write you a shorter letter but I didn't have the time all right and this was actually Pascal the one the programming language was was named after so one of ours if you wish right and the same is true with Enterprise architecture to come to the simple message to get stuff to the essence that management that the CFO can see oh yeah all these big green boxes yeah you make this smaller huh this saves me money yeah sorry to say right this is at the level you need to work and at the same time making sure that this actually has some technical Merit and doing this in a compact format is actually not easy right so I spend a lot of my time this wasn't the first picture I drew there I spent quite a bit of time to really make the shortest letter right and this is another I would say important lesson to be learned like condense down the message stay true to the 10 technical nature right this is not BS right but come to saying this is the biggest problem we have right now and the key strategy and roadmap is you know to put this runtime platform in and as you can see on the right hand side once we have this runtime platform and abstraction this also serves as a basis for a hybrid Cloud strategy yeah they're sort of hitting the on-premise off-premise there because once you have that right it's more easy to shift workload in and out private cloud and and public Cloud right and this is what a lot of the kubernetes docker kind of things help help us do another real example is governance right so now you have the roadmap laid out as we said management likes plants and roadmaps so we have that now the G word governance comes in what is governance right governance is basically what is so people don't goof off right it's sort of to make sure that the reality follows the roadmap and it's not an easy thing to do because often it's seen as an extra hurdle right it's like when somebody says oh I'm here to do governance people quickly get busy right it's like oh I have something else to do right I once heard the joke like the three biggest lies in the world are um I love you forever um the check is in the mail and I'm from headquarters I'm here to help you right so so this is the governance right it's like yeah I'm here from headquarters right so in the end though this is another real picture we said how do we deal with governance right so if you see this simplified stack so infrastructure platform applications customization where's the business value right does your customer care about infrastructure you run on oh yeah as long as the stuff is running probably not but they care about your features and customizations and tailoring to the local market or to their needs right so the business value is clearly on top so one thing we realized and this is an Allianz example is that we have a huge level of diversity I mean basically you name it we have it right so so Allianz owns everything so there's a huge huge level of diversity at the bottom but at the same time at the top the applications often lack flexibility right and people from the local markets are always complain and saying well your insurance system doesn't really serve my local market because I'm in Taiwan or I'm in Bangkok I'm in Thailand or I'm in the US so I'm in Germany we just have slightly different needs so my view was that that is exactly the wrong way around because you have too much guidance where business value could be generated and a little a little bit more diversity would provide business value but at the bottom of the stack right in infrastructure where it would be very hard to make the argument that that Pro that that sells insurance policies right there you have a huge diversity so in the end yeah what you want to do is that's where you want to start to govern where you want to reduce diversity right for example give a real example people always came to us as like oh your virtual servers don't meet our needs okay why would that be oh I need more RAM per CPU and my answer is well you know in a scale of architecture you just get more machines right there you go you have more Rams what's wrong with the architecture right should deal with this well in many cases in this particular example it turned out it was a licensing model that gave them a headache right because the reason they wanted so much RAM per CPU was because they get billed by core by lavender so they want to load these machines up as much RAM as possible so they can eat every little bit of performance out of that CPU because if they add another core they will build dearly So my answer was just like well we don't have an architecture problem we have a line sensing problem all right go talk with a vendor right this doesn't match our strategy our strategy is a scale-out architecture with harmonized infrastructure if your licensing model doesn't work with this well you know we need to have a serious talk right you shouldn't be on our strategic roadmap if you can't fix this so this is the way you know you drive business with Enterprise architecture coming back to the hurdle so nobody likes governance right it's like checkpoints architecture review boards right who here loves going to architecture review boards yeah exactly I'm not even being right am I lower my hand right this is something you don't want to go to because people come with extra hurdles right at the same time we found that an architecture review board can also provide value concrete example somebody showed a network architecture you know sort of you know leaf and spine sort of classic Network top of rack switches you know yeah they gotta you know not cheap Millions some euros for a Data Center and we have this in the architecture review board we had a feeling for the size of that location for the data center it seems pretty over dimensioned I forgot how many VMS they actually had but it was like a few thousand virtual machines or something in this data center having like 1.x million just for the network infrastructure seems like a lot of money well talking to the architect you know the guy who came up with this was a very intelligent person he basically it came out to they didn't want to be blamed in case something went wrong they were being super risk-averse because on the company that makes 11 billion profit it's easier to spend another 500 000 Euros than to get kicked by your boss right by saying well you know you know maybe you have larger failure domains so if one of the switches goes up in in thin air right you have a larger outage so for them they're just being extremely risk-averse right and it's easy to say oh this is a silly architecture so I know for what they were after was exactly the right architecture because they were like minimized blame on me that was the driving requirement for the architecture now having that discussion in the architecture review board and having me as Chief Architect there I basically voted it's like well here who here would be in favor of taking one level out of one layout of this architecture basically collapsing this one layer saved like 400 000 Euros or something basically everybody said it's gonna be fine right I mean this switches have like mean time between failure of 50 000 hours anyway they're all redundancy there's always two switches they're like it's gonna be fine anyway they said great then we'll go with this solution and if anybody throws any rock at this send them straight to me right you don't have to stand up for this and defend this if your boss says oh this was a dumb thing to do or whatever you know problem they have send them straight to me and I say listen up we had all the smartest people in the company in one room we all said this is the right thing to go and we went with it I don't know how we could have made a better decision right so in the end you can give people help and support also in these review meetings it's not just like putting extra extra you know blocks or something in their way but actually defending them in case somebody questions their decision so this is one nice example where we were able to provide value in this usually not very beloved you know review meetings cool so we're almost here at the at the end of our value chain we have two more important parts and that is it's not going to go like you planned right and this is a big theme at this event anyway right there's a lot about getting feedback and adjustment cycles and that is not any different in Enterprise architecture either likewise it's one of the biggest challenges for Enterprise architecture because your feedback Cycles are slow right if you found out four years later that you should have had that other layer in the network architecture that's a little bit late so the best thing that we did is to we made sure that our architecture team doesn't sort of sit on top right the classic picture of central Enterprise architectures here's the organization and then you know Enterprise architecture is on top we didn't like that picture we basically made an Enterprise architecture team that works at all technical layers we had infrastructure Architects we have people on call we build real platforms and that gave us a much closer connection to the reality and gave us a much better feedback cycle right because in the end you need the signals you need the feedback in order to steer what you're actually doing and the very last one and almost most important one is so you think if I do all this it's fantastically great but you forgot the people right and no matter how much money you have you can make it like me 11 billion profit a year you won't have enough people with the right skill set well and that's because stuff keeps changing stuff keeps evolving right this is a problem that you can't solve with money and that you shouldn't solve with money alone so in the end mentoring and sharing and growing skills set and and giving an identity to The Architects The Architects team was a huge part of what I did there so we started writing papers around it I Mentor people I coach people we speak at conferences together right so there's a lot of human element right this is not a simple top-down thing where you tell people what to do right you need to help create the base and what you bring to the people shouldn't just be commands like oh put everything in a Docker container but it should also be really mentoring and growing because that's in the end what will make the organization successful all right this is the the last but by far not the least element of this value chain so that's you know as we said yeah it goes by really understanding the business understanding the business strategy mapping that to an I.T strategy developing a Target picture out of that making a road map towards their target picture than having some governance to make sure that reality matches that roadmap and then ultimately that you get feedback and calibrate and don't forget to mentor and Coach the people along the way because only that way this whole thing can become reality now it's time to look inside the head of one of these you know Enterprise Architects like what kind of thinking do you need to have what do you need to do to to do a good job at this right and in the end we try to distill this down to three main factors yeah it's a lot about the connections it's a lot about abstractions and it's about making decisions before we go there do a tiny little bit of an exercise so let's say you're the Enterprise architect or an I.T architect and you meet the CEO in the elevator so classic elevator pitch and CEO says well what do you do here so first you need to be clever enough to realize that when a senior executive asks you what do you do they don't mean what do you actually do right it's like oh I come in the morning I log on I open PowerPoint you know draw some nice pictures right that's not what they want to know they want to know what value you bring to the organization right so translate this into okay you're the architect what value do you bring to the organization well right now you have like depending how many floors your building has right you have like 30 or 60 seconds to make a convincing pitch right and if you start talking about Docker containers and CI CD probably difficult for the CEO to understand so we had this exercise once where senior executive asked somebody and they started talking about you know architecture it's you know the components and constraints and rules you know whatever some like IEEE 1471 definition of software architecture of the executive was like whoa I wish I hadn't asked kind of thing and then I said oh no architecture is very simple architecture is selling options and in this case we were lucky because the person we were talking to used to be the head of asset management the insurance company financials that stuff they know so it helps a lot to speak in the domain of your counterparts right if you work a financial services organization talking about options you know that is for them it's like what's Docker containers for us right that's all easy now this is the black shorts formula you know two very smart gentlemen got a Nobel price for this and this is options pricing so very condensed Layman's explanation of how this works your financial option is usually you acquire the right but not the obligation to make a future transaction at given parameters so let's say you can buy the option to buy Alliance stock for 250 euros in one year so currently it's like I don't know 196 or something right so you can say in one year I am allowed to buy a leon stock for a guaranteed price of 250. now you know when the year comes it's very easy to decide if the stock is more than 250 of course you buy it for 250 you sell it for more money in the bank if it happens to be less than 250 you just don't buy it you let the option expire so to speak now this option has a price right because there's a chance you know the stock will be higher than 250. so you know there's a value there's a price to this coming back to architecture why are we selling options what we're doing the same thing how do you know a system has a good architecture a system has a good architecture if in a year you can still make changes new requirements scaling out right migrating to a public Cloud right these are what makes a good architecture these are options you buy they cost a little bit of money but they provide you value so it's a classic wisdom that deferring decisions has value and options is a clear example of this bring an I.T example again what is a what is a classic example where architecture helps you defer a decision scale out right it used to be server sizing right before people to launch anything they do do server sizing they spend weeks and weeks on server sizing and server sizing unfortunately only has two possible outcomes too big or too small right so either you waste money or the CFO will ring on your door it's like why are you buying all this Hardware right all the other stuff doesn't perform so a scale out architecture is a classic example of deferring a decision now you can add Hardware at will you can scale out when you have the actual need we all know this but in the end it's very much like giving people an option you're selling people the option to add Hardware later and that has a value so when the CEO asks you know you know what do you do here it says oh I sell options and they will surely say oh please explain to me how this works and you have a fantastic pitch now in my case we lacked out even more and there was the head of asset management of course you know this is his home turf he said aha I like this analogy and in a volatile Market the value of the options goes up so this is something that I didn't know but you know read up on Wikipedia it's a little Sigma in there there's a sigma squared another Sigma there so as the volatility goes up the price of options goes up the Layman's explanation is a little bit so let's say alian stock was like 200 Euros for the last 100 years buying an option for 250 maybe not that interesting versus if there's a lot of movement in there right it might be more interesting yeah like Layman's explanation but basically so my counterpart you know the head of innovation said oh I like the metaphor and I know that in a volatile Market the value of the option goes up right now we have a very volatile Market both in I.T and in business right there's a lot of movement going on so I should spend more money on architecture right so that's the kind of conversation you want to have with your Executives right will they conclude themselves that you know they should be investing more because the options architecture provides you are now more valuable right because you have applications on the internet there are more scale demands right if you build applications for a thousand internal users the option of horizontal scaling is not as valuable because of the Thousand users to get sick fine it's 9.98 right versus if you put stuff online well it's like 10 users today 100 000 tomorrow and 50 in the day later right so in a volatile Market can very easily see this option suddenly becomes much more valuable and this is a great way to engage with management saying that's why we do software architecture but coming through the three main components so talking about Connections so the the key statement and this comes from a Chief Architect is is that you know people really don't care about these systems architecture right they care about the properties that your system yields that your architecture yields and as we'll see that largely comes from what connections you make but these are very different kind of connections you will be making right you might be making connections between different layers in the organization you know this is what we said in the beginning making sure you know business strategy I.T strategy Etc is the line right so you make sure things are connected over different layers of abstraction you can also connect things between different applications right this is the data warehouse data Lake Etc right we talked about in integrated business models integrating systems also has a high value and then you know the third one is integrating different functions so for example we work very closely with procurement because procurement has one important property if you want to spend a lot of money you usually have to make it past procurement and we had good friends and Kim procurements if somebody came like oh I want to buy this monitoring software for a million bucks procurement said like well you surely aligned this with the central architecture team right and then I will get this email it says oh I think we need to have a quick phone conversation it's like well I don't I don't think this is going to be a quick conversation right so procurement was a great sort of you know safe stop for us when a lot of money was going to be spent on things that were not part of our roadmap right so those connections also hugely valuable but coming back to why people don't care about the architecture right and this comes from a Chief Architect people care about the properties of the system that are generally set by your architecture so two systems here fairly abstract do you think those two systems have different properties who thinks they have different properties wow come on all right counter example who thinks they're like behave exactly the same okay let's be brave on why oh I could be looking at different abstractions for the same problem that's I wasn't prepared for such a clever answer so I'll talk to you afterwards so so very good though right this could be different viewpoints right it could be the same system different viewpoints very very good so let's the same assume it's the same Viewpoint right if it's the same Viewpoint the properties would be vastly different right so on the left hand side it's easy to replace one component for example because the dependencies are very clear at the same time you might have some more latency and if one component fails the whole thing is pretty much down and the right hand side is almost exactly the opposite right you have more direct connections likely lower latency um if one if C fails maybe you can still talk from a to d which you can take on the left hand side but it's much harder to replace an individual element because you have more dependencies right so in the end right what does this tell us is it's not about the ingredients it's about how they're put together right like the whole property is changed just by the wiring so I give the example this is similar to restaurant so buying high quality ingredients is is a good thing but you go to a good restaurant because they have a good chef and what does the good Chef do the good Chef puts the things together in the right way right in give Two Chefs the same ingredients and one will be great and one won't be any good so the Architects are much more like the chefs our job is to understand how things are put together to yield certain properties not to have a shopping list right unfortunately in it architecture too oftentimes it's the shopping list you say what is the architecture web logic web sphere right that is not an architecture that's a piece of a shopping list right so that is one important takeaway from this right it is about how you put things together second takeaway is when somebody shows you an architecture diagram so some Viewpoint and it has no lines I will basically straight out reject it can be an architecture right because the purpose of Architecture is to yield some properties of the system these properties of the systems are a function of How It's put together so if you don't show me how it's put together this is unlikely to be a useful architecture so you can take this away we once gave a training for top Executives like CEOs CFOs because our CEO wanted them to be more I.T Savvy and this is one thing we taught them is If somebody walks up with some architecture picture that has no lines you know even if you don't know much about it you can just raise your hand and say I don't think this is an architecture because there's no lines in there so be careful the word the word is spreading make sure your architecture pictures have have some lines in them right and we we did this we did this seriously so behold the lines right give the lines you know their fair credit lines are important abstractions right so we deal with a ridiculous amount of complexity and usually and your point went and back exactly there is so usually the way we conquer this complexity is by by using abstractions right now when we see an architecture picture it's almost always an abstraction it's a model of reality because the real architecture is only in the system right and that's how we know every system has an architecture right you cannot build a system without an architecture because it inherently has one the question is do you consciously want to choose which architecture has and there's many nice papers like the big ball of mud Etc who makes the argument that if you don't choose you usually end up with one that you don't particularly like so there's always an architecture so the rest is all viewpoints now why do you make these viewpoints well you make these viewpoints in order to make a decision or improve your understanding right why else would you make this right it's not an art class right like like here right yeah Pollock very nice right it's not an art class this is architecture it's there to help us make better decisions or answer some questions so when somebody comes with an architecture picture first check you should do is other lines and the second check is well what question is this picture answering right why you made this picture like what decision does this help me made what question does this help me answer and if that leads to a lot of ho-hum like then you know something is wrong here because why did you draw this picture as I said it's not art class we draw pictures and abstractions because we want to answer questions and make decisions and what kind of abstraction you need depends clearly on the question you're trying to answer here's a perfect example right top left is like well what is sort of the easiest way to walk from Lower Village to stove wherever that is right it answer that question very easily and down here is what is the fastest way to drive from Atlanta to Birmingham different questions different Maps right and you can't say one map is good and the other one is bad so people came to me a lot as Chief Architect and say is this a good architecture or is this a good architecture diagram like I can tell you because I need to know what question you're trying to answer her and if that isn't clear we need to have a completely different discussion second part of this is all these models are wrong right the model is not this is not reality it's not meant to be reality right I guarantee you the freeway between Atlanta and Birmingham is not bright orange right it's also probably not two miles wide I mean in the U.S almost but not quite right this is wrong right it is there to hide some complexity to help you make better decisions and it's not about right or wrong a model has to be wrong because if it's completely right it would match reality and then it's no longer a model right so we always talk what is the top right what question does the top right model answer and this is you know how did Donald Trump win the election but then come to think about it I don't think it really answers that right so my one political joke for today let's go back to Enterprise architecture so this is a model many people use when it comes to Enterprise architecture so so this is a lot of these Enterprise architecture Frameworks they will give you a data model like this and the interesting thing is we talked about making connections between layers of abstraction and you can see this very nicely right you have business objects and business processes and at some point you have software device and network right and this lets you make things like oh do I have multiple applications for the same business function right or do I have business functions where I don't have an application right so these are tools and data models that people use in these you know famous Enterprise architecture tools to come this insights so it answers those kind of questions it answers the questions right do I have duplication do I have multiple applications for the same business function right or should I have the same application for multiple business functions right it's another very valid question so actually these tools are very useful the challenge with them is they often take off a live on their own so people put data into this tool no longer to answer the question but to fill fill out the tool and this is where this Enterprise architecture thing usually takes the wrong turn because people just start collecting information collecting information but if this information never helps you answer question your value chain is broken right you're not providing any value to the business sounds harsh because like oh my God I collected all this information well if all this information doesn't help you make better decisions or give you a better Insight unfortunately it has no value right so be careful with these tools right they're very helpful but make sure you know who's the master and who's the tool make sure you're the master and the tool is the thing not the other way around it can happen very easily where the tool takes over and you sort of basically become the the slave of the tool so third part so we talked about Connections we talked about abstractions now it's about making decisions right so here we have another simple test right I like making things very simple and the question is is this architecture so yeah 50 50 chance of being right so who says Yep this is a proper architecture okay or the third so we're saying no no no no no way okay it's about even interesting okay so ironically is when you look at the popular definitions of architecture and software architecture this will check in as correct right because the the software engineering Institute actually maintains a whole website with all the definitions of software architecture but it's always the components relationships constraints so this matches perfectly right the door is in the wall conveniently reaches the floor the windows are there the roof is on the top right all the components are there of their relationships and contains are clear and fulfilled right so yes this is architecture however don't forget we're in a business right and in the business the question is less about is this architecture but the question is much more about would you have paid an architect for that and now probably in the hands you know not so many hands are going up well why not because there are no decisions here there's no meaningful decision this is absolute cookie cutter off the shelf right there's nothing in there versus if you look at this house which is almost identical there it would flip right now here's a conscious decision the roof is much more pointing that's because it's in a cold climate right it says it reduces near the the pressure from the snow it snows a lot snow is very heavy it can either crush your roof or at least make your house leave a leak so what you do you make your roof pointed because your gravity is one of our most renewable resources right it's like you know stuff works very well you know gravity takes the snow off and of course you don't want the snow to go off the roof and come back through the window so you make a nice overhang left and right so the snow goes off and I would say that's enough to make this flip like good architecture doesn't have to be sort of 100 pages of complicated stuff it's a few key decisions that are there that makes a difference between sort of meaningful architecture and not meaningful architecture now of course somebody could have been super clever and say everything has an architecture so even this one would have been an architecture and the other clever thing would be to say it can't be an architecture it's only a viewpoint but yeah I made sure my storyline went quick and that nobody can inject that so next time you can bring the case and say it's just a viewpoint coming back to the decisions though right decisions that don't have a cost are not very meaningful one of the worst things you can hear in an Enterprise when you propose something is oh yeah that is really important right that's about the worst thing you can hear because saying that is really important doesn't cost anything right people have the job of going in a lot of meetings and only saying yeah that's really important right and unfortunately people do make a career out of this right does happen but that's not a commitment right that is not a meaningful decision it's not a meaningful decision I like George Fairbanks point of view a meaningful decision is we know what's a priority so there's a principle behind it there's something we want and therefore we choose design X or we choose design Y and we accept downside that like a decision just doesn't have any downside is likely to be not a very meaningful decision so for example with a pointy house what is the downside of the pointy house well Ikea won't sell a lot of furniture for your upper floor remember because your wallets are like this right so there's a downside of this and you might mean minimize their downside by saying oh I built My Own Furniture whatever it is right but in the end and a decision should be driven by clear principles and it should have a downside if there's no downside right there's nothing to decide so this is easily forgotten and the next one on decisions is in a large Enterprise it will never be easy to make a decision there's a lot of fussiness and uncertainty and complexity so you need to divide and conquer and you need to find something where you can focus right and start making some decision you cannot boil the ocean people often came to me and said oh did you know the people over there are doing XYZ and I'm just like yeah yeah I can't be bothered like oh you're the Chief Architect right they're doing something that's not the standards and I'm just I need to pick a Focus right if you start skirmishes everywhere you just get lost in the Enterprise so you need to find one part where you can focus and you can really only then if you divide and conquer get to get to measurable outcomes right if you start acting everywhere boiling the ocean will not work you need to pick some something where you can make an outcome because that's the only way a you create business value and B you can get feedback right if you're always starting some of the meta stuff everywhere you will never get the feedback whether this is actually works now there's some people who like doing that but I don't call them Enterprise Architects I call them like charlatans or something right sometimes we call them Consultants right also happens coming to the end right so hopefully I've shown that solar Enterprise architecture is actually quite a bit to it the amazing thing I always find is there's no black magic right it's about having the right models understanding what we're trying to decide evaluating the options following the value chain right it seems all like you know we don't need a PhD in Enterprise architecture to follow this however people so easily get lost in the complexity right all this happens in a super complex diverse domain it's a moving Target and that is the real challenge so I feel the main reason often this doesn't work very well is not because you know people don't understand what they're trying to do is but In the Heat of the battle with all the complexity they lost they forgot where they are in this thing so it's really kind of a discipline is it's kind of about having the discipline to come back to your sort of good Common Sense understanding and not forgetting where you are and what you're doing and not allowing yourself to get lost in either the tooling or into the complexity last thought on this right we talked a lot about architecture and how we're having different viewpoints and distractions makes you in the end be be in bed architect or do better architecture I think the same is also true for your career so I had quite a diverse career I spent a lot of time as a consultant right so all consultant jokes decide right I worked in Internet you know soft engineer at Google and worked in corporate I.T right so I've done many I've seen many different viewpoints and I think just like when we look at the architecture of a system having different viewpoints really helps you reason about it and I think the same is true for the world of I.T right I think having these different viewpoints having seen a large corporate I.T from the inside out having seen the internet giant from the inside out how they haven't seen a lot of organizations and the Consultants that is also putting different viewpoints together and I think in the end this makes for for a really interesting career and if you have the ability to make those kind of connections right if you have the ability to have these different viewpoints and make these kind of connections there's enormous career opportunities there for I.T Architects and you will never have to be ashamed to carry the title Enterprise architect because in this case you'll be providing enormous business value and the demand for those folks is extremely high so with that positive thought I would leave you for the rest of the event if you enjoyed the stories there's a book called 37 things day four is right I gotta write five more to make it 42. so there's a book called 37 things one architect knows about it transformation a lot of stories anecdotes and opinions about about you know what do Architects do in a large Enterprise so thank you very much enjoy the rest of the show thank you