Search
Search
SE Radio guests Eoin Woods and Murat Erder
January 28, 2026

SE Radio 705: Murat Erder and Eoin Woods on Continuous Architecture

Murat Erder, CTO for Financial Services at Valtech in Europe, and Eoin Woods, independent consultant in the field of software architecture, join host Giovanni Asproni to talk about Continuous Architecture—an approach to software design where architectural decisions are made and refined continuously throughout the lifecycle of a system, instead of up front in a big design phase. The show starts with a definition of Continuous Architecture and a description of the six principles underpinning it. Following that is an explanation of the main reasons and advantages of this approach, which finishes with some hints on how to get started using it. During the conversation, they explore several key points, including how to empower teams to take architectural decisions and recording those decisions; using feedback loops to refine the architecture; the role of software architects and architectural governance; the importance of focusing on quality requirements; and the impact of artificial intelligence on the field.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Show Notes

Related Episodes

Articles, and Resources

Transcript

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Giovanni Asproni Welcome to Software Engineering Radio. I’m your host Giovani Asproni and today I will be discussing Continuous Architecture with two guests, Murat Erder and Eoin Woods. Murat is an experienced technology leader in Otto and currently CTO for financial services at Valtech in Europe. He’s an expert in software architecture and data integration and also a frequent industry speaker. He has authored two books. The first one is Continuous Architecture, Sustainable Architecture in an Agile and Cloud-Centric World with Pierre Pureur and Continuous Architecture in Practice, Software Architecture in the Age of Agility and DevOps with Pierre Pureur and Eoin. Eoin is an independent consultant in the field of software architecture, green software and software engineering and he’s the former CTO at Endava. Eoin wrote and contributed to several books and among them there is Software System Architecture, working with stakeholders using viewpoints and perspectives with Nick Rozanski and Continuous Architecture in Practice. As I said before with Murat and Pierre Pureur, I want to mention that Eoin was also a guest in Episode 132 of the Software Engineering Radio and in that case was about top 10 Architecture Mistakes with Eoin Woods. And this was published on the 16th of April, 2009. Welcome to both. Is there anything that I missed that you would like to add?

Eoin Woods 00:01:33 No, those were great introductions. Thank you.

Giovanni Asproni 00:01:35 Okay then let’s get cracking. How do you define continuous architecture?

Murat Erder 00:01:40 The core of continuous architecture, if you go to the background and just want to have a call out to Pierre who couldn’t join us today, but Pierre and I, this is going back 10 years. We were thinking about, we always called ourselves the architects and we wanted to combine what is good in architecture and what is good and Agile. So, the principle or the essence behind, continuous architecture is how do you make architecture relevant and Agile? But yeah, the core of continuous architecture is the six principles, which we’ll get into more detail as we speak.

Giovanni Asproni 00:02:12 I noticed that you have things like architect products, not just solutions or architect for build, test and deploy. So, it seems that continuous architecture encompasses a bit more than the typical approaches and the definitions of software architecture. Am I correct?

Eoin Woods 00:02:29 Well I think continuous architecture focuses on getting the value delivered and empowering teams. The reason I think because I didn’t write it but I’ve used it many times, the reason for the principle about build, test and deploy is that if you don’t do those things then the teams aren’t empowered and value isn’t delivered. So, it tries to take a slightly more holistic view of what software architecture work should encompass than just structure of a software system.

Murat Erder 00:02:53 Yeah, I mean I can add to that as well. I mean both Pierre and I worked in consultancy and in enterprises and it’s really about practicing architecture, right? So, it’s not about theoretically what makes a good architect, it’s what makes architecture sensible in an enterprise, right? So, if you’re just doing architecture, maybe a very small company or you’re building three or four people building a system, some of these things might not be as relevant, but it’s really about practical architecture and what makes sense while you’re building systems. And another thing which we might touch upon later is that, while writing the first book, which is again 10 years ago, one question was asked to us like what’s the unit of work of an architect? And we came to the conclusion at that time we called it architectural decision. Now this is before ADRs architectural decision records and other topics came about. But that really is architecture is about the running software in production and making it sustainable. Everything else doesn’t matter and what really matters are the decisions you make that impact how that software running and production is constructed.

Giovanni Asproni 00:04:00 Okay. And now maybe we can go in more detail into the principles. I know that there are six of them. Can you briefly explain those to us?

Eoin Woods 00:04:08 The first one is quite fundamental. It’s about thinking about a product led approach as opposed to a project led approach. And today this sounds entirely obvious, and I sometimes do stand in front of audiences who look at me and go and you say, well you’ve got to remember these things were being thought out in 2011, 12, 13. I asked the audience for those who are old enough. And then if you, in 2012 were thinking about building products inside enterprises as opposed to running projects and very few hands go up. It’s more a reminder that actually if you take a product oriented approach and you think about the long-term planning and a product inside an organization that has a particular collection of stakeholders and will have a long-term life. And so, it needs to be managed in a sustainable way, it drives you to thinking about all your work as building products. Even if they’re never sold outside the organization, even if there’s only one copy, it’s still a product. The second principle is fundamental to architecture in general. It’s about focusing on quality attributes. Most of our architects do obsess about quality attributes, but especially when you’re introducing these ideas to people, it’s actually not obvious to people. They think architecture is about boxes of lines, it’s about structure. The only reason for the structure is to achieve quality attributes, security, performance, scalability, resilience and maintainability.

Giovanni Asproni 00:05:18 This is actually an interesting point because often in many software products or projects, there is a lot of focus on features and then the quality attributes are often an afterthought.

Eoin Woods 00:05:29 Exactly. And that’s why it’s such an important principle. It’s that quality attributes have to be lived and breathed by the team. You don’t want someone over here called an architect who it’s their problem. And generally speaking, I’d say with all due respect to high performing Scrum teams, they can be doing a great job working with that product owner delivering features. They find it very hard to step back and take that more holistic view unless you remind them to because after all, security is not something that one team can actually achieve. They need an environment that they plug into to achieve security. And so that’s why it’s an architectural principle to focus on quality attributes because it’s a holistic systemic characteristic. The third principle I suspect, because again I didn’t write it, but we can ask Murat, I suspect came direct from really the Agile manifesto type thinking, which is delay decisions as long as you can.

