Simon Rohrer

[00:00] Hi. Good morning. I'm Simon Rohrer from Saxo Bank in Denmark, in Copenhagen.

[00:00] 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 those things, about modern approaches to enterprise architecture informed by modern ways of working, being agile, et cetera.

[00:00] So where have I come from?

[00:00] I started my career 26 years ago, that many years ago, as a developer.

[00:00] I learned Java super early.

[00:00] I was using that at version 0.8 alpha.

[00:00] Early on in my career, I picked up the extreme programming whitebook back in 1999. I became an agile passionate zealot, test-driven development, refactoring, and all of those good things.

[00:01] I was working for a consultancy as well.

[00:01] I worked as an enterprise architect.

[00:01] I was doing a lot of PowerPoint, a lot of Word documents, strategy documents.

[00:01] I learned TOGAF, the Open Group Architecture Framework.

[00:01] I learned about the Zachman Framework as well, and I was sort of passionate about those for a while.

[00:01] My career swung like a pendulum between developer, more and more senior developer, more and more senior enterprise architect, and eventually I ended up as chief architect for the wealth management division of Barclays.

[00:01] And then I met Jon Smart at Barclays, and he was starting up 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.

[00:01] We wanted people to pull agile and for them to adopt it with our help. And then we decided, well, actually, it wasn't just agile, it was ways of working, lean systems thinking, theory of constraints, other things as well, and DevOps, of course.

[00:02] And then late 2018, I decided to leave the UK, so I had to leave Barclays, and I moved here to Denmark, to Saxo Bank, and, well, actually, I combined my previous two things, head of enterprise architecture, and co-lead on the ways of working program.

[00:02] I read an interesting tweet last year, just after I became head of enterprise architecture.

[00:02] Grady Booch, venerable software engineering maven, he said, "What is enterprise architecture?

[00:02] It's kind of like astrology for big enterprises or homeopathy for bureaucratic organizations." And maybe that should have made me feel uncomfortable, but I actually sort of got what he was talking about.

[00:03] I'd read Mark Schwartz's book, "A Seat at the Table" as well, and he talks a lot about enterprise architecture, and we'll quote him a fair bit.

[00:03] He says EA folk are perceived as office-dwelling trolls who manufacture constraints.

[00:03] They're perceived that they are stymieing 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.

[00:03] There's also a super interesting Forbes article from 2014 that says, "Is enterprise architecture completely broken?" Well, it's part of my career, so I don't really want to be an astrologer.

[00:03] I don't really want to be a homeopath.

[00:03] What are the alternatives to doing those things and to fix what is perceived as a sort of broken practice?

[00:04] What are the alternative practices to astrology and homeopathy? Law is one of them, but not law in a way that enterprise architects are used to being.

[00:04] Architecture governance, one of the practices of architecture governance in a waterfall or sort of pseudo-waterfall, WAGILE, water-scrumfall, even these sort of hybrid waterfall agile, which aren't really that agile at all.

[00:04] These practices, they sort of align software development with project management practices.

[00:04] So where you've got the project management phases of initiate, plan, execute, and close, they align 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 fair bit of build and test, although that tends to get squeezed out, and then you release once.

[00:05] And architecture governance has typically tried to find itself there between analyze and design.

[00:05] And most commonly, I've seen it, I saw it back at Barclays certainly, and I know other people have practiced this as well.

[00:05] Tried to say at the end of a design phase, "Well, let's do a design review.

[00:05] Let's get a bunch of enterprise architects in a room where the project team can present, and we'll sign off the design, or we won't and tell them they need to make changes to it."

[00:05] And that sort of works in a waterfall world.

[00:05] What happens when we move to a more agile world?

[00:05] Well, yeah, sure, we initiate maybe projects, maybe initiatives, maybe business outcomes. We plan continuously.

[00:05] We adapt our plans, and we execute in line with that continuous planning.

[00:05] Maybe we close it if we're in a project mode.

[00:05] If we're in product mode, that stuff goes on for a long time. And then, yeah, we're going to do some analysis, but again, it's a continuous process.

[00:06] Test-driven design. Test and design and build, and do that all day, every day.

[00:06] Release and release and release many times continuously, hopefully so.

[00:06] Where do we do our design review? There's no design phase.

[00:06] We've not really got anything to review here.

[00:06] We don't really have anything to-- We've got a bit to review here, but we've released some software already. So we're asking the wrong question. This shouldn't be about a single design sign-off. If the design evolves, well, how do we work with that?

[00:06] There's 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 up front that we're going to rubber stamp.

[00:07] We need to work with the teams. If we've got things that we want to do and things that we think are going to be beneficial for the organization for the longer term, then great. Let's talk to the teams about how, why, and what.

