00:00:08

Hi, good morning, some end Rora from Saxo bank in Denmark, Copenhagen. Uh, here I am head of enterprise architecture, as well as co-lead on the ways of working program. And I'm going to talk to you this morning about things about modern approaches to enterprise architecture informed by modern ways of working in agile, et cetera. So where have I come from? I started my career 26 years ago, not many years ago as a developer. Um, I learned Java super early, uh, was using that alpha, um, early on in my career, I picked up the extreme programming book back in 1999. I became an agile, passionate zealot gesture and development refactoring, and all those things. Uh, I was working for a consultancy as well. I worked as an enterprise architect. It was doing a lot of PowerPoint, a lot of word documents, strategy documents. I learned TOGAF group architecture framework.

00:01:21

I learned about the Zack framework as well. And I'm sort of passionate about those for a while. Um, my career swirled like a pendulum between developer more and more senior developer, more and more senior enterprise architect, and eventually ended up as chief architect for the wealth management division. And then, uh, I met John smart about clicks and he was starting up, um, what originally was an agile transformation program and I joined him and then we decided it wasn't really transformation. It was more agile adoption. We didn't want to transform people. We with people to pull agile and for them to adopt it with our help, uh, then we decided, well, actually it wasn't just agile. It was working meme systems thinking, uh, theory of constraints and the things as well. And dev ops, of course, uh, then, uh, late 2018, I decided to leave the UK. So I had three Barclays and I moved here to Denmark to succeed Lankan. Well, actually I combined my previous two things head of enterprise architecture, uh, and co lead on the ways of working program.

00:02:40

I read an interesting tweet last year, uh, just after I had an enterprise architecture, Grady, Booch, venerable, uh, suffer engineering Maven. I said, what is enterprise architecture? It's kind of like astrology for big enterprises, homeopathy for bureaucratic organizations. And maybe that should make me feel uncomfortable. I actually sort of what he was talking about. I'd read mark Schwartz's book a seat at the table as well. And he talks a lot about enterprise architecture will occur to him a fair bit. He sees EA folk are perceived as office dwelling, trolls manufacture constraints. They're perceived. They are combining people who are trying to be productive and they're perceived as a conservative wing that tries to keep everyone in line with old values. There's also a super interesting article from 2014 that says is enterprise architecture completely? Okay. Well, it's part of my career, so I don't really want to be an astrologer.

00:03:54

Um, I don't really want to be a homeopath. What are the alternatives to doing those things and to fix what is perceived as a sort of broken practice? Uh, what are the alternative practices to astrology and homeopathy law is one of the more in a way that it's the phrase, architects are used to be architecture governance, one of the practices of architecture governance in a waterfall, or sort of pseudo waterfall, watch our water's gone for these sort of hybrid waterfall, agile or really agile and tall. These practices, they sort of align software development with project management practices. So when you got the project management phases of initiate plan, execute and homes, they align in the software development, the waterfall software development practices of analyze. You do a lot of analysis, then you do a lot of design and then you do a test or that tends to get squeezed up.

00:05:02

And then you release and architecture. Governance has typically tried to find itself, uh, there between analyze and design and most commonly, uh, I've seen it. I saw it back at Barclays, uh, and I know other people as well, tried to say at the end of a design phase, well, let's do a design review. Let's get a bunch and suppose architects in the room where the project team can present and we'll sign off the design. We won't tell them they need to make changes to, and that sort of works in a waterfall world. What happens when we moved to a more agile? Yeah, sure. We initiate maybe projects, maybe initiatives that your business outcomes, clam continuously adapt or plans and execute and align with that. Continuous planning, maybe close it. If we're in a project mode, if we're in product mode, that stuff goes on for a long time.

00:06:03

And then yeah, we're going to do some analysis, but again, it's a continuous process test driven design testing, design, and build. We'll do that all day every day, release and release and release many times continuously, hopefully. So where do we do our design review? There's no design phase where you got anything to view here. We have had to quite a bit to review here, but we've released some software already. So what we're asking the wrong question was shouldn't be about a single design if the design evolves well, how do we work with that was a vision that the teams are going to have the delivery teams, and then really, we need to start having a conversation rather than acting as if we expect a big design upfront that we're going to rubber stamp need to work with the teams. If we've got things that we want to do and things that we should be beneficial for the organization for the longer term and quick, let's talk to the teams about how Y um, and let's try and do that in a community. Let's not try and be done. Let's involve the teams in the decisions, in the strategy and the long-term thinking as well.