Eoin Woods 00:06:13 This is a reaction to the kind of architecture that I used to do. Absolutely. If you look at the software systems architecture book, I put the graph from that showing architecture activity over time up on slides now so I can laugh at it because it’s my graph where we used to say, well of course architecture’s, lots of decisions upfront to de-risk the whole enterprise. And then we have some decisions at the end where we realize that now we’re getting towards production, we need to rethink a few things. Of course, that’s a pretty flawed approach actually as we discovered over the years, some decisions actually do need to be made very early and there are contexts where actually more decisions need to be made early. But the earlier you make a decision, the less information you have, therefore the poorer decision you probably make. We need to make the decision as late as we can as the Agile communities have been telling us for, is it 25 years now Giovanni? No. To make the decision as late as possible because that gives you the most accurate context to make the decision.

Giovanni Asproni 00:07:03 This is actually a good point because, well I worked in many projects and funnily enough, often when people go with early decisions with grand designs of how the system should be and trying to overthink the evolution and everything, what happens is that the systems have this horrible habit of evolving in a direction that is different from the one you forecasted. So, you end up having to maintain a lot of stuff that you don’t need because otherwise you cannot even compile the code plus hacking to the system, the things that will support the new direction it’s going to towards. So, you may end up with a spaghetti monster that you really didn’t think of at the beginning.

Eoin Woods 00:07:41 Exactly the number of people over the last 15 years you’ve told me I just want a future proof architecture to pause for a moment before breaking the bad news to them. There’s no such thing. There’s just the simplest possible effective architecture for now and we’ll maximize the options for change later by keeping it simple.

Giovanni Asproni 00:08:01 Now before letting you proceed, I can tell you this, that this is a real thing that happened to me in a requirement document, a requirement that was written that the architecture has to be flexible to support future requirements. And I explained the person at the time that I didn’t have a crystal ball to actually be able to do that in advance. Yeah.

Murat Erder 00:08:21 I’ll give to a few examples about this. For example, I mean one experience I had was people were designing the system, and they were expecting thousands and thousands of users. So, they built a lot of complex capabilities in the system but it went live and it never reached that user capacity required. So, all that effort of building that was wasted. And back to your flexibility comment Giovanni, another thing at least maybe you step in quite a lot when rules engines were very popular, you would say, oh I need the system to be flexible. That means I’ll just write rules, and I’ll put the rules engine on my system, and I’ll just change the rules. Which usually didn’t work as anticipated and you just put a rules engine one, not required one, you could just get by with just some simple logic. So it’s those type of things that if you’re thinking you have the most future proof architecture zone set and you try to build it, you’ll just waste a lot of time and effort and probably all architectural decisions about you balance different quality attributes And because you build a complex system, you might overlook some other quality attributes that you might not have thought of.

Murat Erder 00:09:23 Yeah, and one final comment on this one presented this that a lot of people understand that as do not make design decisions and that is not the intent at all, right? We want to make design decisions, as I said before, it is the unit of work of an architect. If you do nothing else, you’re just make sure you know which design decisions you’re making. So, it’s about making them in the right context as Eoin said.

Eoin Woods 00:09:47 Yah, so to recap, the first three, build products or projects, quality attributes over functional requirements, delay decisions as long as you can. And then the fourth one is focus on build, test, apply and operate. I think this again is not about only focusing on build, test apply and operate, but it’s making sure that someone is thinking about build, test, apply and operate. Again, guessing a little bit really between the lines historically software architects perhaps been quite good at debating design patterns and software structures and code line organization and how the unit tests should run and actually have then left a yawning chasm between that and how code runs in operation. I have a former colleague, Edward Butler, who I worked with a friend quite a while in Endava who a great turn of phrase and it was started really on the ops side of the house.

Eoin Woods 00:10:33 So then moved to the dev side of the house. So, he for a period was very influential in DevOps as you might imagine. He was one of the pioneers and he had a lovely phrase, he said, on the one side you’ve got operations, on the other side you’ve got development. And in between you have the desert of responsibility, nobody wants to tread because they think they’re going to die and architecting for build test supply operate is about building the bridge over the desert so that actually code can stop just being beautiful structures and it can actually start delivering value in production.

Giovanni Asproni 00:11:01 Yeah. Do we actually, this principle is something that is quite interesting because I think is an excellent one. It’s also something that really when you talk about architectures, often with architects they don’t really emphasize the architects for build, test and deploy. Often there is the emphasis on the boxes and lines if you like. Yeah, I’m simplifying a bit but it’s often on this, on the structure. Usually on the static behavior sometimes some sequence diagrams. But then is how are we going to test this or how are we going to build or deploy this stuff? It’s never discussed.

Eoin Woods 00:11:31 And I think historically there were reasons for that. Not maybe brilliant reasons, but there were practical reasons. I grew up in product development and there, I mean the development team software engineers didn’t deploy anything. We had to produce a binary that came out of a build cycle that went to showing my age something known as the gold master meaning because the first CDs were always gold so you could tell them apart from the other CDs. So, it was stamped to the gold master that went to the test team and actually that was sort of sane and sensible. This wasn’t a cloud deployment, this was going to have to go to a customer. The customer was literally going to put that CD into a server machine and try and install the product. So, the fact that you had a separate team with the skills the customer had checking what was coming out of the engineering build cycle actually made a lot of sense.

Eoin Woods 00:12:16 But as soon as you start operating here on software as a SaaS vendor, that suddenly doesn’t make any sense anymore. And I think a lot of big companies, enterprises were set up that way too. Do you remember they used to have? Yeah. Well, many still do, quite isolated ops function Dev are not allowed to have any access or control over production at all. They can fiddle in their test environments but there’s not a very serious attempt made to sync them up. And again, something that looks a bit like a gold master comes out of development is handed to ops across the desert of responsibility. Ops try and install it, tell you it doesn’t work and hand it back again or even worse, boot it and then hope for the best in full knowledge that it’ll probably go wrong. And then have to deal with the fall at half past two in the morning when some other region starts using it and they suddenly discover they haven’t got their languages loaded or whatever gross error has been made.

Giovanni Asproni 00:13:04 Also, that test bit is actually quite interesting because in practice you can have something that that high level architecture, two systems look identical from a high level point of view, same module, same things, but one is testable, the other is not simply because you didn’t think about how are you going to test this thing. Yeah. So, to me also this is quite an important point. Another one that is often not discussed even nowadays.