[00:07] And let's try and do that in a community. Let's not try and be them and us.

[00:07] Let's involve the teams in the decisions, in the strategy, in the long-term thinking as well.

[00:07] So law is interesting when it comes to enterprise architecture because there's one particular law that has been much discussed recently. Conway's Law.

[00:07] Mel Conway in 1968 made an observation that architecture follows organization effectively.

[00:07] And that's the main bit of Conway's Law that people recognize, understand, have heard of.

[00:07] In the same article, he said, well, great architecture may follow organization, but likelihood is that design, that architecture design that you get in the first place is probably not the best. You might well need to change it, and the implication there is you're not going to just have to change your design.

[00:08] You're going to have to flex your organization as well, and you're going to have to reward people for being flexible in the organization.

[00:08] That's hard. If architecture structure drives organization and there's this sort of feedback loop where architecture drives the organizational structure as well, and then you layer culture on top of that, and that constrains both of those.

[00:08] It gives them momentum.

[00:08] 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.

[00:08] And we can't just say, "Well, we need to build this new system because that's the way we want to evolve." We need to say, "Well, your part of the organization needs to change.

[00:09] You might not have the power structures you had anymore." That stuff is hard, but it generally is the enterprise architect's job.

[00:09] And that starts to say, well, those design reviews that we are starting to do or that we used to do, maybe let's try and shift our influence left.

[00:09] If we're going to have conversations at team level and look inside the 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 what boxes there are, what teams there are, how those teams and boxes as components interact.

[00:09] 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 about investing in the right initiatives and maybe changing the initiatives as well.

[00:10] A second profession we might want to look at inspiration from is evolutionary biology.

[00:10] Neal Ford, Rebecca Parsons, and Patrick Kua a good few years ago wrote a book on building evolutionary architectures.

[00:10] Agile software development talks a lot of that emergent design and evolutionary architecture, and there was a lot of talk about it, and then the book came out.

[00:10] If you look at real evolutionary theory, it's gone a couple of ways. Originally, evolutionary theorists thought that evolution happened in a gradual straight line.

[00:10] And then some iconoclastic evolutionary theorists came out and said, "Well, no. We don't think that at all. We think that the fossil record says that things stay still for thousands, maybe tens of thousands, hundreds of thousands of years."

[00:11] And that then these events happen, like a volcano erupting or a meteor hitting the Earth, and then rapid change happens.

[00:11] This is called punctuated equilibrium theory.

[00:11] And then as good academics do, they came together and said, "Actually, do you know what? We're both right.

[00:11] There is some gradual evolution, and there is some rapid punctuated evolution as well."

[00:11] And that to me is super similar to how we should be guiding the enterprise architecture.

[00:11] Some of that is going to be continuous improvement and continuous evolution of things getting better and better towards the niche that we need to be in.

[00:11] And that doesn't require sort of big chunks of something.

[00:12] It does require teams to be able to just stop looking at the end of their short horizons and start to look to the near term, but teams really should be doing that anyway.

[00:12] Mik Kersten's talked a lot about how you should be portioning your time across feature work and technical debt, as well as a couple of other kinds of work as well.

[00:12] And then there's the occasional step change, the step change in your architecture when somebody decides they're going to invest in a cloud program or replacement of a legacy system. And both of these kinds of evolution need to be guided and supported by your enterprise architecture team.

[00:12] And of course, that aligns back to what we were talking about before with governance, governance of evolution.

[00:12] The continuous evolution you talk to within the teams and then that longer-term, big step change where you actually need a chunky piece of investment to where, again, enterprise architecture should be making the case, should be advocating for spending the money on the right teams.

[00:13] Back to the Agile Manifesto, continuous attention to technical excellence.

[00:13] That's the technical excellence that allows us to evolve over time and evolve just gradually, continuous improvement, Kaizen.

[00:13] Evolutionary algorithms have things called fitness functions.

[00:13] So as enterprise architects, what are we looking at for our fitness functions for that evolution of the enterprise architecture?

[00:13] Accelerate has many, many good practices, the practices that it thinks drive continuous delivery.

[00:13] A lot of those are team-level, and we can trust, hopefully, the teams to do it. There's maybe support that we can trust the teams to evolve that way.

[00:14] There are a couple that sit outside the control of teams often, but loosely coupled architectures and empowered teams.

[00:14] Here's an example. This is not exactly what we've got at Saxo, but it's something that looks a little like what we've got, and it's something I've seen in a few places outside of my current role as well.

[00:14] It's an interesting architecture.

[00:14] If we're trying to optimize the speed, time to market, and speed from concept to cash, well, let's look at how our architecture sort of slows us down.

