GOTO - Today, Tomorrow and the Future

Continuous Architecture in Practice • Eoin Woods & Simon Brown

August 20, 2021 Eoin Woods, Simon Brown & GOTO Season 1 Episode 23
GOTO - Today, Tomorrow and the Future
Continuous Architecture in Practice • Eoin Woods & Simon Brown
Show Notes Transcript Chapter Markers

This interview was recorded for the GOTO Book Club.

Eoin Woods - Co-Author of "Continuous Architecture in Practice" - @eoinwoodz
Simon Brown - Author of "Software Architecture for Developers" - @simonbrown

If you are aiming to achieve the really challenging Internet-style quality attributes about speed and performance and scale you will need a really good architecture. This implies keeping things in sync and having a pragmatic approach. Rather than going after the hyperscalers you can build your own way.
Learn from Eoin Woods and Simon Brown how UML and evolutionary architecture can help you achieve that.
The interview is based on Eoin's book "Continuous Architecture in Practice":

Read the full transcription of the interview here:

Woods, Erder & Pureur • Continuous Architecture in Practice •
Woods & Rozanski • Software Systems Architecture •
Simon Brown • Software Architecture for Developers Vol. 2 •
George Fairbanks • Just Enough Software Architecture •
Erder & Pureur • Continuous Architecture 1st Edition •

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.

Manufacturing Matters
Insights and interviews discussing trends, innovations, and advanced automation technology

Listen on: Apple Podcasts   Spotify


Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket:

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily


Simon Brown: Welcome, folks. So my name is Simon Brown, I'm an independent consultant specializing in software architecture. I'm the author of a couple of software architecture books. Joining me today is Eoin Woods, who's the author of another bunch of software architecture books. Eoin, do you want to introduce yourself quickly?

Eoin Woods: Thanks, Simon. Hello, I'm Eoin Wood. I'm the CTO of a company called Endava. Simon and I have known each other for a while, one of the reasons being we've both written some software architecture books. I've written a couple, one called Software Systems Architecture with my good friend Nick Rozanski. And one more recently with Murat Erder and Pierre Pureur which is on continuous architecture. It's the second of two books on continuous architecture. This one is called Continuous Architecture in Practice.

Software Systems Architecture

Simon Brown: Awesome. We should get into the title of that book a little bit later on.

So I remember reading certainly the second edition of Software Systems Architecture probably... When was it released?

Eoin Woods: The second edition I think was 2005?

Simon Brown: Yes

Eoin Woods: I'm actually getting lost myself.

Simon Brown: Yes, it was the latter half of the early 2000s, wasn't it?

Eoin Woods: Yes, it was.

Simon Brown: So I remember reading that at the time and that was kind of just after the Agile movement came around, but just on the tail end of the waterfall, RUP, UML sort of movement.

I remember being a big fan of the book, still am a big fan of the book, it's on my recommendations list. It's a book about two things though, right? It's a book about architecture and processes and things, and it's a book about documentation. Both of these topics have been, let's say, shunned over the past decade or two decades. What are your thoughts on that, and is the book still relevant for today's audience?

Eoin Woods: That's such a great question. Yes, it was a funny time to be writing the book because it has its roots right back in the early 2000s when I was working in Silicon Valley and Nick was working as an architect in the UK, mainly on big finance projects. We were both realizing definitely waterfall wasn't the answer, that had not been the answer for some time and probably never was. RUP was quite mainstream, but RUP was starting to get sort of almost undermined by a sort of tool-selling process and it was becoming quite a waterfall, it was becoming very document-centric.

We realized that really we had to somehow try and write a book that was relevant to people who were going to do a lot of big design upfront, as it used to be called. But, also, we wanted to stress the fact that if you were going to do a big design up front, it had to be valuable. That was something that seemed to us, seemed to be getting lost at that time. People were just producing documents because they were told to produce documents.

So that was really part of the inspiration for the book, as we both believe in capturing things, Nick calls it writing stuff down. I prefer just capturing because there are all kinds of ways you can capture information. It's about having the information. But, for goodness' sake, make it valuable.

So I think the book is a little bit context-dependent, it's very much the book of its age as the world was moving between these two worlds. But in terms of more recently, I think we've had this conversation a few times, I mean, there's a tendency to go Agile and don't write anything down. That's not what the manifesto says, it's not what any leading practitioner says, it's not what any successful Agile team has ever done, but somehow it gets interpreted that way, just the same way RUP used to be. RUP has got all these possible documents I can write, "I'm going to write them all." So for some reason, people often take a pretty simplistic view of an approach, and unfortunately, that doesn't normally end up being successful.

So I think that's where the book stayed at least somewhat relevant. We're still selling copies, which is really nice. And people are still referring to it and people are still getting value from it. Because there's a lot of what's in it, actually, we have to straddle the two worlds. So I hope it's pretty pragmatic and it emphasizes doing useful things rather than doing things for the sake of doing things.

Simon Brown: It's also used in a bunch of universities and courses, I believe. Is that right?