Murat Erder 00:13:28 No, I totally agree. But I think it’s all about back to what we said about the principles about the team and a team owning the software. So, it’s not about having separate teams do different things like you build it, you own it, you operate it right? In an ideal world, you want the team fully accountable for the software from its conception to its decommission actually at some point. And in between you operated for many, many years hopefully. And then I think that’s sometimes lost on people and this distributed responsibilities, different teams and you create those deserts that are mentioned of no responsibility. And testing is another good thing, right? Testing should be done by the team. You might have certain testing experts, but you don’t need massive separate testing teams and thinking about how you test it, which artifacts you test, how often you test, what do you mean by regression testing, how you manage your test data, all those things the team should be thinking about.

Giovanni Asproni 00:14:22 Yeah. And then which principles are left?

Eoin Woods 00:14:26 There’s two. One is architect for change and the last one is organize your teams along the design of your system. And architecting for change is, it’s a little bit like the testability one, I think it’s, if you think about the fact the system will have to undergo possibly traumatic change in the future and you think about that early without building a monstrosity, there are things you can do to make it easier to change. So, for example, I mean your kind of expertise, Giovanni and domain driven design tends to produce code that’s highly modular with very limited dependencies and very regular structure. Making things testable early frequently allows them to be repackaged in different ways on still testable building from smaller rather than huge, big monolithic components. Anyone, I mean offshore three of us have sat in front of an IDEI wondered what to do with even a single class.

Eoin Woods 00:15:11 But a single class that sack seven or 800 lines of code with a small number of huge methods in it’s just very hard to change. And so, dealing with more smaller pieces and it’s bearing those in mind. And particularly the emphasis behind this principle is as the principle says, that leveraging the para small, clearly written by Pierre as it’s more of an American phrasing of it. So, I mean that that alludes to things like small services, not necessarily microservices but, small services rather than big monoliths with lots of internal interdependencies or if you’re going to build a monolith, build it out of really well encapsulated. Smaller parts are assembled at runtime.

Murat Erder 00:15:48 And if you think about microservices and the whole debates around that, if you combine principle four with actually principle five, those things together will make you decide what’s the best size of those components, right? Because the more if you, everything is very small, it’s very difficult to operate and monitor and manage the dependencies and even just understanding the message flows et cetera, between tens of components versus a few handful is very different. So, I think the principles really add value when you try to apply all of them together.

Giovanni Asproni 00:16:22 Definitely. And then the last one is the, want to say the model, the organization of the design of the system. This is Conway’s Law, is it?

Eoin Woods 00:16:30 Yes. I’d say probably we’ve probably got less to say about this collectively the three of us than we have about all the others because it’s about organization design and generally people who are expert software architects don’t do organization design to be honest. I think certainly what I’ve started to point to is team topologies because I think they thought quite a lot about a sort of abstracted software engineering approach to how you design organizations, which seems to work well in practice. They’ve been adopted lots of industries. But for me actually the core of the principle is bear in mind if you have one structure for your teams and a different architectural structure in your software, the two will start to overlap and merge whether you want them to or not because people need to get things done. And so, if there’s lots and lots of discussion needed between teams, they will find ways around that and you’ll probably find functions bleeding into their own modules. You’ll find strange interconnections suddenly appear between components. You’ll find components suddenly getting merged without you being told or split because people can’t work on that other one. So, it’s if you ignore the relationship between the organizational structure and the software structure, you are fairly doomed to the fact that the two of them are going to start merging in probably unforeseen ways.

Giovanni Asproni 00:17:34 Yeah. To me it looks like the Conway Law is almost a law of nature of how organizations work. And you mentioned team topologies and team topologies is an approach on how to exploit this law somehow make sure that it works in your favor because it’s easy to say you should carry of course is a principle here. But modeling the organization after the design of the system as a principle does not tell you much about how in practice do that and team topologies is an approach for doing that. There may be others but is kind of help in achieving that.

Eoin Woods 00:18:07 Exactly. It’s a starting point and like any prescriptive abstract approach, you’re probably going to change it in some ways for your particular context. But it’s a good starting point.

Murat Erder 00:18:16 Maybe I’ll take the principle in a different way of thinking about it. It’s also about the things you care about, and you can change and the things you care about and you can’t change. And if you find yourself that you, and this probably works more for if you’re thinking of systems or systems or more complex systems, but if you think the perfect system you want to develop but it actually doesn’t fit within how your organization is structured. For example, I mean in banking at the very highest level there’s the front office and the back office. Like if you oversimplify it and if you own the back-office system, but for it to be fully successful, you need your front office systems to operate differently. You really don’t have much influence over that. So, they sometimes know what you can influence and if you can’t influence it, just then build your architecture around that rather trying to fight unnecessary corporate battles.

Giovanni Asproni 00:19:08 Yeah. How do you balance upfront design with architecture flexibility here, especially when dealing with a change in business needs?

Eoin Woods 00:19:17 Yeah, it can be quite difficult. Just the same as in Agile software development in general. But delay your design decisions as far as you can but not too long. Actually, finding where that point is can be quite tricky. And I think there’s two things that I use. One is when is the decision going to be needed as opposed to when is the decision probably going to be irrelevant and things will have moved on. And the second thing is how risky is the decision? Which tends to come down to how reversible is it. Decisions that are not very reversible are ones that certainly need attention early and you need to be thinking about them even if you don’t make the final decision. You need to know what your options are because other decisions may cut off possible solution options for another decision. And then when you are looking at whatever approach you’re using, but some sort of roadmap as to when the systems go to evolve, for example, when you’re going to go into a new region or when you think user numbers are going to go for a certain level or when a particular set of features implies big changes or maybe big increases in the complexity in the data layers, that’s when from some distance out you can generally see that architectural decisions are going to be needed before you get there.

Eoin Woods 00:20:23 So you then have to work back and work out how much time do I think I’m going to need to make a good decision as opposed to the first thing that pops into my head.

Murat Erder 00:20:30 And sometimes to expand that, I mean architecture decisions, what I find quite useful is to try to write out architectural decision you need to make and not these. And I said certain decisions are very critical and non-reversible. I think like the how you manage data in your system or the database technologies you use are something that’s quite influential in the future of your architecture for example. That is an important and significant decision. While some other decisions like do are use synchronous or asynchronous messaging, you can work around that, and you can build components that shield you from changes in those decisions.

