simon-rohrer-modern-enterprise-architecture-architecting-for-outcomes

[00:00:25] at home when we do that. Okay folks, let's go. I can assure, uhm that's all the French you'll hear for me as well.
[00:00:39] Does it work? Uh, welcome everybody. Uhm, what an awesome conference. Thank you so much to Evelyn and Kenny, um for their cognitive scaffold with five things in it. I have another one. which is entirely coincidental. Uh, I'm going to talk about architecting for outcomes. Uhm I am Simon, briefly on my journey uh in the last 32 years. Now I started as a developer. I'm still cutting code a little or now these days I'm letting my agents cut code for me, occasionally I review it. Uhm, relatively early and I was discussing this with a friend at about like my mid-20s, I was doing enterprise architecture. Uh enterprise architects are meant to have gray beards, but I'd managed somehow to to be doing it relatively early. Uhm, I did that for quite a long time. Uhm, I was chief architect uh um for wealth management at Barclays in the UK. Uh and then in 2015, I got a chance to work with John Smart. There was an Agile transformation program, if those of you who remember in 2015, they were very on trend. Um and I got a chance to join the group Agile transformation program at Barclays. I'd been a passionate agilist since I picked up the XP white book in 1999. So I um joined as an Agile transformation lead. We then decided, um and this is important for the talk, that actually Agile transformation was not focusing on outcomes. So then it transformed itself into Agile adoption. Um and then actually we decided it wasn't Agile at all, but we were looking at it was ways of working. Uhm and then in um in 2016, Britain uh where I used to live did a very weird thing. Uh as people remember 10 years ago, um Britain voted to exit the EU. Uh what a strange thing that was. So I decided to uh exit Britain at that point. Uhm, and now I um now I work in Copenhagen in Denmark. Uh and I've combined my uh two previous career roles in a job title that I invented for myself, but I I love which is uh head of Enterprise architecture and ways of working. Uhm, and when I was working with John Smart uh in London, I got invited to co-write a book called Sooner Safer Happier. Um maybe one or two of you have read it. Um we're pretty proud of it. So this is modern enterprise architecture and it's about architecture within a modern enterprise. What do we say when we mean a modern enterprise? Well, it's a lot of people, it's teams of teams of teams. Uh, it's uh interacting with your customers digitally. That's that's most of the world right now, I think. Uh change is a constant. Um, it's a it's a much mix of systems. So your uh technology is typically uh heterogeneous mix of off-the-shelf systems, of things you've bought or built yourselves, things that change in a slow and fast way, there may be some monoliths, maybe some distributed monoliths and some microservices. Uhm and a a nest of systems, so not ones that stand alone and deliver micro products, but typically you have fairly sizable products that are systems of systems of systems. So my take, my five element cognitive scaffold for modern enterprise architecture, it's an ABCDE. Uh it's aligning and cohering people, value and technology. This used to just say aligning. Uh but I got hit twice on this, so it's now aligning and cohering. Uhm, the first was by Diana Montallian who the first time I gave this talk, the talk immediately before, Diana said uh in the systems thinking community we don't like alignment. We use coherence. Uhm, Sin also uh in her talk yesterday and uh and back in Berlin talked about the discrepancy between alignment and coherence. So I'm going to talk about why it's both. Uhm for B it's a better value sooner safer happier which is the full name of Sooner Safer Happier, it's the five outcomes. Uh and again this is about architecting for outcomes. Uhm C is about continuous and conversational. Uhm and how architecture is not this one-off process and how it is a collaborative process, echoing Evelyn and Kenny talk about. D is about DevOps at enterprise scale. Um several architects or more traditional architects I talked to think of architecture is about Dev and it's about the early part of Dev and it is not. And E is about evolution, evolutionary enterprise architecture.
[00:05:40] There will be plenty of reiterations of this, so you can take a pick later, but I'll move on. Uhm, so a bit of wayfinding, um where are we? Uh again, I started my career back in the 1990s. I remember the uh Netscape Navigator browser coming up on my Sun Microsystem.
[00:05:59] Uhm, I read later the Standish Chaos report about how 70 plus percent of software projects failed. Uhm, in '95, the first paper on Scrum was published. In '99, the very first, did anybody, is anybody old enough to have had one of these uh Nokia 7110, the first Wap Internet connected mobile phone, commercial one. Uhm and in '99, the book that genuinely changed my career came out, the Extreme Programming white book, the first edition.
[00:06:33] And since then, uh as Mark Andresen, and I'm not the world's massive fan of Mark Andresen, he's a strange and very far right man these days, but he said software ate the world. And to a huge degree that's true. Uhm and a paradigm shift happened in how we developed products. Back in the 1990s, we had this very phase and silo based way of developing products. We would plan for months and then hand a bunch of documents over the wall and we'd then maybe uh we'd do some build, maybe some code, some design, maybe even the design was up front, and then we'd hand it over to yet another team who would typically be quite squeezed that had planned to test for months, but the code would come late and so they'd maybe have a couple of weeks. And then we'd hand it over to yet another team who would then be tasked with working out how to release this stuff into production and then another poor team would get to operate this maybe forever.
[00:07:42] And lots of things happened, not just Agile, but DevOps, cloud, systems thinking, a whole bunch of practices that had they weren't actually brand new in the 90s, they'd been being developed since the 60s. But they came much more into the forefront of of use. And then we got our our friend the the loop, the DevOps loop. And instead of taking uh months or years to go from concept to cash as as Chris was talking about yesterday, we could we could get things live in days or even hours. And instead of having multiple teams, we have a single team that's capable of and enabled to do that entire loop themselves.
[00:08:30] And this takes us from just a single project mode to what McKersten says this journey to product. Software is never done.
[00:08:41] But not everybody noticed and in particular a lot of the people in my profession of enterprise architecture are still thinking in this sort of very phase-based way. So this is advice for those of you who work with enterprise architects or maybe some of you even are, to move away from the phase-based thinking.
[00:09:01] Uh a bit more wayfinding. Uhm, complexity in the what we might call legacy, but effectively the existing system landscape especially for those large modern enterprises I talked about start to dominate the pace of change. This is a diagram from a guy called Roger Sessions. Um and when I talk about Roger Sessions, he he was a superb writer on enterprise architecture and very practical enterprise architecture. He's now retired, he moved to Mexico, he runs a meditation retreat. That is a lesson maybe for all of us in technology. Uhm, and Roger Sessions wrote an awesome book back, um God, nearly 20 years ago now, about simple architectures for complex enterprises, and he sort of pre-invented microservices, his concept of boundaries based on both the team and the software and the business problem. A bunch of patterns and principles for that, but not everybody, in fact next to nobody picked this stuff up. And so our problems are similar but different to those of the 90s, um where Dan North talks about how we picked up this civil engineering metaphor of how we should build software and it was it was the wrong metaphor.
[00:10:24] But in the 2020s, we've got complexity uh where we need to use these project management techniques to orchestrate these overly complicated things that we've built. And back to Roger Sessions again, he says enterprise architecture is key to do this. And I'll try and sort of back up this argument, he says complexity is the enemy and enterprise architecture is the only solution.
[00:10:53] Uh a quick word on complexity here, uh anyone Cannevin, familiar with Cannevin, of course, nearly everybody is. So when Roger Sessions and some of the other people I quote talk about complexity, they're probably talking in the area of complicated and complex. Some of these things and uh both Sin and Bear Riley talk about how technology itself, just the technology, is probably only in the complicated space, but once you start adding people into the equation, once you start getting sociotechnical, that's when you start getting more complex. And people are nearly always in the equation. Okay, back to our uh little framework, our ABCDE. So aligning and cohering people, value and technology. I'm not even going to ask because everybody knows Con Conve's law of course, of course. So roughly, very, very roughly is that organization architecture drives system architecture and I know the stuff about it's the communication uh structures of communication drive the system architecture. And Ruth Malan, who I adore, worship, Ruth Malan, um she says if the architecture of the system and the architecture of the organization are at odds, then the architecture of the organization is going to win.
[00:12:15] But uh Alan Kelly makes an awesome point as well. He says where all hell really breaks loose is where management decides to reorganize things. You try and change the organization, but the software is not going to let it happen. He talks about how you know trying to get mainframe engineers to split up into into teams and it's just it's just not working.
[00:12:38] So then the system architecture is driving the organization architecture. How do how do we reconcile these things?
[00:12:48] Again, back to my uh my home country, the UK. In the 1940s during the war when the House of Commons in the UK got bombed.
[00:13:00] Uh, there was an offer to rebuild it in a a slightly different way. So for those of you who know the House of Commons, it's built in an adversarial way. There's one set of benches facing another set of benches and apparently it's two swords lengths apart. Um, incredibly adversarial.
[00:13:19] And there was an offer to say, look, the modern way to do this is in a curved chamber like so many of the European Parliaments. Let's do that. And Churchill said no, I like the way that this is adversarial. We shape our buildings and and they shape us and how we work.
[00:13:37] And so Jim Kim has taken that quote and applied it to architectures as well. And this I think talks about that feedback loop. Well, of course, the on blank sheet of paper, we shape the architecture and Conway's law applies one way, but then the architecture shapes us back again. It's a feedback loop.
[00:13:57] Like this. Uhm and recently, uh I saw James Coplin do a talk and he said uh Grady Booch and him were arguing on Twitter. And Grady Booch thought it was one way and thought that Mel Conway had only implied that organization architecture shapes system architecture. And Jim Coplin said, no, it's definitely two ways. And so the two of them went to Mel Conway. And Mel Conway said, yeah, of course, I always meant it was bidirectional. and this I think talks about that feedback loop. Well, of course, the on blank sheet of paper, we shaped the architecture and Conway's law applies one way, but then the architecture shapes us back again. It's a feedback loop.
[00:13:57] Like this, um, and recently, uh, I saw James Coplin do a talk and he said, uh, Grady Buch and him were arguing on Twitter. And Grady Buch thought it was one way and thought that Mel Conway had only implied the organizational architecture shapes system architecture and Jim Coplin said, no, it's definitely two ways. So the two of them went to Mel Conway. Mel Conway said, yeah, of course, I always meant it was bidirectional.
[00:14:29] Back to Beth Mallen again, she says system architects who we call architects and organizational architects who we call managers shouldn't work as if they have no impact on each other.
[00:14:42] So this is this feedback loop and and again, typically in organizations, it's back to the silos. The organization architects, the managers are the ones who design the team structures. And the systems architects are the ones who are meant to design the systems. They have to work together to get efficiency. And then, of course, there is another angle to this. Gregor, who um, we last saw in Berlin, but he's not here, Gregor Hopy, I hope everybody has come across Gregor and his amazing work on the architect elevator. He talks about how enterprise architecture is is the joining of business architecture and technology architecture.
[00:15:24] And then in the sort of modern world again, in these recent Agile transformations, you've had business architecture try and shape the organization architecture, reorganizing people into value streams or tribes or whatever. Boston Consulting or McKinsey want to call it this week.
[00:15:44] So, it's not just a two-way feedback loop, it's this sort of interaction between these three elements. Hence the triangle against the A, you've got organization architects on one side and system architects and again, if this is going to work well, there needs to be a collaboration between them. I'm thinking about how all of these three interact.
[00:16:09] So really for sustainable flow, this is a conference about flow.
[00:16:13] This for me is where the alignment and coherence start to come in. Your value, your organization and your technology and processes, you need a large degree of alignment in order to achieve sustainable flow.
[00:16:31] What does that look like? Well, the team is the unit of delivery.
[00:16:37] So, this talks about an ideal two pizza streamline team for those of you who are team typologies fans and Amazon way of working fans.
[00:16:48] A very short digression, uh, right now, uh, with a friend, I am working on a presentation for the fall, um, on what AI does to two pizza teams. I'm really looking forward to this, it's going to be such an interesting talk. There is talk about two pizza teams shrinking to two people, uh, an AI Wrangler and a product owner. I don't think that's the case. This talk about one pizza teams and the sin talks about this. This is such a fascinating area, but why we still have teams that are dominated by humans, then a two pizza sized team, they own some value, some element of value. They're a two pizza team and we can discuss numbers until the cows come home, is it four, is it seven plus or minus two, is it less than 20? It's some relatively small number of people and maybe people and agents. And it's what Don North started and then Matthew Manuel from Team Topologies extended to software that fits inside the team's head.
[00:17:52] So it's eventually consistent, it's again great, um, presentation by Matthew Manuel from I think 20, 18 or 19 called monolith versus microservices missing the point. It's about the team ownership and the team understanding of the software. And it's this DevOps loop, I think it's some uh Newman called microservices the first DevOps native architecture because. The point of this is distributed systems are hard, Martin Fowler used to say sell your grandmother before distributing objects. But the point of the distributed system here is that it makes it easy for the team themselves to own the entire operational life cycle and not just the development of the software. And back to Roger sessions autonomous business capability.
[00:18:40] What does the full burrito mean?
[00:18:43] Sorry.
[00:18:46] Full burrito.
[00:18:48] Full burrito. Uh that is a quote from Martin Fowler's article on team topologies. So he says, uh it's the full the full life style the full stack uh and the full life cycle. He he calls it the full burrito. So effectively the team should be able to do everything. Front end, back end, database. Yeah.
[00:19:11] Um, nobody knows where this comes from, um, and I sort of skip over it these days because there's a hell of a lot of posts actually saying this is nonsense. Not everybody needs to talk to everybody all the time. But this is effectively why you want to keep your team relatively small because of the overhead of intercommunication. The more people you add, the sort of exponentially more communication paths you add.
[00:19:35] Uh, Martin Fowler again, so who does architecture talk about architecture, who does architecture, um, well, the team themselves do the architecture, they own the architecture. Um, and um, just before I wrote this talk originally, there was a uh post on social media that said, uh, I'd like to do a conference basically on the theme of Martin Fowler uh solve this problem 20 years ago.
[00:20:04] Uh, so about 20 years ago, I think it may even be longer, Martin Fowler wrote two what I consider very similar articles. One called who needs an architect and the other called is design dead. But the conclusion of the two of them basically is that the team needs to own their own architecture. He talks about the extreme programming coach role, uh, as opposed to the sort of matrix style, know it all architect. The point of the XP coach is not to be the architect, but to facilitate architecture with their experience within the team.
[00:20:39] And that's awesome. But no team is an island. And again, within our modern enterprises, um, there are very few organizations where one team is delivering one product by themselves, typically they need to collaborate. And there is some kind of coupling and Vlad Honov's book on balanced coupling, this is extremely pragmatic book. That says well coupling by itself is not necessarily bad. It's the degree of coupling combined with the distance between decisions that is something you need to keep an eye on. So of course, in your modern enterprises, you will have a team of teams and this starts to get this self-similar fractal nature where of course the team of teams also owns something of value. And again, being skeptical of numbers, 150 is the Dunbar number, but again, people are throwing rocks saying forget the Dunbar number, it's uh, it's close close close to meaningless. But it's team of teams, which is a some number above the two pizza team.
[00:21:46] And again, this is a system of systems and these teams need to collaborate and they need to converse. And again, back to sins thing, we can decouple, um, we can decouple technology, but we have to connect people.
[00:22:02] And again, the system of systems and a domain somehow here that fits inside the team's head.
[00:22:12] And, um, again, self-similarity of fractal here for the enterprises, certainly the ones I'm used to working in, in places like financial services, with a line of business, typically you are talking about teams of teams of teams. And of the order of sort of several hundred up to a up to a thousand plus people collaborating doing the same thing, whether that's wealth management or credit cards in in my kind of space. Um, but then you're at a real sort of system of system of systems level. Does this fit in anybody's head at all? And what I say here is, typically not, but what does fit in the head of the people who are operating at this level is the organization. And who knows what. So it's a sort of level of indirection. Certainly that I try to operate at. In my world, I don't know every detail about the payments element of the system or the pricing element, but I know who knows, and I know who to go to talk to.
[00:23:19] Um, and David Woods, um, talking about, uh, sort of error catching within complex, and again, this is probably complicated rather than strictly complex. But David Woods says, look, as as something as this complexity or complication increases, the accuracy of any single agent, so your God level architect, uh, the accuracy of the their model of the system decreases rapidly. So instead, you have to trust, you have to trust others and know who to trust.
[00:23:53] Uh, back to, uh, back to alignment versus coherence. So Ralph Stacy talks about how organizations are intertwined order and disorder.
[00:24:07] Uh, and that typically managers try and bias themselves towards order rather than disorder, but they need to be able to cope with both. So for me, when we talk about alignment and coherence, the alignment side is more about the ordered side of the organization. So again, for me, working in financial services, I have to work with regulations a lot. They are pretty ordered. And so when I'm trying to work with people and get them aligned, that's typically on that sort of ordered side of the, um, the organization. But, of course, there is disorder, you can't get people with this sort of pretty alignment. Back to sin's slide, alignment is pretty and that's great for certain uh problems and situations that are ordered. But coherence is not, it has this alive nature. And so for for me, in that Stacy model of ordered, intertwined, order and disorder, you you need a degree of both.
[00:25:11] Uh, and finally for the A, uh, back to, uh, back to Conway again. He says ways needs to be found to reward design managers for keeping their organizations lean and flexible. And a philosophy of system design management, which is not simply based on the assumption that adding manpower adds to productivity.
[00:25:31] Cool. So what's the point here? So you're aligning as an enterprise architect value, people and technology, all three in the triangle.
[00:25:44] Lots of organizations try and do this bilateral alignment where managers will try and align value streams and organizations and enterprise architects try and align business and tech, and it's all three or nothing.
[00:25:59] Cool. Uh, onto B, better value sooner, safer, happier. Um, there's an anti-pattern here of traditional enterprise architecture outcomes around standardization, consistency, and predictive planning, um, and and cost reduction. And uh as the man says, these are not the outcomes you're looking for.
[00:26:20] Some newer ones like uh let's move everything to cloud or Kubernetes or microservices or AI. These are not AI, these are not EA. Yes. biased mis yeah, mis speak there. These are not the outcomes you're looking for either. And what we talk about in the book is this balanced scorecard of outcomes. Value is in the center of course, and value is what makes you you, what makes your organization special. But you should balance those with better, sooner, safer and happier. Better is quality. Sooner is what we're talking about here, it's flow. Safer is agile not fragile, it's building in security, privacy and if you're a regulated industry, which again, most people are these days, it's minimum viable compliance. And happier is concern about your customers, but not just your customers, also your colleagues, your citizens and the climate as well.
[00:27:19] And these are the balanced outcomes that I think we should be looking for across the board. Back to Jean again, uh, we shape our architecture, then our architecture shapes us, but he goes on to say, as the systems we build become larger, the coordination increases and it can grow so that just our spend time is spent coordinating rather than delivering value.
[00:27:40] So we want to try and avoid that.
[00:27:43] Um, and this is a bit of sort of architecting for flow in things that I have seen, patterns that I've seen recur over and over. We've got um, concept to cash again, we want to optimize that. But we've got this legacy architecture where we have a team looking after the UI, a team that builds the APIs, a team that builds uh, a greetings service and a team that builds a planet service and another team that looks after the database. To do that, you need a team outside the teams to do the solution. How do we distribute this concept of Hello World across these teams? So we give hello to the greeting service, we give world to the planet service, uh, we give a little slash API to the API layer and the UI adds some Chrome to it. And the DBAs have this weird naming convention for tables that has to begin with T_ and then it gives you two letters, so it's T_H W.
[00:28:50] Uh, and then after a few months of developing and integration testing, we get something that says Hello World, which is close enough. It's not a showstopper defect, so we can go live with that. Testing team happy. We'll fix that later. Um, that's not optimal, it's really not optimal for for something that we could do slightly differently. And uh back to Gregor again and Gregor says, layering is sometimes considered harmful, it is a bit of an anti-pattern.
[00:29:22] So here we can and I'm told this is not refactoring. Dave Thomas told me off for this. It's restructuring. We restructured both the organization and the architecture like we learned, we worked together. The managers and the architects and we say, no, actually one team can own all of this. This is a new world where we can have a full stack, full burrito team who can own the user interface, they can own the business logic, they can own the database. It's not hard to change databases these days, we have the technology.
[00:29:56] And so the time from concept to cash and the time to change, it's reduced massively because well, we've not just changed the technology, but we've reorganized around this better way of architecting.
[00:30:12] And, um, there's a great presentation from Enterprise Technology Leadership Summit about how coordination costs are killing your effectiveness. To actually give the the numbers, the economics behind this, reducing the coordination can radically change both your risk profile and also just the cost of change. business logic, they can own the database. It's not hard to change databases these days. We have the technology. And so the time from concept to cash and the time to change, it's reduced massively because well, we've not just changed the technology, but we've reorganized around this better way of architecting.
[00:30:12] And, um, there's a great presentation from Enterprise Technology Leadership Summit about how coordination costs are killing your effectiveness to actually give the the numbers, the economics behind this, reducing the coordination can radically change both your risk profile and also just the cost of change.
[00:30:36] So, back to outcomes and particularly focusing on flow,
[00:30:42] we would advise as authors of sooner say for happier, that you focus on these outcomes. Better value sooner say for happier is a balancing set, rather than the sort of again traditionally EA outcomes that were just looking for cost reduction, we're just looking for standardization for its own sake or duplication. They're maybe good outcomes but not for their own sake.
[00:31:08] C is on continuous, continuous and conversational and automated governance. So
[00:31:16] why governance? Well,
[00:31:19] creating and reducing complexity might sound like opposites, but they're not. They're asymmetrical. This is a Harvard Business Review article. It's not to do with technology at all. It's just just to do with business in general.
[00:31:31] So architecture governance is a very traditional way of rescuing this and saying, no, we need to review everything, we need to review the hell out of the complexity to make sure it doesn't happen.
[00:31:43] But architecture review boards in the modern world, in the uh, the situation we've been talking about is it's an anti-pattern. We used to do architecture governance again in the sort of 90s. Are people still doing it like this today? In this sort of waterfall or agile or water scrum fall, we have a project life cycle where we initiate, plan, execute and close, and then we have a parallel tech life cycle where we do analysis, we initiate, we do design, we do build and test, and then we release, and then we're done.
[00:32:20] And that sort of was great for the promoters of architecture review boards because you had a slot for them at the end of analysis, you could review an artifact. rubber stamp it and say that's awesome. and the same you'd get an even better, more detailed. This is exactly what we're going to do going forward, rubber stamp. That's great. Cool.
[00:32:44] As soon as you start to work in an agile or lean way, where you're doing these things in parallel, you're planning and executing continuously. maybe eventually because again, it's still a project, you're going to close. For sure you do a tiny bit of upfront analysis, but you're again continuously analyzing and look, you're releasing early and often.
[00:33:10] So, where does your architecture review board sit? Well, you could try and do it at the end of initiate, but you've only done a bit of analysis. What are you rubber stamping at this point?
[00:33:21] You doing it here? You've already released two pieces of software. You've already done your risk here. So this entire concept of again waterfall silos, gates, gates in particular and phases have gone. And so the architecture review board does not align to this at all.
[00:33:37] And certainly once you're moving from project into product, it's it's simply not possible. So, we've got a couple of patterns here.
[00:33:51] this complexity that Roger Sessions talks about, it is stuff you can look at early. I need a new service. So for us, our enterprise architect says, well, great. You think you need a new service, let's have a conversation about it. This is going to add complexity, it's going to add complexity over the long term.
[00:34:11] Could you do this another way? Could you expand something you're doing already? Do you even need to do this? If you do, then awesome. You can do that.
[00:34:22] Connectivity, if you remember the spider diagram at the start from sessions, connectivity is a it's a complication. So cool. You need to connect to another service. Um,
[00:34:35] awesome. Let's have a conversation about it. Do you really need to do that? Should you really be doing this data yourself? Is this within your own boundary? Great.
[00:34:45] Automation here, pretty much automation and governance on demand, not rubber stamping a design, but rubber stamping what's actually there. And we have paved paths if teams want to do stuff that follow the golden paths. That's cool. It's pre-approved for them.
[00:35:05] Sorry for those taking photos. I will put the link out later. And conversations are key here.
[00:35:15] So governance is sort of in quotes here because this is more about collaboration than governance at this point.
[00:35:23] So great, we have an idea up here, but the teams are having this sort of continuous conversation with our architecture community of practice. This is very similar to the architecture advice process that Kenny talks about, that Andrew Hammarlaw of the book about, this isn't the hierarchical view, this is conversations with your peers about whether this is the right kind of thing to be doing, hopefully doing some debiasing here.
[00:35:53] Um, and honestly this is the only way you can work if you've got a continuous product again, there are no gates, no phases, there is no point at which you can stop and say, great, tell us the things you the only things you're going to be doing going forward.
[00:36:09] And the scales as well, this happens across value streams. We have the architecture community practice. For us, we have a tiny central architecture team. We don't tell people what to do. We talk talk with them about what they are going to do.
[00:36:27] And platform engineering is awesome here too, especially when you have regulated industries when you need a aligned view about some of your checks. Charlie Betts uh writes brilliantly about this. He says in a properly executed platform strategy your architecture and security checks have happened because they're all baked into the platform. And a checklist you might have had to fill in for your security colleagues, for every release or for every new piece of software, it's dumb. Or at least it's 90% done.
[00:37:03] And the path forward here Charlie talks about is the stakeholders accept a level of standardization and the architects are not standing in the way of progress and they never should have been in the first place.
[00:37:15] So, C is continuous, conversational, as automated as possible, instead of this sort of legacy way of assuming that you have phases that you can gate, that your governance is about documents, and it's adversarial.
[00:37:33] D is DevOps at enterprise scale, so taking on that idea of continuous conversational governance.
[00:37:42] The entire point of your architecture function is to enable this loop to be happening at the enterprise scale.
[00:37:51] Which of course has a much higher scope than the teams, it's a coherent system of systems of systems, it's a coherent set of products. And things are happening over a longer time frame as well, so teams are delivering as quick as possible, but there is change going on in different cadences in the organization as well as that.
[00:38:15] again back to this alignment.
[00:38:18] Um, certainly for me and what I advise enterprise architects is they do not live in a silo. Some of my closest stakeholders work in service management and this is an anathema to traditional enterprise architects. What are you doing even talking to service managers? You're not involved in the same kind of stuff. But if you as enterprise architects, modern enterprise architects, care about the loop, then well, you're reflecting on what's in live as well. Again, this is Ruth Malan's diagram that I've augmented a bit. You're looking at intention, but then stuff gets deployed and you reflect on that and you feed it back.
[00:39:00] So one of the tools me and my team use most is observability tooling. We look at what's going on and we don't just look at one single subsystem or microservice. We zoom back and observe what's happening in the entire enterprise. This gives us knowledge that we couldn't get just from looking at design documents, of course not.
[00:39:27] John Cutler uh talks about this uh about how a sort of uh ultimate way for teams to operate and there's a lot of asterisks around this but an ultimate way for teams to operate is to collaborate on everything from opportunity selection all the way through build test deploy and run.
[00:39:50] And for me, you add the two together. You add the DevOps loop, the team, to this, you build it, not just you build it, you run it, but you everything it, you everything it. You dev it, you build it, you change it, you operate it, you run it, but also you're doing the business, um, selection here as well. So it's it's BizDevOps taking to the extreme.
[00:40:17] So then again, modern enterprise architecture is DevOps at enterprise scale. It isn't the traditional enterprise architecture architect focus just on change, not run, on dev not ops, and on project not product. You are as an enterprise architect continually going around the loop.
[00:40:35] Finally, evolutionary enterprise architecture, curating the evolution of the enterprise architecture and the organization. calling back to the start. Uh, evolutionary architects, um, Nick Ford, Rebecca Parsons, Pat Kua, and Hamid Savaj, have been talking about this for, well, as long as I can remember, about 20, 20 plus years they've been talking about evolutionary architecture. Um, and there is an awesome ThoughtWorks podcast when Neal Ford is talking about this.
[00:41:06] Um, and talks about how it gets actually really quite hard to build the fitness functions that these folks talk about once you get beyond an individual system, an in-process system.
[00:41:21] And we talk in sooner say for happier about two theories of actual biological evolution. The original sort of Darwin type theory says evolution happens on a gradual scale and happens continuously. Theory number two came a lot later, said, no, actually everything stays pretty much the same until something like an asteroid comes along and destroys a bunch of flora and fauna, and then a big change happens and then stuff stays the same for a while again.
[00:41:55] Of course, both of these theories are true. It's a bit of both. So there is some gradual change happening continuously. And then occasionally there is a massive change caused by some huge event. And for me, we need to take inspiration for this in our organizations.
[00:42:17] So we have to pay as enterprise architects and just as leaders, continuous attention to complexity debt, and pay this down. So this is where we advise sort of 20% to 30% of a budget
[00:42:35] for teams to be paying down debt. Paying down complexity debt, technical debt, even organizational debt.
[00:42:45] but also that isn't going to solve all your problems. Occasionally, you need to fund a massive step change. This is where you might want to start doing architecture modernization, the sort of stuff that Nick Tune is talking about. get an architecture modernization enablement team in. But you're going to need a business case for this, or maybe you stop doing this thing entirely. Maybe you've been doing some Wardley mapping and you've decided this thing that you were doing has now become a product or a commodity. And you don't need to do it at all. But this is the occasional big change combined with that continuous improvement and continuous change.
[00:43:28] And of course, Martin Fowler wrote about this 25 years ago. Again, uh, one of the best ways to do that is to adopt the Strangler Fig pattern. You're not going to rewrite your entire system of system of systems. So take it a piece at a time.
[00:43:45] strangle it, take it out.
[00:43:49] And this is what we do. This is my journey in the seven years since I did my own personal Brexit to Saxo Bank. When I arrived,
[00:44:00] I saw a system looking very much like this, a distributed monolith, with many, many databases, 1200 plus services, that was hard to change. And slowly but surely, we've refactored it. We've started to work with the organization and the systems to build them into autonomous teams that own autonomous capabilities. We haven't done it all. Seven years, we've got pretty far.
[00:44:27] But I will probably retire before we are done.
[00:44:31] And that's quite a way off as well.
[00:44:35] Keep going.
[00:44:38] Uh, back to Simon Wardley again, I I probably don't need to do hands up for this. Wardley mapping, anybody?
[00:44:44] Everybody, nearly. Cool. So Simon talks a lot, of course, about evolution as well.
[00:44:53] Uh, in fact, almost all of the, uh, strategizing that Simon talks about is about evolutionary movement, about how agile is strong way over on the left, about how you should start thinking about other methods way over on the right.
[00:45:13] And he also talks about his, uh, his principles. He says you must have principles. Here's ones you might want to take off the shelf.
[00:45:25] he says, do them in phases. And he says,
[00:45:30] start on phase one.
[00:45:33] Start focusing on user needs.
[00:45:36] So many people don't focus on user needs. So the the absolute basics. But way up in the top right in phase four, is my favorite, which is design for constant evolution.
[00:45:50] Because that's the world you're going to live in.
[00:45:54] Uh, we talked about the Chaos Report, the Standish Chaos Report about how 70% of software projects fail. Um, the Standish Group published one final Chaos Report about software projects that basically says stop doing software projects. Don't do software projects, just build. Move to product. We need to stop doing, uh, stop artificially breaking software into projects. Start running half a mile today, a mile tomorrow and that's how you improve.
[00:46:26] So evolutionary architecture is about continuous evolution,
[00:46:32] continuous evolutionary enterprise architecture rather than waiting for these big bang improvements and letting entropy go in. So our modern enterprise architecture again is aligning and cohering value people and technology rather than these bilateral alignments. Better value sooner say for happier rather than those old enterprise architecture outcomes. Continuous conversational governance rather than phase gating. DevOps at enterprise scale, rather than just focusing on change.
[00:47:03] And evolutionary enterprise architecture rather than entropy in the occasional big bang improvement.
[00:47:11] That's it. Thank you so much.
[00:47:19] I don't think we have time for questions, do we? We do.
[00:47:23] Anybody?
[00:47:28] No. No question.
[00:47:31] Oh, one.
[00:47:34] Did you ever experience situations where you start an architecture, it's extreme, and then after some time, you realize you need another transformation for that? So it's like two theme.
[00:47:47] So the question was, did you ever start a transformation and do the sort of Strangler Fig pattern type thing and then realize you need another transformation on top of that? Um,
[00:48:01] yes. You need to be continuously humble and not assume again that you have the Matrix style architect blueprint of how things really must be. Target architectures are awesome, but they're never frozen. And so design for constant change is the absolute key here, having that humility. Um, yeah, so yeah, yes, absolutely, just assume that's going to happen.
[00:48:35] Cool. Folks, thank you so so much. Have a great rest of day.

Transcript