Eoin Woods: It is used quite a lot in academia, that was a great surprise to us. When we wrote the first edition, we had no ambition at all of reaching academia. Completely written for people developing systems every day, because that's what we did. Then when the first edition was out, we got quite a few e-mail messages from academics saying, "Could we have the slides, please?," or, "Could we have the worked examples?" And we went, "Well, we haven't got either of those. Why did you think we would?" And they said, "Well, it's really useful for teaching, we use it all the time. And the normal protocol is if you want us to use it for teaching, you write the slides." Well, we didn't ever write the slides, but luckily they kept on using it. And actually, now we still get approaches from master's students who are using it as their inspiration for a thesis or it's being used in some teaching.

So I think, again, it is about straddling the two worlds. I have more of an academic background than Nick, Nick has got a really practical industrial background. So we were able to bring both of those things to bear so the book is relevant to practitioners, we're still selling there and they're our primary market. But actually lots of academics who want to prepare students for real industrial work seeing it as a kind of pragmatic text, but it's founded in some quite sound academic principles.

Simon Brown: Yes, that's really why I like and still recommend the book today. It's because if you look at some of the, let's say, older software architecture books, some of those are very theoretical, very dry, and very kind of academic-focused. But your book has that nice mix of two. There's lots of theory there, but you also describe how to do it in the real world. Which, I think, at the time it came out that was something that was really kind of missing in those sorts of texts.

What does "viewpoints and perspectives," refer to?

Simon Brown:  The subtitle of the book, "viewpoints and perspectives," what's that about?

Eoin Woods: Yes, so that's really where we started. We nearly called the book Viewpoints and Perspectives. I think we talked to a professional in the publishing industry who looked at us with horror and said, "Goodness no, tell them what the book is about."

So viewpoints are really where we started. I discovered this thing called viewpoints when I was working in Silicon Valley. Because I had a real software architecture problem. I was working as the software architect for a new software product line and we needed to describe it, we needed to write down the fundamental principles of how it hung together. And I, like most people, started drawing boxes and lines and had some information on there and a bit of how we would deploy it and a bit of software structure, and nobody really understood it.

Then I came across this paper, the "4+1" paper, as it's known, by Philippe Kruchten. That really started my personal journey into some meaningful, you know, kind of relationship with software architecture. Because Philippe's paper points out that there isn't one architectural structure, there are many architectural structures. He indicated four. We actually started there and with those structures, Nick and I started using them in our everyday work. We came across a few limitations. Nick was doing a lot of systems that had a lot of data in them, so he needed an information data type view and there wasn't one of those. When we came to using products and dealing with software products that were in operation, there was nothing in Philippe's set to talk to the people in operation...the operations people about.

So we started extending it a bit. Then as we thought about it a bit more, we realized one of the things that software architects need to obsess about, that you talk about a lot in your work too, is system qualities, quality attributes, so performance and scalability and resilience and security and all those things. We started thinking about creating a security view, and then we'd need a performance view, and we'd need, back then we called it, a high-availability view, and so on. Our views were exploding. We realized that when we actually came to do it for real, we actually tried this, we were duplicating lots and lots of information between the views. That's when it sort of hit us, "Actually, you don't create a view for security, security is something that all of your views need to be affected by." So that's why we said, "Don't create a security view. Here's the advice on how to think about security in the context of your other views."

A view is a way of describing one aspect of the software system, one kind of coherent structure. So this is its functional structure, how are you going to deploy it, how are you going to operate it, and so on. They're normally written from one particular group of people who care, that's the jargon the "stakeholders." So that's who cares about the functional structure. Well, not the operations people, they really, really don't care. They care a lot about what's going to go wrong, how to monitor it, and how to pick it back off the floor when it's gone wrong. So it's a very different set of concerns. Each view addresses some of those people.

Once you've got a candidate system, the perspectives are about how you think about these cross-cutting concerns, as we call them, like security, performance, scalability. How do you revisit each of those kinds of structures and think about the impact that meeting that software quality, that quality attribute, is going to have on that structure?

So that's how we came up with "viewpoints and perspectives." It would be fair to say that viewpoint...our set of viewpoints has had quite a lot of impact, it's cited quite a lot. Perspectives considerably less so. Quite a lot of people know about perspectives, not that many people have picked up the idea. In the academic literature, there are probably two, three, maybe four new perspectives that have been added by software architecture researchers.

Simon Brown: It's kind of weird, isn't it? People...if you ask them to think about a software architecture document template, they'll be able to list out the various sections that they think they might want to cover in their documentation set. But very few people, it seems, have heard of something like "4+1." Which, of course, is the essence of all of the stuff, it's, "Let's look at our software system from different angles."

One of the big additions you made in edition two of your book, and I know we spoke about this before, was the context.

Eoin Woods: Yes.

The Context View

Simon Brown: Do you want to tell us about that?

Eoin Woods: Yes. That is actually quite interesting. So that was a badge if idealism in the first book. We said, "Well, clearly they'll be people who already have a vision for their system." And we didn't call them product owners, I think we called them acquirers, the people who really know what the system is going to have to do. "There will probably be business analysts involved and it will be very obvious where the boundary of the system is."

Then, well, we realized after a while that, when we looked back at our real experience, that was almost never true. When there was some idea about the context, it was always wrong because people hadn't actually thought through the technical implications of where the system boundary was.