Giovanni Asproni 00:21:13 And in terms of evolving architecture, how do you incorporate feedback loops into architectural decision making? Any feedback says from operations, user experience, business, maybe the development teams, how do you do this? How do you implement these loops?

Murat Erder 00:21:27 In the second book we wrote something called the essential ctivities of continuous architecture because the challenge to us was it’s great you have these principles but what does that really mean? And that’s why with Eoin joining us as well, we wrote the second book because which is much more practical and walks you through an example of building a system and the decisions you need to make. But if you look at the essential activities, like if you do nothing else, if you want to do architecture, and again we’re talking about your responsibilities, the code that runs in production, you have to focus on quality attributes. That’s kind of non-negotiable. You have to have architectural decisions that we said is the core unit of work and then basically you have to track your technical debt. That is quite important. We don’t dive into it that much as a topic. There’s quite a lot of good books on that that are separate. But I think understanding technical debt is important and we say those are the core things and you have to implement feedback loops to do architecture act, you need feedback loops. Now depending on your organization, what those loops are and with whom is.

Giovanni Asproni 00:22:33 Have you got any examples?

Eoin Woods 00:22:34 So there’s two sources generally of information to give you a feedback loop. One’s an artifact-based measurement, one’s an operation-based measurement. So, artifact-based measurements tend to come from the pipeline and they’re all the things most listeners will be very familiar with static analysis, dynamic analysis, complexity, security, checking code, quality metrics, all those things. But can also be things like you might be doing performance testing in one of your pipelines, that kind of thing. And then there’s the operational stuff where you tend to get some business measurements and some technology measurements. Both of them can provide useful architectural input. I have repeatedly found that the business measurements actually don’t tell you much about the architecture because the business want to know things like what’s the dollar value that has flowed through the system today? That’s a very reasonable thing for them to ask. But it doesn’t tell you much about your architecture unless you understand the transaction makeup.

Eoin Woods 00:23:21 So this is common thing in banking. You hear people in money markets saying, oh well we do $1.4 trillion worth a year. Okay how many transactions about 40 a day. And the equity guys look up and go, we do more than 40 a second. The amount of money doesn’t matter. It costs the same process, a $1 transaction as a trillion transaction to a first approximation. So, some of business metrics can be shared of things like they may well care about peak load because it’s giving them a business view as well as there’s a technology view. But generally, for architectural feedback loops, I’ve always found the technical measures are normally what you need to know whether your architectures going in the right direction or the wrong direction. How many security problems have you had in the last three months? How many failures have you had? What was your recovery time? What’s your CPE usage on? Average throughput, it of course depends on what’s important for your system, but it’s those kinds of tangible measurements that a well operated production system can provide you give you a lot of input.

Giovanni Asproni 00:24:16 So from the business, if the feedback loop from the business it could be interesting is anything that reflects almost directly to technical things like we want to serve X million customers per day, for example, which would reflect on the load of the system. Maybe.

Eoin Woods 00:24:29 Indeed that can then be sort of translated into technical requirements. And then if you measure for example raw request volume, that’s not actually going to give them that metric. But you can probably process raw request volume by working out how many unique visitors you have to work out if the business metric is being maintained or not.

Giovanni Asproni 00:24:46 Okay. And now a question that may be a bit difficult, I don’t know, we’ll see. So, I’ll quote you from the book. So, in Continuous Architecture, so in the first volume you wrote, a majority of architects work effectively as part of software delivery teams and most of the time probably not even calling themselves architects. And in the Continuous Architecture and Practice book he wrote, perhaps it’s better to consider architecture to be a skill rather than a role. Now, what does that mean for people whose role is software architect?

Eoin Woods 00:25:15 Providing their organization views that constructively? And as long as they have great relationships with all of the different people who care in order to be effective, it’s absolutely fine to have a role called software architect. I think what we’re recognizing though is that historically that job title can be a bit of a barrier, not necessarily because of any one individual, but collectively that job title can be a bit of a barrier to, for example, effective collaboration with teams. And there’s also to recognize that lots of people are doing architecture work who even in an environment where people are called software architect, there are lots of other people doing software architecture work who are not called software architect. So it’s trying to decouple the two really this was a long theme at Endava, our group head of architecture who I think both of Christina Cooper Bland, Chris chief for quite a number of years before her retiring from Endava about a year ago, that she has been trying to do this within the firm is sort of prize the two apart and make architecture a set of skills and behaviors, which it can be found right across technical job families.

Eoin Woods 00:26:15 And some people want to specialize in those particular things, and they’re called software architects and solution architects, and we have those too. But it’s not trying to corral architectures belonging to the architects. It’s very much a collective shared common is what we’re after. And there’s different ways to achieve that. One of them is to have architects working with everyone else. But the other thing is to have no one called architect, but there’d be people who’ve got architectural responsibilities.

Giovanni Asproni 00:26:39 Okay, so am I correct if I say that is a bit like when we talk about T-shaped people that, have a deep expertise in something and a broad expertise in in other things. So, somebody could be a good developer but is also a deep expertise in architecture and somebody else have maybe broader expertise in architecture but is a better developer or better technologist in some aspects?

Eoin Woods 00:27:00 Yeah, perhaps they’re an expert on databases.

Giovanni Asproni 00:27:02 Yeah. Is something along those lines. So, it’s not that architects are not valuable anymore, their relationship with the teams is different from being somewhere else designing things and

Murat Erder 00:27:14 Exactly. I mean it’s actually to make architecture valuable is the intent, right? And I think in lots of traditionally the ivory tower architect gets a bad name in organizations because you have sort of separate architecture teams that dip in and dip out of different product teams or project teams. And the idea is bringing accountability back to the team, right? Because the unit of work, architectural decisions and the team makes those architectural decisions. So, anyone who contributes to that architectural decision is, you could say an architect. That doesn’t mean you don’t need central teams to set wider principles or wider guidelines for the organization. They need to exist. But it’s to separate this thing of like having architects on one side are the only people that make decisions and determine what’s good or what’s bad. And everyone else has just toiling writing code. And you can take different views, you can say the architects see them as people who just don’t know what they’re doing and make wrong all the wrong decisions or the people on the ground actually working to develop the software, look at the architects and say, who are these guys? They have no idea of our software, of our codes and they just come here with, and they pontificate. So, we really want to bring that together and make architecture relevant rather than having two separate focus areas in the organization trying to do architecture.