00:07:29

So, no worries. Interesting when it comes to enterprise architecture, because there's one particular law that has been, uh, much discussed recently, uh, Conway's law, um, Mel Conway in 1968, made an observation that architecture follows organization effectively. Um, and that's the main bit of Conway. People recognize, understand that I've heard of in the same article. He said, well, quite architecture may follow organization, but like your hood is about design architecture design. You get first place is probably not best Mo we'll need to change it. And the implication there is not going to just have to change your design. You're going to have to flex your organization as well. Then you're going to have to reward people for being flexible and organization.

00:08:26

Um, if, if architecture structure drives organization and there's this sort of feedback loop where, uh, architecture drugs in organizational structure as well, and then you lay a culture on top of that and that constrains both of those, it gives them momentum. Well, it actually gives us quite a hard job to do as architects, because we've got to try and hack culture as much as anything else hadn't we can't just say, well, you need to build this new system because that's the way we want to evolve. You need to say, well, you're putting your organization to change. You might not have the house structures. You've had it in that stuff at Harvard, but it genuinely is it's X job.

00:09:16

And that starts to say, well, those design reviews starting to do. We used to do neither. Let's try and shift our influence left. If we're going to have conversations at the team level and looking slide a box of the things that the teams own, maybe we should trust the teams more to architect inside the box. Maybe we should be architecting more boxes. There are teams that are, how are those teams and boxes with components into that, uh, and start interacting earlier on in the process and actually start looking at talking to the portfolio managers about where they're managing, where they're allocating work to and start having conversations and investing in the right initiatives, changing the initiatives as well. A second profession, we went to look at inspiration from is evolutionary biology, and they'll forward her about Parsons, about cure, um, a few years ago now, uh, I wrote a book on building evolutionary architectures, agile software development talks a lot about emergent design and evolutionary architecture, and, uh, a lot of talk about this.

00:10:35

And then, then the book wheel evolutionary theory, um, it's gone a couple of ways originally, uh, evolution researched that you wish would happen with a gradual straight line. And then some iconoclastic you finish research came out and said, well, no, we don't think on the tool. We think that the fossil record says that you stay still for thousands, maybe tens of thousands, hundreds of thousands of years, and that when these events happen on volcano or update or meet your figures, and then rapid change happens, this is called punctuated equilibrium theory. And then as good academics do, uh, they came together and said, actually, you know what we're about? Uh, there was some gradual evolution. There is some rapid cultural evolution as well. And that to me is super similar to how we should be guiding the enterprise architecture. Some of that is going to be continuous improvement and continuous evolution of things getting better for better towards the leash.

00:11:55

I mean, it's been a, and that doesn't require big chunks of funding does require teams to be able to just stop looking at the end of their, uh, short horizons and start to turn, but teams really should be doing that. Anyway, Nick, Kirsten's talked a lot about how you should be pushing the time across, uh, picture work and technical debt as well as couple of work as well. And then there's the occasional step change, the step, changing your architecture when somebody decides they're gonna invest in a cloud program or replacements of the legacy system and both of these kinds of evolution to be guided and supported by your enterprise architecture.

00:12:45

And of course, aligns back to what we were talking about before with, uh, governance, governance of evolution, um, the continuous evolution you talk to within the teams and then one return, um, big step change where you actually need a chunky piece of investment to our, again, enterprise architecture should be making a case, should be advocating, spending the money on the one six back to the agile manifesto, continuous attention to technical excellence. That's the technical excellence that allows us to evolve over time and evolve just gradually continuous improvement, Kaizen, um, evolution, uh, really sweet. How old are those things called fitness functions? So as enterprise architects, what are we looking at for all of its functions for that evolution? As far as architecture, uh, accelerate has many, many good practices, uh, the practices that I think strive for continuous delivery, um, a lot of those are team level and we can trust hopefully teams to do as maybe support that we can trust the teams to upgrade. There are a couple sort of sit outside. The control of teams often be loosely coupled architectures, uh, empowered teams.