[00:14] We've got a few components and the teams that run those components, a user interface, an API layer, a couple of different services that interact, then a database, big monolithic database that contains, well, a lot of stuff, and a team operating a bunch of stored procedures around that.

[00:15] So what happens when we want to put a simple piece of functionality, Hello World, through this system of systems? Well, somebody's got to decide where that functionality actually goes and which teams we ask to build it.

[00:15] And so we have a team of solution architects who sit outside of the main delivery teams, and their job is to say, "Great, we've got this new feature.

[00:15] How many teams, which teams need to work on that?" So we had an example in Saxo late last year where 17 different teams needed to cooperate to build just one feature.

[00:15] The solution architects said, "Great, you need to build this.

[00:15] You need to build that."

[00:15] And teams typically are going to need to cooperate as well.

[00:16] And eventually, that functionality or something that looks close enough to it gets to the testing team and then goes to our customers and starts feeding cash.

[00:16] As you can imagine, that takes a while. That's not Dave Farley's one-hour continuous delivery concept to cash.

[00:16] That's weeks or maybe even months.

[00:16] So there's a couple of ways that you can start to look at Conway's Law to start to optimize that. Probably the easier thing to optimize is the organization, and it's where we are at least starting.

[00:16] So this is architecting the organization, refactoring the organization, saying, "Great, that sort of functionality is not just a one-off.

[00:16] It's the sort of thing that gets asked for a few times.

[00:16] So let's get a virtual team together from the UI team, the API team, service teams, and the database team.

[00:16] Let's sit them in the same room and take all of the features that look quite similar and get them to work on their bits of those components." They're still individual components, and the teams on top are the ones who are sort of maintaining them in the long term.

[00:17] But that value stream-aligned team, well, they can be a bit more efficient.

[00:17] They're still sitting in the room.

[00:17] They're conversing on another Slack or maybe over Slack these times.

[00:17] And that's a little bit more efficient, but it's still got some inefficiencies as well. Typically, you're going to have to have things like release trains.

[00:17] Again, you're not down to Dave Farley's one hour less between concept and production.

[00:17] Longer term, you want an autonomous team, and you want them to own their own component, their own value. And that's going to take some time. So we've, again, this is not the exact service we've built, but probably something similar, several similar things to this. A micro-frontend and a microservice database, effectively one component that owns that value and a team that owns it as well. There's a good pattern that Martin Fowler described many years ago called the Strangler Fig pattern, mainly known as the Strangler pattern these days, which says what you don't need to do this as a big bang.

[00:18] This can be one of those continuous optimizations where effectively you eat the elephant one bite at a time.

[00:18] You strangle those old applications, but you coexist alongside them.

[00:18] So those components are still going to be delivering a lot more functionality, but you take one bit out of it, and then another, and then another, and then eventually they get totally strangled.

[00:19] And this is exactly what we're doing at Saxo. We've got a bunch of component teams.

[00:19] We're slowly going to take some of those and put them into virtual teams, still working with the same components.

[00:19] And then slowly, slowly, refactor the teams and the architecture, taking Conway's Law into account to get that optimal design for fast flow.

[00:19] It's a multi-year journey for us. This is three to five years at the very least.

[00:19] Profession number three is tightrope walking.

[00:19] Enterprise architects need to walk that rope.

[00:19] An old quote from Jerry Weinberg, "Everything new is broken." We said Mark Schwartz put it before that enterprise architects are seen as a conservative wing that try to keep everyone in line with their values, stop people from experimenting with new things because they're not standard.

[00:20] Jessica Joy Kerr came with a counterpoint to Jerry Weinberg. "Everything new is broken, but everything old is stupid."

[00:20] So there's balance.

[00:20] You need to be able to balance and choose and be smart to go the line between old and new, stupid and broken.

[00:20] Standards, Mark Schwartz again says it's not that standards are bad.

[00:20] They are overrated. They are a drag on innovation, on productivity, on improving flow.

[00:20] As enterprise architects, we need to balance.

[00:20] If we are going to have standards, we are going to have to have some of them, then, well, let's be permissive. Let's try and look for disallowing things rather than allowing them.

[00:20] So if you want to look at open-source libraries, people use, let people use open-source libraries, provided you have tools like Black Duck or WhiteSource or JFrog Xray in place to stop vulnerabilities.

[00:21] Just say, "You can do what you like, provided it doesn't break either our legal agreements or break our security."

[00:21] Automate it as well. Remember, if we're working in an Agile way, we don't have a design phase anymore.

[00:21] So you need to start automating standards in pipelines.

[00:21] If you want to constrain people, then great.

[00:21] The CI/CD pipeline is the place to do it.

[00:21] Be future-oriented. Again, try and move the momentum forward rather than backward.

[00:21] Balance, of course.

[00:21] Some of the new things are broken, but many of them are not.