Giovanni Asproni 00:28:34 Yeah. Another question around the decisions. As we mentioned before, the architectural decisions are kind of the say what architects do, is that the main output of their work? In a continuous architecture context? How do you recall them and maintain those decisions? Because if it was waterfall, everything that set up front I have all my decisions written, agreed, signed on blood and that’s it. I don’t need to do much.

Eoin Woods 00:28:59 Well written, agreed, signed, ignored.

Giovanni Asproni 00:29:02 Ignored, that’s the full life cycle. But in a continuous architecture situation, especially when we work start from small and evolve the system and take decisions all the time, we need to record these decisions and manage them in a bit of a different way. Is much more dynamic, isn’t it? So how do you do that without actually being overwhelmed by the process?

Eoin Woods 00:29:22 It’s quite difficult. And interestingly in the last two to three years I’ve worked with a couple of clients who were actively trying to figure out how to do this. They were very well-intentioned. I’ll just say they met ADRs, they sort of unleashed ADRs across their team.

Giovanni Asproni 00:29:36 Just a sec, so ADRs we mean?

Eoin Woods 00:29:38 Sorry, Architecture Decision Records. Yeah, they picked a format; they did some thinking about how they wanted this to work. They started producing architectural decision records, almost not exactly ad hoc but con very continuously. And they ended up with this huge heap of architecture decision records and it wasn’t quite clear what to do with it. And I think the lesson I learned after two or three times of kind of trying to help people with this is, it’s one very important to work out what you’re going to do with your decision records. And secondly you need to put some effort into curating your decision records very early. Otherwise, they become a sort of documentation debt. Because you don’t know which ones are valid. Some of them are probably now being retired but they’re still sitting there in the overall heat. It’s very hard to find a specific decision because there’s just, they’re very loosely organized.

Eoin Woods 00:30:23 The best solution I found for that I didn’t find a great solution, but the best solution was using Wikis because they can be hierarchical along with rich content tagging. And so, you can use I forget all the right content term for it, but you can effectively have a web of content linked together by the tags with an overall primary organizing hierarchy. So, you can go and find stuff quickly and find related things quickly and you link between the records. But the thing that you have to keep persuading people to do, even though they’re busy, even though they’ve got three jobs, is when they hit a decision that that looks wrong, the documentation looks wrong, flag it up and do something about it. And secondly, on a routine basis, review decisions in the overall decision base and retiring the ones that should be retired, correct ones that are incorrect or at least flag things up that are inconsistent. And particularly if they’re not consistent with the principles because the point of the principles is to guide the decisions. That’s a really, you were talking about feedback loops. That’s a great feedback loop. So, are we ignoring the principles when we make decisions and so the decisions aren’t great decisions or are we making good decisions deliberately violating the principles? Because the principles aren’t right. And so, you need to go back and think, well these principles don’t reflect our priorities.

Murat Erder 00:31:32 I mean there’s I think two sides to like there’s the managing decisions as part of the process, almost as implementing principle three is one way to look at it. And then how you curate decisions after you’ve made them so that you have a proper knowledge base is another way to look at it. Right? And they, I think they’re both complimentary, but one talked about good ways of how you can make sure that your collections, that decisions are already there so you understand why the hell the software was built in the way it was. But also, I’ve found using like a basic ban board of architectural decisions on a product and you just go through them, and you have decisions, as I said, that you’re not going to make yet. You have decisions you’ve made. Of course, once you make a decision then it goes into the heap of how you want to review them, et cetera. But that can ban board thing really, really helps focus the team on just saying what are the, and that’s the process of making the decisions on implementing principle three. I think that’s just as important as the post the decision is made, curation.

Giovanni Asproni 00:32:32 Yeah, in some projects I work actually we found useful to put many decisions in the same configuration management repository of the code that was affected. But then decisions of higher level may be weeks or somewhere else. Basically, a mixed kind of approach. Because the reason is sometimes when you are, even if you are in a continuous delivery approach, sometimes you have a version in production of a system and you want to know what these decisions related to that thing. Not necessarily the new decisions for what you’re working on at the moment. But it’s really a complicated thing. But it definitely requires some effort from the company to actually address the problem.

Murat Erder 00:33:09 Yeah. And very dependent on the culture of the organization as well. I mean I’m a continuous architecture as principles and recommendations, but it’s not a cookbook. In the sense that we don’t tell the mix two teaspoons of decisions with one tablespoon of quality attributes, and you get the perfect system. It’s just ways to think about how you do architecture.

Giovanni Asproni 00:33:31 Now moving on a bit about validation. How do we validate an architecture in a continuous architecture context?

Eoin Woods 00:33:38 Well, the feedback loops are quite fundamental to it. There’s nothing to stop you though doing what you might call traditional architectural evaluation on a system that’s, using a scenario-based technique like a term or something, a bit lighter weight and less formal, but you still understand the overall architecture. So, you can still do a, what you might call an abstract evaluation of it, but I think the key evaluation is how well does it work? And that’s what your feedback loop should be telling you.

Murat Erder 00:34:04 Yeah. The end goal is to, as we said, like you’re accountable for the system that’s running in production. So, if you really think about it, if you know how well the system is operating, plus how well you can maintain it over time because architecture’s about building a sustainable system over time, those two things validated. But yeah, I’m known as, right, there are lots of techniques for validating an architecture and those and you could do architecture reviews, or you could implement anytime (?) all those things are valid. We’re not very, but this are not very prescriptive on that what whatever works. And I’ll tell you an interesting way. We validated architecture designs years ago and it was not my idea, it was my boss’s idea was actually we bought huge, big Lego blocks, like the ones that you play with, and we had sessions where people would describe their architecture.

Murat Erder 00:34:55 Here’s the database, here’s the web server, here’s that component or that other component. And they tried to build it with Lego blocks on the floor and then people would walk around and ask questions, what if I move this or if this component you could just actually physically kick a Lego block and say if this component goes down, what goes on? So, I mean, again, it’s not a very formal technique but it’s I think there’s multiple ways. But then objective is if the system is working and you can maintain it over time, then you’re successful.

Giovanni Asproni 00:35:25 Basically ensure that you can exploit the feedback loops but also you can apply some for the lack of a better wording, more traditional techniques. And they still work in the context of continuous architecture. Am I correct?

