I'm an independent software development consultant specialising in software architecture; specifically technical leadership, communication and lightweight, pragmatic approaches to software architecture. I'm the author of two books about software architecture; Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility) and The Art of Visualising Software Architecture (a guide to communicating software architecture with sketches, diagrams and models). I'm also the creator of the C4 software architecture model and I built Structurizr, which is a web-based tool to create software architecture diagrams based upon the C4 model.
I regularly speak at software development conferences, meetups and organisations around the world; delivering keynotes, presentations and workshops about software architecture. In 2013, I won the IEEE Software sponsored SATURN 2013 "Architecture in Practice" Presentation Award for my presentation about the conflict between agile and architecture. I've spoken at events and/or have clients in the following countries.
Australia Belgium China Czech Republic Denmark Finland France
Germany Guernsey Hong Kong Hungary Iceland Ireland Italy
Jersey Latvia Lithuania The Netherlands New Zealand Norway Poland
Portugal Romania Spain Sweden Switzerland Ukraine United Arab Emirates
United Kingdom United States
I believe that a lightweight approach to software architecture is pivotal to successfully delivering software, and that it can complement agile approaches rather than compete against them. After all, a good architecture enables agility and this doesn't happen by magic.
In a nutshell, my lightweight approach to software architecture includes doing "just enough" up front design to understand the significant structural elements of the software, some lightweight sketches to communicate that vision to the team and ensuring that the highest priority risks are identified and mitigated. I use a technique that I call "risk-storming" as a visual and collaborative way to identify those risks. The code doesn't tell the whole story, so I deliver a lightweight software guidebook as supplementary documentation.
The image that many people have of software architects is of traditional "ivory tower" software architects dictating instructions to an unsuspecting development team. It doesn't need to be like this though, with modern software architects preferring an approach that favours coding, coaching and collaborative design. The software architecture role doesn't necessarily need to be undertaken by a single person plus coding is a great way to understand whether the resulting architecture is actually going to work.
Simple sketches for diagramming your software architecture summarises my "C4 model" for describing, visualising and communicating software architecture. It's a simple hierarchical way to think about the static structures of a software system in terms of containers, components and classes.
A software system is made up of one or more containers (web applications, mobile apps, standalone applications, databases, file systems, etc), each of which contains one or more components, which in turn are implemented by one or more classes.
Visualising this hierarchy is then done by creating a collection of system context, container, component and (optionally) class diagrams. For me, a common set of abstractions is more important than a common notation, so I don't use UML for most of this. Maps are a great example of this principle in action. They all tend to show roads, rivers, lakes, forests, towns, churches, etc but they often use different notation in terms of colour-coding, line styles, iconography, etc. The key to understanding them is exactly that, a key/legend tucked away in a corner somewhere. We can do the same with our software architecture diagrams or use a notation that is much more self-describing.
I regularly deliver sessions about software architecture at conferences, user groups and organisations around the world; including opening keynotes, closing keynotes, conference talks, panel sessions and workshops. In 2013, I won the IEEE Software sponsored SATURN 2013 "Architecture in Practice" Presentation Award for my talk about the conflict between agile and architecture. Here is my public speaking schedule for 2016.
All of the slides from past talks are available to view online/download. Here are the slides from some of my recent talks and workshops.
I've been interviewed for magazines, books and podcasts a number of times too, including:
I regularly run training courses, including a 1-day "The Art of Visualising Software Architecture" workshop and a 2-day "Software Architecture for Developers" course. Most courses are private, on-site courses for organisations around the world, but there are usually a small number of public courses each year. Read more...
Both my Software Architecture for Developers and The Art of Visualising Software Architecture e-books are available to buy from Leanpub. A Chinese translation of "Software Architecture for Developers" is also available, and more translations are in progress.
I regularly blog about software architecture on Coding the Architecture, which is a website that I created back in January 2006 to provide a resource for aspiring and new software architects, particularly those who favour an approach that is a little more "hands-on" than your traditional "ivory-tower architect".
Some of my popular blog posts have been translated.
Software architecture diagrams are a great way to explain and document how a software system works. Static diagrams, whether drawn on a whiteboard or with a general purpose diagramming tool such as Microsoft Visio, tend to get out of date quickly and often don't reflect the structure of the code. On the other hand, automatically generated diagrams, such as UML class diagrams created by reverse-engineering the code, typically show far too much detail, limiting their usefulness.
Have you abandoned UML and switched back to "boxes and lines"?
Do your software architecture diagrams look like this?
Do your diagrams get out of date quickly?
Do you feel overwhelmed by automatically generated diagrams?
Structurizr provides a way to create software architecture models using code. There are client libraries available for Java and .NET, which allow you to extract information from your code using static analysis and reflection. The resulting diagrams can be visualised and shared via the web. Here is an embedded software architecture diagram powered by Structurizr and the code that created this diagram can be found on GitHub.
The first ~15 years of my career were spent working for consulting companies (primarily in London) and, although I predominantly built software for our customers, I have also performed a number of consulting roles. These included software architecture reviews, software archaeology, architecture strategy work, technical due diligence, process engineering, being a trusted advisor, developer mentoring and coaching, rescuing failing software projects, performance testing, creating technical career frameworks and training plans, etc.