So when we came to the second edition, we just thought, "No, this isn't credible, is it? We're going to have to add a context view. Because we nearly always end up doing a context thing, that is outside the architectural description. We should just include it in the architectural description, it's so much neater and cleaner. And if there's something preexisting, we can always inherit it and evolve it a bit further." But I'm afraid we were just a bit optimistic and kind of ignored practical experience at that point.

Simon Brown: Yes. The number of architecture documents I've read in the past where you kind of get through the first 10, 20, 30 pages, and it all goes into, like, very technical details very quickly, and you're kind of left wondering, "What is this thing and who's using it and why are we actually building it?" And all of that context, as you say, is kind of missing. So yeah, I really like the way that was embedded into the viewpoints and perspectives that you first put together.

Eoin Woods: That's a great point, is that one of the key things about any deliverable, any artifact you create, is you need to think about who's going to use it and what are they going to use it for. Because otherwise, as you suggest, you just end up writing pages and pages and pages that may or may not be of any use to anyone and they just become really sort of technical debt immediately, they just become a liability. Because they become out of date very quickly or, in fact, they completely misrepresent how the system really works.

The minimum package of software architecture

Simon Brown: This leads me to my next question. So one of the things I see a lot of people talking about at the moment is what should our minimum package of software architecture documentation be. What are your thoughts on that question? For teams who have nothing now and are looking to create something.

Eoin Woods: Yes. I think it's terribly context-dependent and I always start really from, "Who cares?" And we said the jargon word for that is your "stakeholders." But they're the people who care. Some people care in a very positive way, and they want your system and they want it to be a success and they try to cheer you on. Some people frankly maybe, at best, rather indifferent as to whether your system is successful, or may want it killed at birth because it in some way causes them a problem. But they all have a view and they've all got influence. And I think we're trying to serve those people.

I mean some of them are obvious, the development team. I hope the development organization let the architects in, they are very obviously major stakeholders in architecture. It affects them directly, they're part of creating it, they're part of evolving it. Some people like end-users are pretty obvious. They maybe don't understand quite how the architecture works, but they may need a lot of consideration during it. You've got people like the operations group we talked about, infrastructure. There are various groups who may want to know. Then there are some people who aren't obvious at all, at least when you start out, like compliance in a bank. I mean who would have thought you'd have to have a software architecture view for compliance? Actually, as I discovered many times, if you ignore compliance until the last minute, you're just not going live. There's no negotiation, they don't care how much money has been spent, you're just not going live. So actually it's really important to have some kind of architecture and artifact that addresses them.

So that's where I start, is, "Who cares?" And in most cases, the people who care are the people who have to build it, the people who have to operate it, and the people who have to sit in between those two worlds. I hate the term "DevOps" people because I don't think there's anything such thing, I think DevOps is something everyone does together. But I think of them as the people who are maybe infrastructure designers, application management experts, and so on. Those groups are probably the minimal set. If you can't explain what the structure of the system is and what are the guiding principles and how to evolve it, if you can't explain where it's going to run, how it's going to run, what it needs, and if you can't explain how to operate it, you're probably in a bad place.

Then the other group who don't always want to know, but they quite often want to know, are the people paying for it. So we call them the acquirers. They might be the product group, that kind of people. Then some of them are very hands-off, I've found, about architecture. It's really, "Just make magic happen, I trust you." But in many cases then, of course, if something goes wrong, then they want to know why they didn't know.

So actually the people who are responsible for shaping, the funding, and the functional trained features going into it and who are maybe accountable for the business results, it's important to have some sort of architectural description for them so they understand all the trade-offs you've made. Because whether they understand them or really care, those trade-offs actually have a big impact on the potential success of their business. So it is important that something caters to them. Whether it's unlikely to be the same architectural description that you and I would like to sit with a dev team and kind of debate for hours, but they do need something that explains what those trade-offs are.

Simon Brown: Yes. Previously we've had lots of people say you don't need to write documentation because you should write self-documenting code, clean code. There's been this big kind of anti-documentation movement over the years. And I think if there's one benefit, potentially, that's come out of this COVID thing, it's that teams have realized that, "Oh, everybody is not in the office anymore," they can't have those conversations as easily as they were before. "And we've not written anything down, so, oops, maybe we should start doing something." So I think from my perspective that's why I'm seeing a lot more teams figuring out how do we do documentation.

So that kind of brings me back to my initial question about how relevant do you think your book is in today's world, and I think it's hugely relevant.

Eoin Woods: That's good to hear, thank you. Yes. I mean the thing about architecture in code is really interesting. So we have a mutual friend, George Fairbanks. Who, in his book Just Enough Software Architecture, which is aimed very much at teams, talks about this idea of architecturally evident coding. And, I mean, it's a really simple idea, but quite often you don't end up with it.

I mean all George is saying is if you've got an architectural concept, I should be able to go to IntelliJ, assuming I'm using Java, and search for that name and I should find it. I should find it in the right place with the right features and functions and what you'd expect from the whiteboard sketch. And that's true. The problem is that the programming languages we've got today, and to some extent the frameworks, don't actually make the architectural structures very obvious. A lot of architecture, by the time you get into the code, it's really a convention. And the problem with convention is you've got to infer it, you can misunderstand it, and sometimes people completely ignore it.