Eoin Woods 00:35:37 As long as you understand your system. But to be fair, techniques are ATAM, which are often thought of as very formal and documentation-driven. They’re not at all. When they designed ATAM, they would typically turn up in a US Department of Defense subcontractor. Because that was the market it was built for. And the first thing they’d say was where’s all the architecture documentation? And this large defense subcontractor who’d spent a billion dollars would go, oh, we haven’t got any of that. So, the first step of ATAM is like, work out how the system works. So hopefully if you’ve taken a continuous approach, you’ve got all your decisions, you’ve got minimal models, you’ve got your principles, you actually know how your system works. So actually, assessing it shouldn’t be a huge problem.

Giovanni Asproni 00:36:11 Okay. So as long as you know what the system does, it should be fine.

Eoin Woods 00:36:15 Should be fine.

Giovanni Asproni 00:36:16 In terms instead of Governance. So, making sure that the architectural decisions are implemented and implemented correctly. Yeah? How do you approach Governance from a continuous architecture perspective?

Murat Erder 00:36:27 Governance, right. We wrote about that in the first book had the chapter or part of the chapter on it. And the whole idea is that again we’re talking about the team and the team owning the architecture of their system and there’s lots of decisions that they need to make. So, when you think about Governance, you want to make sure you enable the teams to be able to make those decisions as quickly and explicitly as possible. But at the same time, you want certain enterprise standards. It could be database technologies, it could be certain techniques for logging or certain metadata you want captured for certain events, et cetera. So, the whole idea about Governance is that you have, you make very few but significant decisions at the top of the corporation by the, I guess the most senior architecture Governance body you have.

Murat Erder 00:37:15 And then depending on the size of the organization, you can get to divisional level and lower levels. But the majority of the architectural decisions are still made by the team. But they make it within the context of that. Now for that to work, you need to make sure that the communication is very effective. You need to make sure the enterprise standards are really communicated to all the teams as effectively, which is difficult on its own, but somewhat achievable. But what I think we lack as an industry, and I don’t know we even practice how you make sure that the decisions made by the teams are visible to other layers in the organization and to other teams, right? I think that knowledge management of architectural decisions is still a huge gap. And eventually what happens is that something goes wrong. Someone, senior is called, dragged them, what’s called the senior person accountable for sort is dragged in front of people to say, well this system went down and who approved X, Y, Z.

Murat Erder 00:38:12 And they don’t know because they had, they don’t have that transparency. And after that happens then they start becoming much stricter. They say, okay, now I want every architectural decision approved by me. This could impact tens of teams, right? So, I think the trick in Governance is again, I guess the unit of work is the architectural decision. You want to make that in context of bigger principles and rules set by the organization. But you need transparency and cracking that transparency not I think is a big challenge but, it takes a lot of time. It’s a big knowledge management efforts and, most people who are technologists, I want to do architecture and things like that sometimes don’t want to focus on that. I guess the more social and all the sharing aspects of developing software

Giovanni Asproni 00:38:59 And are there any elements of the Governance that can be actually automated? Something that maybe can end up in the build pipelines or some level of automated checks.

Eoin Woods 00:39:10 There’s quite nice support in open-source libraries like ArchUnit for checking some quite sophisticated dependency in code structure, implementation of patterns, those kind of constraints in code. But that’s a very micro level architecture. You can’t really check the, I don’t know, web sockets as being used correctly for all request handling. You just can’t check that with a simple static test, which in that case is based on reflection and using annotations in the code to spot different type types of component.

Giovanni Asproni 00:39:40 That could be useful but definitely insufficient.

Eoin Woods 00:39:43 It’s only part of problem differently.

Giovanni Asproni 00:39:44 Yeah. Let’s talk about adoption of a continuous architecture approach in a company where somebody says, you know what? We need to adopt this approach to architecture because we think is a good one. Yeah? We can give some benefit. Now my first question about this is, are there any specific organizational structures or cultures that for which continuous architecture is particularly challenging to adopt?

Eoin woods 00:40:09 I think it’s very difficult to adopt whether there’s a centralization of architecture and decision making. And so, you have a very entrenched team of, they’re probably called solution architects or maybe called software architects, and they sort of work across the teams telling the teams what their decisions are. Sometimes you can be pleasantly surprised, and those teams react very positively to a more decentralized bottom-up approach. But frequently if they find it quite challenging, they will advise senior technology management that chaos will ensue. There will be no Governance, and the bad things will happen. And so, you have to work to come to the fears because some of the fears are legitimate and explain how you are not trying to achieve anarchy. You’re trying to empower teams. They’re two different outcomes and how you can empower teams without it being an, but it does require a certain change of mindset if there are central architecture teams who view themselves as primarily a decision making and policing function.

Giovanni Asproni 00:41:02 So basically, it’s introducing a company that more decentralized decision making. This could be scary to people that are not used to this.

Eoin Woods 00:41:10 It certainly can be. Yes.

Murat Erder 00:41:11 And that’s like, I mean almost going back to the first thing I said that was the reason we wrote the principles and the book is to I guess challenge that structure and organizations and say there is a way of bringing good architecture and Agile practices together. But you can flip it around. I mean I haven’t experienced it, but you could say an organization that is, let’s call it Agilist or they’re saying they’re fully Agile and they pay no attention to architecture would be just as difficult because then they would say, well why do we need architecture decisions? Or it’ll just go and develop. So, I think if you’re at the extreme of centralization or the extreme of just build it and see what happens, it will be difficult.

Giovanni Asproni 00:41:54 Yeah. For a greenfield system. Are there any first steps that you would recommend to a software organization that are wishing to move towards a continuous architecture approach?

Eoin Woods 00:42:04 About to say greenfield system? Gosh, I’ve not seen one of those for a long time. I think the first thing is do you understand the principles and what they mean for people’s look behavior approach? And do you believe them? If you don’t, then you need to look somewhere else for how you want to achieve, just call it design really. I mean from an architecture, I mean how are you going to do design needs to be different and that’s not necessarily a bad thing, but if you haven’t sort got some sort of philosophical congruence with the principles, then it’s going to be quite hard to make it work. But what I always say start with the technical leadership team. Integrate architecture work into every work cycle, whatever you call your work cycle, sprint iteration. And even think about the five activities and how are you building the technical leadership across the teams.

