What to Consider for a Successful Software Architecture

Where should you start when setting the basis of your software architecture? What is the minimum required to package and how can viewpoints help? Simon Brown and Eoin Woods explore the right — and best — way to start that process, key things to consider, and what some useful resources are, including “Continuous Architecture in Practice” by Eoin Woods.

Intro

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.

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: 3 Practices for Effective DevOps Adoption • Eoin Woods • GOTO 2020

Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020

Software Architecture as Systems Dissolve • Eoin Woods • GOTO 2016