So that's why even if the architectural description is a little bit idealistic and it's not always followed and it doesn't quite match, I think knowing what the key abstractions in the head of the person or the people who put it together and actually how they thought the system should work, that's tremendously valuable five years later when you're 500,000 lines of code in and you need to make a change and you can't really understand why changing it in one place seems to have this ripple effect you just didn't understand.

Simon Brown: Yes, totally agree. Yes, it's super essential and I think a lot of teams have not got to that point yet. So I see younger, less mature teams from an engineering perspective. Those sort of teams are typically shown documentation. And you're right, maybe in two, three, four, five years they might realize, "Oh, perhaps we should have written some stuff down because we forgot it." And I guess that's why architecture decision records are becoming much more popular because now we can record that set of decisions that ultimately got us where we are today.

Eoin Woods: Yes. I mean I think that's very much, actually, how teams that don't want to produce lots of pictures, if you like, or models ideally, yeah. If you capture your style that you think the thing has, as in what kind of patterns you're using, could you capture your decisions? That will be so valuable in two or three years' time, the rationale for those decisions. It's not a new idea, I mean we've been capturing decisions, even checking them into the code, for decades. But again, relatively few teams do it and it's really good to see it now becoming quite popular again.

UML in 2021

Simon Brown: Yes. One of the things I think put people off documentation was UML. What are your thoughts on UML, today in 2021?

Eoin Woods: Yes, it did. So some years ago, was it 2017? You and I did a joint conference talk on UML, didn't we?

Simon Brown: We did, yes.

Eoin Woods: That was very fun.

I've been an advocate for UML for quite a long time. And I'm well-known... Actually, I'm known in the UML community for not being very keen on UML and I'm known outside the UML community for being an absolute pro-UML bigot. So I've clearly offended both groups quite effectively. It's a gift.

Certainly, I have found a lot of value using UML over the years, as I explained on that conference talk which is still knocking around and I think I've documented many times. I used to joke it's kind of the worst architecture description language apart from all the others, and that for certain kinds of architectural documentation UML has been very valuable. However, I was always qualifying that and saying it's very valuable, providing you're building a model, as in something that's real data as opposed to just drawing some pictures. Secondly is that the people you're talking to understand it. And thirdly, that you tailor UML enough to make it specific so you actually know what a particular kind of box on a diagram actually means, it's got some relation to the real world, you don't just sprinkle UML-generic components all over the place because no one knows what you mean then and you'll probably forget.

So with all those qualifiers, I have to say that it's becoming increasingly difficult in 2021 to see why most mainstream teams will use UML. There are relatively few people, for better or worse. The reality is there are relatively few mid-career engineers today are fluent in UML and tailoring UML. Relatively few teams have access to good UML tooling. And when you just go down the software industry in general, you don't find a fluency with it or any sort of natural affinity with it which allows people to understand it quickly. So actually, if you're not careful, using UML sort of defiantly today can just become a barrier to communication.

Simon Brown: Yes.

Eoin Woods: The lessons from UML now, which I think one of the great things about your book, you keep on reiterating these simple points but you make it really clearly, is you make sure that you know what the style you're working on is, make sure you know what your building blocks are and what they mean, make sure that you're very consistent in your diagrams, make sure you've got a key so that somebody can look at the diagram and quickly pick up, "Why have you used a dashed arrow there?" I come across so many diagrams just like the ones that you kindly parody in some of your talks where, they've used four different arrow styles, and there's no key, and I have no idea whether they just got bored of one arrow style and thought it would be visually pleasing to use a different one or it's critically important and I have to understand that's a different thing. It just devalues so much of the good work they've done to try and think out how their architecture works.

So yeah, as much as it grieves me to say it, I think today it's quite difficult to see where UML fits in mainstream software development practice, outside of specialized environments where they've got lots of tooling, it's very well understood, they could do code generation off it, you know, and where that's actually valuable. There are domains t that's true in, but for a lot of us that's probably no longer the case.

Simon Brown: Yes, I mostly see the same sorts of things. So UML is big in regulated environments, automotive, those sorts of more precision-based engineering environments. If you guys have read it, UML dies every week. I mean there was a blog post last week that says "UML is dead again." It's a tough sell, isn't it? I mean it's just notation, ultimately. It's just a bunch of boxes and lines and people can use it however they want to. But even suggesting teams use UML for drawing diagrams, like, "No, that's not for us." And it's just an instant knee-jerk reaction probably based on fashion.

Eoin Woods: Strangely the thing that I've seen a lot more recently is ArchiMate. Which, for years and years, struggled to make itself heard in the din of no documentation versus UML. Now somehow it seems to have poked its head back up and I've seen more ArchiMate in the last two years than I did in the previous five. Which, again, surprises me.

Simon Brown: Yes, same here.

Eoin Woods: Because actually, you need to understand the notation, you don't need to understand the semantics, you probably need to have some kind of a tool. But actually, it seems to be popping back up.