Eoin Woods 00:42:47 And from the very beginning start thinking about what quality attributes are important and the product managers will look after the functions that will be fine. Start thinking about making architecture decisions very intentionally. Start thinking about the implications for technical debt. Even as you’re writing the first lines of code and everyone’s thinking it’s all going to be lovely and there’ll be no technical debt, we’ll know three weeks in you’ve got technical debt. So, start managing it. And feedback loops are an awful lot easier both culturally and technically to put in from the very beginning than in a sort of 7-year-old system. So, it’s a bit like design for testability, designed for feedback loops.

Giovanni Asproni 00:43:19 Yeah. Okay. And for legacy systems instead, this should be easier because you said he haven’t seen greenfield systems for a while so for legacy systemÖ

Eoin Woods 00:43:27 That’s right. It’s some of the same steps, but the constraints are very different. So, I mean step one is especially if you’ve got small number of all-powerful architects, build a technical leadership team around them and get them sharing what they’re doing and delegating and people working together to really understand the architecture. And then you’re sort of reverse engineer it. It’s what quality attributes do we have or what quality attributes should we have and how do we know what quality attributes we have? That sort of leads you to feedback loops. Do we know what the performance is in in production or are we just guessing? Do we know what the security situation is? If not, we should be putting measures into the pipeline and into production and so on. And what are the big architectural decisions that we’ve made? What are our principles? Let’s go and like work those out.

Eoin Woods 00:44:10 I did that actually with a, it was a company that does products, not the sort of products that, consumers would buy, products that big companies would buy. And for them it was a really interesting exercise because they got to where they’d got to, and they knew that wasn’t where they wanted to be. They weren’t quite clear how they got there. And so, one of the things they tried to sort of reverse engineer across a sort of broad team of technical seniors was what decisions have we made along the way? And it was really interesting in a workshop, people suddenly realizing, do you remember three years ago? Do you remember we decided to split the trade table, and we went, oh yeah, why did we do that? The sort of, it was mental archeology and there was certainly after a while you could start drawing timelines. There was a big split hit. Oh yeah, we did that. Oh, that’s what then caused these problems. I wonder should we rethink of that now? And it’s very different to doing it on the Greenfield project. It’s just you do the same things, but you do them in reverse.

Giovanni Asproni 00:45:01 Seems that there is a lot of fact finding at the beginning.

Eoin Woods 00:45:05 Definitely, though it’s also I think, super important not to try and boil the ocean as the saying goes. It’s to take it quite incrementally. If you’ve got a system that’s seven, eight years old, it’s got 150 people working on it, it’s got a product backlog and it’s got some demanding product managers, you are not going to change everything within a couple of weeks. It’s a question of taking small steps, like you might decide that what your key architectural decisions and principles are and managing some of your technical debt is probably all you can do to start with. And that might be a good first step. It’s sort of having some vision for where you want to get to and just like you would with the software, a roadmap for how you think you’ll get there.

Murat Erder 00:45:35 And again, back to like continuous architecture is a way of thinking and not the methodology. So, it’s just pick whatever works. I mentioned the essential activities, which are the things like core things you need to do, which is again, technical debt, quality attributes, architectural decisions and feedback loops. Right? That’s probably a good place to start. But also, one of my, I mean, years ago actually both Pierre and mine manager, because Pierre now used to work together quite some time ago, but he used to say architecture 50% of architecture is communication, right? It’s not about actually, it’s just communicating the decisions, communicating the principles or as own search communicating why certain decisions were made at a certain time.

Giovanni Asproni 00:46:21 A common problem I see with then, teams that work in short iterations say two-week iterations, which is a kind of common thing nowadays. Usually there is a problem with the time, lack of time, typical things have lot of meetings and other stuff to do and then sometime to write some code occasionally. Well, I’m exaggerating a bit, but I think you get the point. It is a common complaint. Now adding this work for around the architecture. So architectural decisions and feedback loops and decision records and all this stuff. How can development teams avoid being overwhelmed by this additional workload?

Eoin Woods 00:46:59 It’s no different to any improvement. I think you have to have the product management and the software development management, delivery management and teams believing in the value of this. So, they have to make room for it. It’s like, I’m sure you’ve both been in the situation, we’ve been on the system and the technical debt level has risen high enough that progress is starting to slow dramatically and it’s becoming quite hard to make reliable change that point the product managers have to one, accept there is a problem. Two, accept that they’ve probably caused it. And three, accept that in the short term they’ll have to go slower before they can go faster. Unless you can get those three points acknowledged, it’s very hard to get space to solve the technical debt problem out because they’ll just keep driving feature requests into the teams and getting annoyed when they don’t get their features in. I think it’s the same with this. It’s why do you want to improve your architecture work? Presumably that’s because you think there will be good outcomes, therefore it’s not a huge amount of extra work, especially in a decent sized team. But there is something that has to be incorporated into the delivery cycle.

Giovanni Asproni 00:47:57 Can it be that it’s actually the extra work is a lot of it is actually making the decisions explicit somehow. Because sometimes with things, what happens is under pressure, somebody takes some decision, but they don’t really communicate this in an explicit manner. They do stuff, they change their code in some ways to implement things. And here part of the extra work is actually making sure that those decision are actually explicit and communicated to everybody else.

Eoin Woods 00:48:24 That’s true. The thing that takes the time is making a good decision in the technical leadership team as opposed to one person just going, I’m going to make this pub sub because I can’t figure out how to do this using point to point messaging. I just go ahead and does it. A continuous architecture approach suggests that the technical leadership team should know that’s happening and there should be an ADR produced and reviewed and perhaps some discussion. That’s what takes the time. It’s do you want a good decision or the ad hoc decision.

Giovanni Asproni 00:48:50 And in terms of let’s say return on investment on the approach, how can an organization measure the impact of using continuous architecture?

Eoin Woods 00:48:58 So the only way I’ve found to do it has asked them what problems they currently are costing them time and money and establish why you at least have a credible theory for why using continuous architecture and maybe other techniques would help to address those problems. And then those problems resolving or partly resolving those problems translates to time and money. But there hopefully things you could measure over time. I don’t think it’s something that pays off in weeks. I mean it’s months and years.

