Fog Creek

Lightweight Software Architecture – Interview with Simon Brown

We’ve interviewed Simon Brown, a Software Architecture consultant. We discuss his lightweight approach to software architecture, expounded in his book ’Software Architecture for Developers’. We cover why software architects sometimes get a bad rep, the importance of software architecture in software projects, how even Agile teams can adopt his techniques and how much is ’just enough’ upfront design.

He writes about topics like this and there’s more resources on his website.

Content and Timings

  • Introduction (0:00)
  • About Simon (0:24)
  • A Bad Rep (1:45)
  • Importance of Software Architecture (2:38)
  • Agile Development and Software Architecture (3:29)
  • Just Enough Upfront Design (5:34)
  • Common Mistakes of New Software Architects (6:40)
  • Recommended Resources (7:20)



Today we have Simon Brown. Simon is a consultant specializing in software architecture based in Jersey and the Channel Islands. He speaks at conferences around the world and writes about software architecture, and is the author of Software Architecture for Developers. Simon thank you so much for joining us today, we really appreciate it. Why don’t you say a little bit about yourself?

About Simon

Thank you much for having me. As you said I’m an independent consultant and my background is actually working in finance so I spent about twelve years working London, mostly building software for the finance industry. And I moved back here to Jersey about 6 years ago, mostly because I have family and it’s a fantastic place to live.

The past couple of years I’ve been doing lots of jetting around the world and really teaching people about software architecture and how to adopt a modern, lightweight pragmatic approach to software architecture.

Well I wanted to touch base on the book, Software Architecture for Developers. What made you want to write the book?

I’ve written some Java books in the past, and I’ve gone through the developer to architect role myself. When I did that, I found it quite hard to understand what I should be doing as an architect. There’s lots and lots of books out there for developers, and ironically there’s lots of content and material for architect, but it’s a huge jump. You’ve got all the code stuff down here and all the really high-level enterprise architecture stuff.

When developers are trying to move into an architecture role, you get thrown into all this TOGAF and Zachman in the enterprise architecture world, so I wanted something to bridge that gap and basically make software architecture much more accessible to software developers. That’s it in a nutshell.

A Bad Rep

You mention in the book that some regard software architects as “box-drawing hand wavers”, why do you think software architecture has such a bad rep with some people?

If you look bad ten years, maybe further, we had a very prescriptive way of working in things like Waterfall where you’d hire an architect. So the architect would come in, do all the requirements gathering, put together the architecture, and then they would wield this big hefty set of documents down to the development team. Often those people never got involved with the coding, they never got feedback on their designs and that’s where a lot of the bad reputation has come from. So what I’m trying to do is take a much more hands on, pragmatic, lightweight approach, where architects are part of the team and architects are writing code as well. So we’re trying to move away from the very fluffy, conceptual, hand-waving style of architecture.

Importance of Software Architecture

You say that all software projects need software architecture, why do you think it’s so important?

It’s important because software architecture for me really solves two categories of problems. Category number one is really about building something that has a nice structure. If architecture is about structure, if you don’t think about structure, you basically don’t get structure. This is why we get lots of systems involved in that horrible big ball of mud we’ve all heard of, where everything is really interconnected and inter-tangled. So that’s one category of problems that we’re trying to solve there. And the other is really making architecture systems that work specifically from a non-functional perspective, so making sure that we factor in the important quality attributes. You know, performance if it’s important, scalability, security, and so on and so forth. And really if you look at architecture like that then software of all sizes needs structure and it needs to work. So that’s why architecture is pretty useful to all software projects.

Agile Development and Software Architecture

Software architecture and Agile are often seen as being mutually exclusive, but you think otherwise. How can the two better co-exist?

It comes back to these whole conflicts that we seem to have had in the past. Again, if you look back ten, twenty years, it’s very Waterfall, very prescriptive, process-driven, do lots of design up front. And then Agile came along, ten, twelve years ago, and it kind of reversed the trends. A lot of people’s interpretations of Agile equals “don’t do any up front design.” So we’ve got two extremes here, and there’s a sweet spot in the middle there. It’s about doing just enough up front design to satisfy the major questions.

But for those green start-ups, they barely have a functional spec around, how can they start to incorporate some of your thinking in to their working practices?

So this is that million dollar question, isn’t it? How do we do some thinking up front, but not get taken down this path of just doing it forever? It’s worth saying that a good architecture actually enables agility. If you’re building a lean start-up, and you want to pivot and change quickly, then you need to make sure that’s one of your quality attributes that you consider. Adaptability is a thing you need to bake in to your architecture.

In terms of how lean start-ups adopt lightweight architecture practices, for me it’s very simply about doing just enough up front design. I have a model I talk about in the book called the C4 Model. Basically it’s about going down to component design, nice high-level, chunky components, and then layering on risks and things like that.

You could argue that with a lean start-up you don’t have any requirements, and therefore, how can you possibly come up with a list of candidate components if you’ve got no requirements driving that process. In that case, I think you need to adopt principle-driven design. In other words, identify the list of principles that you and your team want to follow around layering strategies and technology choices, and all of those kind of things, and write them down, and then make sure that your architecture follows those principles.

Just Enough Upfront Design

You mentioned “just enough” up front design. How much is enough?

It’s about this much.

It’s one of those things, when you say it to some people they think it’s a complete breath of fresh air, and when you say it to a different set of people they think it’s a complete and utter cop out. For me, again, it’s in the middle. It’s not doing nothing and it’s not doing everything up front. So this begs the question – can you put some concrete advice about doing just nothing? And for me it’s very simple. It’s about doing enough in order to understand the structure of what you’re building, and also to be able to correct the vision that the rest of the team can understand to work from. That’s why, if you look at my book and all of my stuff online, you’ll see that a lot of the things I talk about relate to diagrams. I’m trying to bring back lightweight architecture diagrams as a way to make people think about structure, to a certain level of abstraction, and also use those diagrams to present and correct that shared vision. So that’s two-thirds of just enough.

The third process is risks. It’s about understanding, identifying and mitigating your highest priority risks. In other words, the things that are potentially going to cause your system, your project, to fail.

Common Mistakes of New Software Architects

What are some common mistakes you see those new to software architecture make?

It’s a really complex role and there aren’t many people out there teaching people how to do this role. Everything from people doing architecture and design on their own, and never asking for feedback. It’s people assuming that they must have all the answers, they are The Architect and they must know everything, which is impossible. It’s not collaborating enough. It’s not being clear with your communication. It’s not applying the right level of leadership. It’s not making sure that you’re policing your architecture principles, it’s all of that stuff.

Recommended Resources

Can you recommend some resources for developers, or those new to the role, who want to learn more about successful software architecture?

I’d recommend a couple of other books about architecture too. There’s a book by friends named Eoin Woods and Nick Rozanski and that’s called Software Systems Architecture. That takes you through lots of things including the more traditional view catalog. If you use Viewpoint Perspectives, so ways to think about and describe architecture.

There’s also a great book by another friend of mine, George Fairbanks. It’s called Just Enough Software Architecture. You can probably understand why I’m recommending that. And again, that’s a great book, George is a really super smart guy. Lots and lots of stuff in there about architecture. And again, he’s trying to bridge the ivory tower, very academic view of architecture with something a bit more grounded.

Thank you so much for joining us today.

No problem, you’re welcome. Thank you.