So yes, as you say, these things come and go. Maybe UML will have a third age, who knows?

How do you keep things synced?

Simon Brown: Who knows? One of the things you said, and this comes back to your viewpoints and perspectives approach, is if you've got, say, a bunch of structural diagrams, and then you want a security perspective and a performance perspective, how do you keep all this stuff in sync? You mentioned modeling, didn't you?

Eoin Woods: It is actually really difficult without a model. I mean that was one of the reasons that I found great value when I was doing architecture in large finance environments. They were big and complicated. Honestly, when you'd understood something and you wanted to capture it at an architecture level, either system of systems, so EA level, or within a complicated system, you wanted to keep that knowledge safe. Also, you wanted to reuse that knowledge in PowerPoint, extract it into Excel, you wanted to be able to use it maybe to, you know, generate something from it.

So actually that was the value of the model, was that once you'd captured the knowledge as a model, you could generate different diagrams very quickly and just modify colors and shape and position, that sort of thing. Then when you change the name here, it would change everywhere, and so on.

Honestly, today I think people generally aren't creating models. And by "models," of course, I mean a data-driven representation of their system from which they can create diagrams. If they haven't got a model, the advice has to be to keep it as simple and minimal as possible, but also to be very aware that consistency is no longer guaranteed. So when a name is different on one diagram to another diagram, you can pretty safely assume that something has changed and you should go and sync your reality with the code because, for whatever reason, some thinking has moved on and something has changed.

Unless people are happy to go back to creating models, and I don't sense that outside creating the DDD type models in code, I don't sense a great enthusiasm for creating models outside the code itself. Even Structurizr, you know, hasn't become an industry standard. Of course, it's your approach to how you use that code as the base, and then very cleverly you then use code structures to represent more abstract structures around it. It's been successful, it's well-known, but you don't go into every software engineering center and see Structurizr in use. A great tragedy for you personally, I'm sure. But as much as we would promote it.

I mean Structurizr is a great approach, it uses the advantages of code with some of the advantages of models to create architectural descriptions. And that will, of course, keep everything in sync. As you compile it, it will quickly point out you've got something wrong. But I just don't see huge enthusiasm for it.

So the advice has to be to keep it as simple and minimal as possible and make sure that you actually spend a bit of time and effort curating whatever descriptions you've got. Because the longer you leave them without any editing and curation the less valuable they're going to be.

Simon Brown: Yes, it's a really hard sell to get people off diagraming and into modeling. I think there's a very negative association just with the word "modeling." "Modeling" sounds like one of those things we used to do with Rational Unified Process and UML and big design upfront, and that was something we threw away in the early 2000s. And, of course, it is fairly straightforward to take a nice lightweight approach to building a model, and then you can surface different viewpoints and perspectives of that. But there's some effort involved in creating a model, right?

Eoin Woods: Absolutely.

Simon Brown: It's a hard sell, it's a hard sell. Lots of people I see are big into creating diagrams as text with Mermaid and PlantUML and things like that. And they'll create multiple versions for multiple different views of the same information, essentially, but they're still not willing to go that next step and kind of converge everything into a single definition. Maybe we'll get there one day. Who knows?

Eoin Woods: Maybe. Maybe we need to get better at identifying tangible benefits or explaining them better.

Simon Brown: Yes. What I find quite funny is when I run my workshops, I explicitly point out that now you've drawn two different pictures of essentially the same thing at two different levels of abstraction. "Wouldn't it be nice if you had a tool that when you renamed this thing here, this thing here changed?" And they're like, "Oh, that would be awesome, you should build that." I'm like, "I have done, but it's a hard sell."

Eoin Woods: "All you have to do now is use it.

The difference between evolutionary and continuous architecture

Simon Brown: Yes, exactly. Yeah. So I think we've covered quite a lot of stuff for software systems architecture. So moving on to continuous architecture in practice. Lots of people will probably be familiar with the term "evolutionary architecture." What's different about continuous architecture?

Eoin Woods: Evolutionary architecture and continuous architecture, I'd say, are related, but I would suggest evolutionary architecture is a looser idea and it's more a set of techniques, patterns, practices to help you create an architecture that is possibly evolvable.

Continuous architecture is an approach that Murat and Pierre, again based on the long, long period of industrial practice, kept finding that they had to react to Agility when it arrived, and they saw continuous delivery arriving, and they saw DevOps arriving.

They saw more and more of their colleagues just couldn't relate their architecture work to working in this modern world where you had lots of stuff happening in parallel because, micro or not, people were doing service-based computing, so they want...teams were more autonomous. They didn't react very well to the fact that people wanted less design upfront because they recognized they knew less, they wanted to learn more through the process. They would take more risk. They weren't very interested perhaps, to be honest, in dealing with the ops group and all the messy details and awkwardness of production operations, they just wanted to sort of set the big blueprint.

Murat and Pierre, they've known each other a long time but were working in very different environments. They just stayed in touch, as Nick and I had. And they were both talking about this and they were evolving their practice. And then, I suppose, was it seven or eight years ago now? They said, "You know, we don't see anyone else who's really explained how to do this. Maybe we should just write it down."