Murat Erder 00:49:24 Yeah, and I think there’s two aspects when you think about the benefits of implementing countries architecture. One is obviously, you have more sustainable systems over time, you’d have less tactical debt. Those things are explicit. But also another way to think about is from an organizational thing, going back to our central team versus decentralized if done well you should be reducing the organizational friction. That might not, I mean that I think does over time impact the quality of the code anyway. If you have more organizational friction like we saw ago, I would say that you would have lower quality code, or you’ll have it more difficult to change code quickly enough. But regardless of that, part of it is about less organizational friction, focus on the team. Actually, happier teams, I would even go that far. Right? It’s about one reason distributed work and autonomous teams work so well is the communication structures and organizational friction I mentioned, but it’s also the people are happier, they’re more productive. So that’s just an, I mean, it’s not something you can quantify, but I think that’s quite important.

Giovanni Asproni 00:50:29 What is the impact of AI on software architecture work?

Eoin Woods 00:50:32 I think it’s still early days to work that out, but the two things that have been occurring to me recently are repository based AI agents like Claude. Seemingly can do a good job of keeping context because they’ve got a lot of information which they can index. And so, they should be able to have generic software architecture information expressed in text along with system specific software information perhaps expressed in graphs or structured formats as well as code. And I think there’s some potential for them to be used to sort of act as an architect’s assistant, answer questions, perform analysis ideas for how to improve or change the system. The other thought I have is I don’t pretend to be a professional, so software developer anymore, I write quite a bit of code for myself, but I haven’t written code that goes into production systems for a few years now.

Eoin Woods 00:51:26 But as I’ve used the AI assistance, I’ve had quite mixed results depending on what I’m trying to do with it. And the state of the code I’m trying to work on, and something I see reported a lot is that they work a lot better in an environment where the structure is relatively easy to discern and where set a constraint can be written down that quickly maps to the code. In other words, they work better when some aspects of the architecture of the system are quite good. So, it seems like architecture actually and also can code and DDD and more detail things have a role to play in making the AI software engineering tools effective.

Murat Erder 00:52:02 I’d agree with that. I mean, something we’ve with the teams I’ve been engaged with quite a lot is the to get real value out of holistic, GitHub CoPilot as an example is, better instruction files you write and you give more guidance to AI or more context to, more powerful than is, and actually one of the people I work with basically said that person to write that instruction file is the software architect, and that’s the term they use, right? So, in essence, you could say that if you have a well-structured system and you can articulate that in instruction file, you get much more value out of AI. So actually, to get value out of AI, you need I’m repeating what, so, but you need a good architecture. I think the principles still apply is still the way you, I mean, you’re still generating code, maybe the roles change, maybe AI does more activities and the type of skills you have change. But at the end of the day, AI and humans are still building systems that have an architecture and that still need to apply these principles.

Eoin Woods 00:53:07 Yeah. It can almost be summarized as AI will be really effective if we’re good enough to do it without AI to start with.

Giovanni Asproni 00:53:13 Sounds paradoxical, but seems to be about right.

Eoin Woods 00:53:16 Given that at some level, neural networks work a bit like the brain. To me, it makes some intuitive sense, and I don’t really pretend to deep in intuition as to how neural networks work at, especially at large scale. But given that human beings work better in well-organized code base where conventions are clear because it reduces their cognitive load, then you would think that perhaps a neural network also works better in that environment because when it’s going through whatever complex pattern matching it’s doing, the level of noise that it’s having to filter out in order to find patterns is much lower.

Giovanni Asproni 00:53:52 Yeah, makes sense. Now I’ve got one last question. How do you see software architecture evolving the coming years?

Murat Erder 00:53:58 Actually the future of architecture, I guess is not answer the question directly, but I’ll say something about the software industry in general. It’s a very young industry, right? And there’s so little knowledge transfer between different generations and each generation, the new technology comes along, and people forget some of the best practices from the former generation, et cetera. So, I think that’s just a wider observation on the software industry. It’s young. You don’t actually need to be a software developer. Yes, maybe a college degree helps, but you don’t really need it. Anyone who is, you know, can learn by themselves how to code. And now with AI can probably do that either quicker, can be part of the software community and the number of people doing development is increasing quite significantly. And I think we lose things between generations, and we try to remind ourselves, that’s why architecture, I think, goes in and out of fashion.

Murat Erder 00:54:55 So honestly, I have no idea how architecture will evolve in the future, but I think we’ll still follow the same pattern that there will be a period that will go out of fashion again and there will be a period that comes back in fashion, but hopefully we’ll get better. So rather than going in circles, we’ll kind of go in a spiral improving over time. But I think we’ll just go through these phases of it’s important, it’s not important, this is what it means. This is not what it means. But at the end of the day, I do believe we are building better systems and more systems than in the past. So, I think it’s just incremental improvements.

Eoin Woods 00:55:29 Well, I suppose in a sentence, I hope the future of software architecture is continuous. There’s a relatively few teams I come across have taken this approach up. Yet when it’s explained to people, often people say yes, that makes a lot of sense. And there’s definitely, there has been perhaps an unintentional drift towards architecture work being more about technical leadership and less about commander control. That’s very constructive and positive. I mean, I think the core of software architecture is dealing with stakeholders, dealing quality attributes, dealing with decisions and making trade-offs between them. And I don’t think that has changed from the 1980s. Well, I suppose software architecture merged in the 1990s. I don’t think that’s changed the 1990s. We are quite a number of years on from there. So, I don’t see that changing. I see the environment that people need to do that in and the technologies they need to do it with perhaps being different. But I think that fundamental core has been unchanging. So, I don’t think that’s going to change.

Giovanni Asproni 00:56:29 Okay. Sometimes talking about these things is kind of in my head, looks like back to the future because there seems to be a lot of things that have been the core of what we do has been the same for many, many years. But somehow, as Murat said, we tend to forget things and then rediscover them again and again.

Eoin Woods 00:56:47 We do. Yeah, we do.

Giovanni Asproni 00:56:48 Yeah. But I like the feature of architecture is continuous. Sounds like an ad.

Eoin Woods 00:56:54 So yeah, that could be also slogan. Yeah.

Giovanni Asproni 00:56:57 Wow. We’ll come to the end now. Thank you very much Murat and Eoin for coming to the show. It’s been a real pleasure. This is Giovani Asproni for Software Engineering Radio. Thank you for listening.

[End of Audio]

Tagged as:
Join the discussion

More from this show

Menu

Recent posts