00:14:13

Uh, here's an example. This is not exactly what we've got right now, but it's something that looks a little like what we've got. It's something I've seen in a few places outside of the current role as well. It's interesting architecture. If we're trying to optimize the speed time to market and speed from concept to cash, uh, well, let's look at how our architecture sort of slows us back. That slows us down. Um, we've got a few components and the teams that run those components are user interface and API layer, a couple of different services that interact on a database, big monolithic database that contains a lot of stuff, a team operating a bunch of stored procedures around that. So what happens when we want to put a simple piece of functionality, hello world, through this, uh, system system of systems, or somebody has got to decide where functionality goes and which teams we ask to build it.

00:15:26

And so we have a team of solution architecture sets side of the routine, and their job is to say, great, we've got this new feature, how many teams, which teams needs to work on that? So we had an example in sex at blank last year where 17 different teams needed to cooperate to build just one picture. Uh, the solution architect said, great, you need to do this. You need to build that. Um, and teams typically are gonna need to cooperate as well. Um, and eventually that functionality or something that looks close enough to it gets to the testing team and customers and the starts, as you can imagine, uh, that takes a while. That's not Dave Follies one hour continuous delivery and concept to cash that's weeks or maybe months. So there's a couple of ways that you can start to look at Conway's law to start to optimize that.

00:16:29

What would be the easier thing to optimize is the organization. And it's where we are at least starting. So this is architecting your organization, Rumi factoring, the organization is saying great. That sort of functionality is not just a one-off sort of seems fast forward a few times. So let's get a virtual team together from you. It in the API team, service teams and the database team that sit them in the same room and take all of the features of that similar and get managed, work on epic to those components. They're still individual components and the teams on top of the ones who are sort of maintaining them on the term, but value stream aligned team. Well, they can be a bit more efficient. They're still sitting in the room, they're conversing on another deck, maybe over slack and these times, and that's a little bit more efficient, but it's still lots of inefficiencies as well. Typically, you're going to have to have things like release trainings. Again, you're not down to doing Follies one hour less between concept production, longer, longer term one, an autonomous team. You want them to own their own component, their own value. Um, and that's going to take some time. So we've, again, this is not the exact service we've built, but whether it be something similar, several similar things to this, uh, how microphone 10 in the microservice database effectively one component, uh, that owns that value on a team as well.

00:18:19

Is it good pattern? Martin Fowler described many years ago called a strangler fig pattern, mainly known as this pattern these days. It says what you don't need to do this as a big bang. And this can be one of those continuous optimizations where effectively you can eat the elephant one bite at a time. Um, you strangle, uh, applications, but you co-exist alongside them. So those components are still going to be delivering more functionality, but you take one bit out of it and then another, and then another, and then eventually they get to, and this is exactly what we're doing. Um, so we've got a bunch of component teams. We're slowly going to take some of those into virtual teams, still working the same components. And then slowly, slowly, we factor the teams and the architecture, taking Conway's law into account. Get that optimal designed for fast flow to a multi-year journey for us. This is three to five years, very used profession. Number three is when to architects need to walk that rope, um, and hold a quote from Jerry wind, but everything new is broken. And you said March Watts or two before the enterprise architects are seen as a conservative leaning, trying to keep everyone in mind, values, stop people from experimenting with new things because they're not staying.

00:19:59

Uh, Jessica joy Kerr came with a counterpoint to Jerry wonder everything new is, but everything old is stupid. So this balance, you need to be able to balance and choose and be smart to go line between old and new stupid in banking standards. Mark Schwartz again says it's not the standards. They are overrated. They are a drag on innovation on productivity and improving flow. Um, as enterprise architect, we need to balance. If we all got to have standards, we're not going to have to have some then, well, let's be permissive. Let's try and look for disallowing things rather than allowing them. So if you want to look at open source libraries, people use what people use open source library provided you how tools, like what source of Jake from x-ray in place to stop, uh, vulnerabilities. So you can use your long. Why did it doesn't break? Uh, I got on legal agreements or, um, automated as well. Remember if we're working in an agile way, we don't have a design trends anymore. So you need to start automating standards in pipelines. If you want to constrain people then right? The CIC pipeline is a place to do the future into again, try and move the momentum fall in the Backwoods.