So they wrote their first book Continuous Architecture and they identified some principles to help you think about the fact that architecture is an activity, but it's not an activity that has to be done by one person all up front, done once, and then abandoned. Continuous architecture is turning that on its head and it is saying, "Architecture is a team game. The entire team, or as many people on the team as possible, should feel part of it." Of course, some people will lead more, some people will follow more. But people feel ownership of it. And it happens right through the life cycle. Because the further we go through the life cycle the more we know. So therefore there's been this idea of deferring your architectural decisions for quite a long time, but not really too much advice on how you might go about doing that or how you might think about structuring the architecture more to support that.

That's what continuous architecture is all about. It's about doing architecture all the time, a small amount in every sprint, making sure that you're thinking about the build, test, deploy, operate, as well as just build. It's about making sure that you shape teams so that they fit in with the structured system that you want. It's about thinking about the fact that if you build smaller things, then you get more parallelism, autonomy, you get more ability to change, at a cost of more complexity. It's about thinking about that trade-off and not always just going, "Microservices." It's about thinking, "What granularity do I need?" But, you know, there is power in small, it's recognizing that.

I met Murat first, we met through an industry event and we got chatting. And we were both working for big banks at the time, we had a lot in common, many of the same pain points, both working as architects on similar projects. I read the book.

Some years before, before the book but certainly, before I'd known them, I created a conference talk called "Agile Software Architecture." That was based on my experience at a big bank working with Agile teams on how architects could be really valuable to Agile teams and not just, like, these awkward Mr. "Say No" who gets in the way but can actually make these Agile teams better. That had been quite successful. I gave that talk five, six times, and then sort of forgot about it, really. I think I wrote an article or two, and then it just kind was just there. They hadn't seen that. But when I read their book, I thought, "Well, this is all very similar."

I got talking to Murat, and then I met Pierre at another conference. We just got talking that their first book they liked, but they felt it wasn't really practical enough. A lot of people had immediately contacted them and said, "I sort of get all these principles, but I'm not quite sure what I actually do." They have a process, but the process doesn't...the process only tells you how to structure your work. Because that was the goal, it was about we know...the assumption is you know what you're doing, what you need is help in rethinking about how you go about the work, not how to do the work.

So that then led them to think about a second edition. They contacted me and we talked about, you know, how they might go about that. The second publisher suggested, "Maybe, given Eoin Woods has got some very specific knowledge and interest in some of these qualities, maybe he should join." So the three of us came together and we formed the book a bit.

That's how the second edition came around, it was, "We've got to take a step beyond assuming that all the knowledge is there and that all we have to do is nudge people in the right direction to rethink how they engage with the team. Maybe we should be giving actually just pragmatic practical advice, based on the fact that all three of us have built a lot of big systems." When we say, "You should do security continuously," "Okay. Well, where would I start exactly? Because the security team turned up and told me to do it all at the very beginning or all at the very end. But, so how do I change that?" So we have chapters on security and resilience and performance and scalability, and we've got all of the data. Which is a big sticking point because, of course, data tends to be one of those things that either makes a system really easy to change or really hard to change, depending on some of...often quite early decisions.

Pierre has just retired, actually, after a long rather distinguished career at Travelers. When he was working there his last couple of years, he actually stepped out of day-to-day architecture and went to look at innovation. Because they wanted to make innovation far more impactful. One of the things they noticed was that it often didn't fit with how things actually worked in their real system. And so Pierre worked on how do architects work with people doing innovation projects so that they don't just create isolated PoCs that are cute to have but will actually be immediately usable with the mainstream enterprise platforms.

So he had quite a few insights on that. We also put a chapter in on how, as a continuous architect, you can be continually working with these fast-moving innovation groups, because this new approach to architecture is very relevant to them. They'd never engaged before. Because they said, "By the time you guys have drawn your pictures and waffled a bit, we'll be done. We only do this for three months, see you." Whereas, you know, architects that used to work in two-week cycles, suddenly they talk a much closer shared language. So that was another thing we put into the book. At the start, it recaps the whole continuous architecture idea.

We hope it's going to bring some practical useful guidance to people who are thinking, "I'm a tech lead. I definitely don't want to be one of those PowerPoint kind of architects, I want to be with the team every sprint doing useful stuff." And to help them think about, "How do I structure that work so I don't get caught up in the kind of, yay, PowerPoint upfront conundrum?" But also when they say, "How do you do performance continually as opposed to upfront or at the end? What would I do?"

There's some kind of practical chapters to get them thinking about the key qualities. They won't be the same for every system, of course, but we found that some of those key qualities are important in most systems.

Simon Brown: So the book is out in, I think, August this year, is that right?

Eoin Woods: Quite soon, yes.

Simon Brown: In the summertime?

Eoin Woods: Sometime over the summer.

Simon Brown: I've read a copy because you sent me a copy a couple of months ago to read as a kind of peer review.

Eoin Woods: Thank you very much, yes.

Simon Brown: No problem, you're welcome. Really enjoyed the book. The thing I do like about the book is that you you just said, you do focus on those trade-offs. So you'll say, "Here's a performance characteristic, here's a system design, and these are the various ways we can tackle it and these are the characteristics of the design approaches and also the trade-offs that we're making here."

