One of the many discussions we had on the training course in London recently was about the actual process of software architecture and design. There's a perception that software design is a complex process steeped in formality where you must produce a large number of diagrams drawn using a formal notation. We like to present a very straightforward and lightweight approach to software design but really the important part of the process is understanding what drives the architecture. It's about understanding the functional requirements, the non-functional requirements, the environmental constraints that are imposed upon you and the architectural principles that you want to adopt. Understanding these and how to work within them does more to contribute to successful software projects than using sophisticated modelling tools and formal methodologies. I'm not saying that you shouldn't use them, but you do need to understand the drivers so that you can make the right decisions and come up with the right design. And coming up with the right design is really what matters.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.