[00:21] Look for minimum viability. Again, don't try and standardize everything.

[00:21] Look for what's important.

[00:22] But most importantly, think more about outcomes than standards.

[00:22] Think about what's going to improve flow, what's going to make your product deliver sooner.

[00:22] What's going to make it less risky?

[00:22] Security, privacy, other concerns, and what's going to make your colleagues, customers, climate, and community happy?

[00:22] Talking about that fourth profession is healthcare.

[00:22] Back to that tweet again.

[00:22] And Grady Booch says, "Well, what's enterprise architecture?" And Linda Michaelson comes back and says, "Well, what should enterprise architecture be?

[00:22] It's probably the right question." She says, "Ensuring the underlying health of the enterprise technology ecosystem, systems, processes, services, platforms, products, and most importantly, people."

[00:23] Health of the ecosystem. How are we going to do that?

[00:23] Well, a Forbes article that says, "Is enterprise architecture broken?" has a great quote.

[00:23] "Truthful data provide the pulse of the enterprise in its environment."

[00:23] How are we going to measure that pulse?

[00:23] Some data from development, maybe down at team level, some data from operations.

[00:23] Again, team and operations typically work in towers.

[00:23] Connect the two together, dev and ops.

[00:23] We can do that. Some of it's quite hard.

[00:23] Linking, for example, change requests to what you've done in Jira or TFS.

[00:23] That's practically been found to be quite difficult.

[00:23] There are solutions, but enterprise architecture can help here as well.

[00:23] You want to roll up, and you don't just want to look at your organization at team level. You want to look at the whole ecosystem of departments, departments up to maybe your whole CIO's level, and try and structure things and be able to drill and dice and slice.

[00:24] And this is where enterprise architecture can help, and really where the CMDB is your friend. Strong guidance here. Well-structured CMDB can really help structure data and metrics. You're probably going to need to roll your own.

[00:24] There are some interesting tools in this space, Hygieia, open source came out of Capital One, and Tasktop Viz, super interesting for enterprise-level flow.

[00:24] But for a lot of these metrics, you're going to end up rolling your own at some point there.

[00:24] You can also play in here to our enterprise architecture and the practice of technology business management interplay really well together. Enterprise architecture promotes the structure and the technology business management starts to look at really data-driven cost management. Super interesting.

[00:24] This is what we've done.

[00:24] Again, it's looking at some metrics driven by linkage between change request and development release.

[00:25] We did find that challenging, we're still finding it challenging, and very much driven by the CMDB.

[00:25] What are you optimizing for as enterprise architects?

[00:25] Typically, standardization, consistency, predictive planning, cost reduction.

[00:25] Quotes from Mark Schwartz again, but they should be familiar to a lot of enterprise architects or those who work with them.

[00:25] These are not the outcomes that you are looking for.

[00:25] Some good outcomes from accelerate.

[00:25] Lead time for changes, deployment frequency, time to restore, change failure rate, availability.

[00:25] And I'll get a quick advert in now.

[00:25] Better value, sooner, safer, happier.

[00:25] Business-aligned outcomes.

[00:26] Jon Smart has written a book, finally.

[00:26] I've been honored to contribute a chapter to that.

[00:26] It's out from IT Revolution Press in November.

[00:26] All data-driven, all good. Do remember the Jeff Bezos quote, "When anecdotes and data disagree, the anecdotes are usually right." So talk to people as well. Talk to development teams, what's working for them, what is not working for them.

[00:26] Keep your head close to the ground.

[00:26] So is enterprise architecture broken? Is it astrology?

[00:26] Is it dead? No.

[00:26] Enterprise architecture is very much alive.

[00:26] It is that health of the ecosystem.

[00:26] Long live enterprise architecture.

[00:26] And Mark Schwartz says this, "Enterprise architects have had it right all along."

[00:26] They see EA as an asset.

[00:27] Mark Schwartz again says, "It's an economic asset.

[00:27] It's something that outlives projects."

[00:27] It lives for the long term, it needs stewardship.

[00:27] And then Tornhill, it's an interesting thing about code being a liability rather than asset. That's worth reading as well.

[00:27] So a few things to recap. Enterprise architecture.

[00:27] Old enterprise architecture did design reviews.

[00:27] We want to have ongoing conversations.

[00:27] We don't want to focus on what's governing what's inside teams' boxes, inside their components. We really want to focus on evolving the architecture itself and getting the right components and the right teams and the right connections between them.

[00:27] We want to avoid detailed standards and work towards outcomes.

[00:27] We move from directing to measuring and talking.

[00:27] And instead of those old things like standards, consistency, planning, and cost, some of those are important, but steward the real business outcomes of better value, sooner and safer, happier.

[00:28] Thank you.