And that's the thing I really like about the book. It's not, "Do everything the same way," it's very context-specific, and you kind of point people to think about the decisions they're making and really consider the trade-offs. And that, I think, is something I see a lot of teams not doing these days. They're just rushing in, they're being very fashion-driven, "Oh, we're going to go serverless and microservices," they're jumping on that distributed architecture bandwagon. Then three years later guess what they've got, this horrible, brittle, messy thing which is really, really slow.

Why Software Architecture is More Important Than Ever

Simon Brown: The first chapter of the book, let me just read it. It has a subtitle called "Why Software Architecture is More Important Than Ever." Do you want to explain a little bit more about that? Because this book seems like a reaction to the whole Agile thing, in some senses.

Eoin Woods: Yes. It's not an explicit reaction against Agile in any way, it's just trying to recatch why doing architecture as opposed to drawing pictures is actually really important in an Agile context and it sort of never went away. And our point is if you're going to try and move really fast, change your system all the time, have loads of parallel activity going from all of your different service teams, pushing stuff into production every couple of days, you better have a pretty good architecture to support that.

Because people kind of glance at the hyperscalers and go, "Well, they do it." I mean I lost track of the number of times I've talked to a client who wants to do something, dare I say it, slightly balmy and they go, "Well, I read this is what Google do." I stop and go, "Yes. And how much are we thinking of investing?" And of course, it's always a very, very small amount. "Well, Google invests 1,000 times that you know, every year, so you're possibly in a slightly different environment to them."

So what we were hoping to do was just sort of...we hope it's reiteration, we don't think it's some radical, recatching of architecture, but it's more almost reminding people of how important good architecture is, or good architecture work is, how important the architecture system is. If you're going to achieve these really, really challenging Internet-style quality attributes about speed and performance and scale and all these things, you're going to need good architecture. So that's why we thought it was important.

Simon Brown: Great. And one of the things I've been kind of banging on for years about is teams need to create firm foundations. If you want to move fast, you need good structure, you need to think about these things, because it doesn't happen on its own. That's how teams get lots of technical debt and they get messy codebases and they just get your systems that are really hard to kind of look after and maintain and enhance.

There's a fine line though, isn't there? There's a fine line between, "Let's design all the good stuff up front and put some really, really, what we think are firm foundations. And let's just write code and kind of hope for the best and do the evolutionary architecture thing." One of the things you focus on in the book, and I really like this, is that approach to shifting the architectural thinking and decisions left. But of course, there's that fine line between how much is too far left and when do we kind of enter into the big design up front world.

Shifting the architectural thinking and decisions left

Simon Brown: Thoughts on shifting left?

Eoin Woods: Yes. That's a really good point, actually. It's easy to misunderstand. We use the term "shift left" quite a lot to indicate that architecture type thinking, which is often... We're talking about qualities. And we're reacting to lots and lots of experience where people start worrying about performance once they're in the final test of some huge six-month release. What we're trying to point out is that all the quality attribute thinking needs to be pushed way, way back into the sort of...not entirely at the front, but throughout the cycle.

It is easy, we realize now that we reread the book ourselves, to think what we mean is to shift it all left into a big heap at the start. That's not what we're saying. What we mean is we're trying to smooth it left. We should have said "smooth it left." We're trying to smooth it through the cycle so it's kind of a constant thing.

There are some things that probably do need to be decided fairly early. I mean obvious things would be, "What's the fundamental architectural style for our system? Are we going to be monolithic or are we going to be serverless?" Because they're such extremes, you're going to have to have some idea about that quite early.

We don't talk a lot about it in the book, we allude to it a little bit. Of course, we also think the basics of fundamental software engineering, like clean code and software craftsmanship, is really important because they keeps the code maintainable so that if you've got a lot of serverless functions, perhaps you will be able to recombine them. If you've got a monolith, you want to be able to decompose it, that's important.

But that was the idea for "shift left." And the balance, you're quite right, is quite a subtle one. And it's one that honestly it's very context-dependent. It definitely relies on a certain degree of experience, but it's about making the minimum number of decisions upfront, and then spreading architectural work such that rather than pushing architecture out of the delivery life cycle, seeing it as a thing that happens first, you have to put some stakes in the ground, you have to make some decisions. And as you go through your constant delivery life cycle, having architecture work all the way through. Because, as we said before, the further you go, the more you know. The more you know, the better the decision is going to be.

Simon Brown: Yes. I guess it's about making teams think about the trade-offs and the consequences of the decisions they're either making now or the decisions that they're deferring. Because, of course, one thing you hear a lot Agilists say is, "Well, let's defer everything, let's not make any decisions until the last possible moment." And, of course, that sounds good, but the thing is a lot of teams don't realize that that last responsible moment is actually really early. Like with your monolith microservices or serverless approach, that's something you do need to decide fairly early, otherwise you completely go down the wrong track.

Eoin Woods: Yes. Well, it's like the old joke in manufacturing engineering about just-in-time delivery is always just too late. It's very easy when you're thinking about making your decision at the last responsible moment to discover the last responsible moment was three weeks ago.

