Is Software Architecture Still Important?

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.

Did you see the first episode: What to Consider for a Successful Software Architecture?

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 having...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 of...it 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 they...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 do...as 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 probably...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 continuousarchitecture.info and also .com, that's our website. More information about me, I have a website, too, Eoin Woodswoods.info. 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.

About the speakers

Eoin Woods is CTO at Endava, the European IT services company. He is an author, a conference speaker, and an active member of the London software engineering community. His main technical interests are software architecture, distributed systems, and computer security.

Simon Brown is an independent software development consultant specializing in software architecture; specifically technical leadership, communication, and lightweight, pragmatic approaches to software architecture. Simon is the author of "Software Architecture for Developers", a developer-friendly guide to software architecture, technical leadership, the balance with agility and communicating software architecture with sketches, diagrams, and models. He is also the creator of the C4 model and the founder of Structurizr, a collection of tooling to help teams visualise, document and explore their software architecture.

Recommended talks: Secure by Design – the Architect's Guide to Security Design Principles • Eoin Woods • GOTO 2016

Software Architecture vs. Code • Simon Brown • GOTO 2014

Modular Monoliths • Simon Brown • GOTO 2018