Interview de Simon Brown


by Romain, on April 13th 2013


We pleased to welcome Simon, author of the blog codingthearchitecture.com, who will give a talk and facilitate a workshop about software architecture, a mandatory skill for all teams. Interview !


MiXiT: Hi Simon, could talk a little bit about yourself?
Simon Brown: Like many people, I started my career as a software developer and gradually evolved into taking on the software architecture role on projects. I spent twelve years working for IT consulting companies in London and, although much of my work was focussed on the finance industry within the city, I’ve worked in a broad range of vertical industries. From a technology perspective most of these were Java projects; ranging from rich-desktop applications and websites through to distributed messaging and service-oriented architectures. Just over four years ago I moved back to Jersey in the Channel Islands. Jersey doesn't necessarily have a reputation for software development so it may seem an odd choice but I was born there and it's a fantastic place to live, especially if you have children. There is very little Java happening in Jersey, so I now have a few years of .NET experience under my belt.

Although I do still write code, much of my recent work has been helping software teams understand software architecture, technical leadership and the balance with agility. I'm writing a book called Software Architecture for Developers and I work with teams across Europe, teaching them about software architecture and how to adopt a "just enough" approach to up front design. In essence, this is about introducing technical leadership, which is often forgotten in the race for agility.

MiXiT: You have a blog, “coding the architecture”, why such a name?
Simon Brown: My view is that software architects should be hands-on, engaged with the team they are working with and ideally they should also write code. I struggled to find good resources about software architecture when I started to take on my first software architecture roles and, after gaining some experience in the discipline, I wanted to share it and help others. There is obviously a large quantity of information already out there, but I found it difficult to relate that information to what I was expected to do as a part of my day-to-day role.

Why the name? My view is that software architects should create the architecture and then have some involvement in coding the architecture too. :-)

MiXiT: What are the main evolutions you see about software architecture for the past years?
Simon Brown: I think it's safe to say that software architecture still doesn't have a universally good reputation, but teams (certainly the ones that I meet) are starting to get interested in software architecture again. The agile movement has drastically improved the way that we build software through an introduction of new techniques and an elimination of those that don't add any value. Agile projects still need technical leadership and they still need good architecture but, given the poor reputation of software architecture, many teams threw this out and are now struggling. The concept of a flat, self-organising team is great, but the majority of the teams that I've seen aren't ready to take this leap yet and still benefit from a single dedicated technical leader. In other words, they need a software architect, but not in the traditional "ivory tower" sense. The main evolution that I've seen is that teams are starting to find a pragmatic and lightweight way to approach the software architecture role. Digital Quadrant Magazine wrote a fantastic article called The return of the architect that summarises this and why it's important.

MiXiT: People are educated about programming language, algorithm, technologies … why is software architecture still such hard discipline?
Simon Brown: Software architecture is very easy to explain to people and it's not hard to learn about. In addition, many software developers are already doing parts of the role right now, despite not having "architect" on their business card. Much of the reluctance to learn about the discipline comes down to the poor reputation that software architecture has though, and also the way it's been presented in the past. Software architecture is also not shiny and cool ... and we only have a limited number of hours per day to learn new things. The role itself is hard to do well though, but then leadership roles are never "easy".

MiXiT: You have a talk and a workshop at MiXiT, what will people discover and experiment?
Simon Brown: Yes, that's right. My talk is an overview of software architecture and it's aimed at software developers. We'll look at what software architecture is, what the role entails and how it fits into our modern world of software development. This includes a discussion on agile approaches and what I consider to be the bare minimum set of software architecture practices that all teams should undertake. In the workshop, people will discover how to effectively and efficiently communicate the architecture of a software system. Visualising an architecture through diagrams is a skill that should be in every developer's toolbox because it's an excellent way for the team to communicate better, which means they can move faster. We'll also practice some pair architecting, which is another way to bring the software architecture discipline firmly back into the software development domain, which is ultimately where it belongs.