It's funny, Sandro Mancuso and I, the leading light in software craftsman, is a fantastic software engineer. We both worked at the same big bank at the same time. And it would be fair to say that we get on really well, but also we had plenty of heated disagreements about the last responsible moment. There is no easy way to spot it. I think my bias is probably maybe different to Sandro's. It's to decide slightly earlier, but constantly as an architect or as a designer or as a tech lead be thinking, "How can I unwind this decision? What are the implications of making it?"

I think one of the really important things to get through to teams, and so we're sort of trying to democratize the architecture here, we don't want an architect making all the decisions, it's a shared collective. However, that places responsibility on you. When you're making a decision that has a trade-off for other people outside your kind of local responsibility boundary, you better think about the trade-offs for everyone else as well as just worrying about your delivery date this sprint. That sort of changes the dynamic a bit and hopefully gets people to think about the overall system qualities as well as my system qualities for my service and getting to production.

Simon Brown: Of course that loops back to your first book. Because if you kind of encourage, by which I mean force, team members to write this stuff down, the act of writing stuff down, I think, forces them to maybe think a bit harder, and then they might think a little bit harder about the trade-offs and the consequences to other team members. And perhaps they might feel a little bit more responsible and accountable for those decisions.

Eoin Woods: Yes, I think so. I mean there are two great ways of finding out if you understand something, aren't there? One is you try and write it down thoroughly. And secondly, you try and teach it to someone else. So yes, if teams have to record their design decisions and explain them to other people, I think you will definitely end up with better design decisions.

Simon Brown: I think I've gone through my questions.

Eoin Woods: Those were great questions.

Simon Brown: I tried, I hope there's nothing too controversial. Now you can obviously chop this lot of chatty bit if you want. Is there anything else you want to mention about the book?

A pragmatic book

Eoin Woods: I think about the new book I'd just say it very much tries to be a pragmatic book, and very much tries to be one that is...doesn't assume...

Simon Brown: So what are your goals with the new book Continuous Architecture in Practice, what are you hoping it achieves?

Eoin Woods: What we're really hoping to do is to do...serve two audiences. One is practicing architects who are really experienced, they know what they're doing, but they've possibly been working on one system or an existing set of systems for quite a while in a particular style. And they can see the world changing around them and they're starting to react to Agility, DevOps, microservices, cloud-based computing. They sort of understand it all in theory, but they've not yet made much of a step into that world. But we hope we're going to share our experience to show how actually all of their skills are still very relevant, it's more about how they apply them, how they work with people, and understanding some of the technical dynamics that have changed.

And then the other group we're hoping to serve is people who are...have come up natively in that world and they're at that sort of team leader, they're a technical designer, they're a subsystem lead, they're ready to take that step to become architects or chief engineers or lead engineers, whatever they're called in their organization. They're going to take accountability for architectural decisions. And they might be thinking, "There are parts of this I know really well. There's a scale I haven't dealt with. I'm not quite sure how to integrate my work outside my local team into the overall development organizations. And I've only worked with certain parts of this quality property mix, I've never had to think about this too deeply because more experienced people have generally guided me. What are the steps I need to take?"

I think the book tends to have both those audience. We really hope people are going to find it useful. It is based on experience and, of course, we've tried to base it on some really solid foundations, as well. But we think it reflects the way that the industry is headed, the reality of today, and also a lot of experience that we've found as to what works and doesn't work.

Simon Brown: Yes. Agreed. From my perspective, when I read the version that you sent me, it's got a really nice breadth of content, so it's very comprehensive in terms of, you know, what it covers from an architect's perspective. I completely agree. For people who are new to the role, it's a really nice, I'm going to say, tick list, but, you know, don't treat the book as a tick list. But it's a really nice list of topics that you should perhaps think about when you're going through and making those architectural decisions.

And the other thing I really like about it, as I said, is the focus on the trade-offs. So kind of explicitly telling people there is no single right answer, don't try and find one. But the other thing I really like about the book is there are so many references to other material. You could just literally give that one book to people and they could have a whole spider's web of other books and knowledge and websites that they can go and find information about. And from that perspective, I think it's super useful for people who are new to the architecture role.

I hope it does well.

Eoin Woods: That's great to hear, thank you.

Simon Brown: Definitely go buy it in the summer, would be my message to people watching this. It's a great book.

Eoin Woods: That's great, thanks.

Simon Brown: So I think we're done. Thank you very much.

Eoin Woods: Thank you, Simon Brown. That was really fun.

Simon Brown: Where can people find more information about you and the book?

Eoin Woods: You can find information about the book on and also .com, that's our website. More information about me, I have a website, too, Eoin And Pierre and Murat both have websites, too, which I linked off the book's website. So plenty of stuff to go and read.

Simon Brown: Right. Thanks very much.

Eoin Woods: Thank you.

Software Systems Architecture
What does "Viewpoints & Perspectives" refer to?
The context view
The minimum package of software architecture
(Cont.) The context view
UML in 2021
How to keep things synchronized?
Difference between evolutionary & continuous architecture
Why software architecture is more important than ever
Shifting architectural thinking & decisions left
A pragmatic book: "Continuous Architecture in Practice"