00:21:46

Of course. So we have a new thing is broken. Many of them are not look for minimum viability. Again, don't try and standardize everything. Look for what's important. Most importantly, think more about outcomes than the standards. You can know what's going to improve flow. What's going to make your product sooner. Uh, what's going to make him less risky security, privacy, other concerns. And what's going to make your colleagues, customers, climate, and community. Happy talking about that. A fourth profession is healthcare. Uh, back to that tweet again. Um, I'm great. He says, well, what's enterprise architecture. Um, and then Michelson comes back and says, so what should enterprise architecture is probably one question. She says, ensuring the underlying health of the enterprise technology ecosystem systems, processes, services, platforms, products, most importantly, health of the ecosystem. How are we going to do that? Well, Forbes article, it says it is enterprise architecture.

00:23:09

Broken has a going quote, truthful data, provide you with the pulse of the enterprise environment. How are we going to measure that? Post some data from development team levels, from data from operations, again, team and operations tip. If you are in towers, can I go to together dev and ops? Um, we can do that. Some of them it's quite hard linking for example, change requests to what you've done in JIRA or TFS, that's been found to be difficult. There are solutions, but then as far as architecture can help here as well. You want to roll up or you just want to look organization at team level and we'll look at how we can assist them in departments, departments up to maybe your whole CEO's level and trend structure to be able to drill and dinosaur and slice. And this is where enterprise architecture can help.

00:24:06

And really quite the CMDB, your friend, strong guidance here, well-structured CMDB who really help structure data metrics, probably going to need to roll your own. There's some interesting tools in the space collegia, uh, open source capital one, uh, and, uh, Tasktop is super interesting for enterprise level flat for a lot of these metrics. You're going to end up from your own machine point. Now you can also play in here. So our enterprise architecture and the technology business management, uh, interplay really, really well together and to provide architecture for most of the structure and technology business management starts to look at really data driven cost management, super interesting. And this is what we've done. Uh, again, it's looking at some metrics driven by, uh, linkage to change request and development release. We did find that challenging. We're still finding it challenging and very much driven by there seem to be, um, what are you optimizing for as enterprise architects? Typically standardization, consistency, predictive planning, cost reduction, quite some more shorts again, but they should play, uh, should be familiar to a lot of those architects or those who work with them. These are not the outcomes that you are looking for.

00:25:39

Uh, some good outcomes from, uh, accelerate lead time for changes, deployment, frequency, total restore, change, failure, rate availability, uh, and, uh, quick Hanford's in now that's a value sooner, safer, happier. Isn't a signed up, comes from smart book. Finally, I've been honored to contribute a chapter to that it's out in press in November, all data-driven all good. Uh, do remember the judge, Jeff Bezos quote, and I don't some data disagree usually, right? So talk to people as well. Talk to development teams, what's working for them, what is not working for them? And so is enterprise architecture broken? Is it astrology? Did that?

00:26:43

Uh, enterprise architecture is very much alive. It's it is that health of the ecosystem long live and pros architecture says this enterprise architects have hundred bytes long. Uh, they see EA as an asset, which once again says it's, it's an economic asset. It's something that how it lives projects. And then just the long-term stewardship to horse north. That's an interesting thing about COVID being a liability of an asset and that's what you use. So a few things to recap, enterprise architecture, old interference, architecture, did design interviews. We want to have ongoing conversations. Don't want to focus on what's, uh, governing what's insomnia teams boxes inside their components. We really want to focus on involving your architecture itself, getting the right connections between them. We want to void detailed standards and work towards outcomes when we moved from directing to measuring and talking. And instead of those old things like standards, consistency, planning, and cost, and some of those are important, but Stuart, the real business outcomes, a better value sooner, safer, happier. Thank you.