Software Architecture for Developers: Technical leadership by coding, coaching, collaboration, architecture sketching and just enough up front design (2014)
About the book
This book is a practical, pragmatic and lightweight guide to software architecture for developers. You’ll learn:
· The essence of software architecture.
· Why the software architecture role should include coding, coaching and collaboration.
· The things that you really need to think about before coding.
· How to visualise your software architecture using simple sketches.
· A lightweight approach to documenting your software.
· Why there is no conflict between agile and architecture.
· What “just enough” up front design means.
· How to identify risks with risk-storming.
This collection of essays knocks down traditional ivory towers, blurring the line between software development and software architecture in the process. It will teach you about software architecture, technical leadership and the balance with agility.
Why did I write the book?
Like many people, I started my career as a software developer, taking instruction from my seniors and working with teams to deliver software systems. Over time, I started designing smaller pieces of software systems and eventually evolved into a position where I was performing what I now consider to be the software architecture role.
I’ve worked for IT consulting organisations for the majority of my career, and this means that most of the projects that I’ve been involved with have resulted in software systems being built either for or with our customers. In order to scale an IT consulting organisation, you need more people and more teams. And to create more teams, you need more software architects. And this leads me to why I wrote this book:
1. Software architecture needs to be more accessible: Despite having some fantastic mentors, I didn’t find it easy to understand what was expected of me when I was moving into my first software architecture roles. Sure, there are lots of software architecture books out there, but they seem to be written from a different perspective. I found most of them very research oriented or academic in nature, yet I was a software developer looking for real-world advice. I wanted to write the type of book that I would have found useful at that stage in my career - a book about software architecture aimed at software developers.
2. All software projects need software architecture: I like agile approaches, I really do, but the lack of explicit regard for software architecture in many of the approaches doesn’t sit well with me. Agile approaches don’t say that you shouldn’t do any up front design, but they often don’t explicitly talk about it either. I’ve found that this causes people to jump to the wrong conclusion and I’ve seen the consequences that a lack of any up front thinking can have. I also fully appreciate that big design up front isn’t the answer either. I’ve always felt that there’s a happy medium to be found where some up front thinking is done, particularly when working with a team that has a mix of experiences and backgrounds. I favour a lightweight approach to software architecture that allows me to put some building blocks in place as early as possible, to stack the odds of success in my favour.
3. Lightweight software architecture practices: I’ve learnt and evolved a number of practices over the years, which I’ve always felt have helped me to perform the software architecture role. These relate to the software design process and identifying technical risks through to communicating and documenting software architecture. I’ve always assumed that these practices are just common sense, but I’ve discovered that this isn’t the case. I’ve taught these practices to thousands of people over the past few years and I’ve seen the difference they can make. A book helps me to spread these ideas further, with the hope that other people will find them useful too.
A new approach to software development?
This book isn’t about creating a new approach to software development, but it does seek to find a happy mid-point between the excessive up front thinking typical of traditional methods and the lack of any architecture thinking that often happens in software teams who are new to agile approaches. There is room for up front design and evolutionary architecture to coexist.
Five things every developer should know about software architecture
To give you a flavour of what this book is about, here are five things that every developer should know about software architecture.
1. Software architecture isn’t about big design up front
Software architecture has traditionally been associated with big design up front and waterfall-style projects, where a team would ensure that every last element of the software design was considered before any code was written. Software architecture is basically about the high-level structure of a software system and how you get to an understanding of it. This is about the significant decisions that influence the shape of a software system rather than understanding how long every column in the database should be.
2. Every software team needs to consider software architecture
Regardless of the size and complexity of the resulting product, every software team needs to consider software architecture. Why? Put simply, bad things tend to happen if they don’t! If software architecture is about structure and vision, not thinking about this tends to lead to poorly structured, internally inconsistent software systems that are hard to understand, hard to maintain and potentially don’t satisfy one or more of the important non-functional requirements such as performance, scalability or security. Explicitly thinking about software architecture provides you with a way to introduce technical leadership and stacks the odds of a successful delivery in your favour.
3. The software architecture role is about coding, coaching and collaboration
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.
4. You don’t need to use UML
Again, traditional views of software architecture often conjure up images of huge UML (Unified Modeling Language) models that attempt to capture every last drop of detail. While creating and communicating a common vision is important, you don’t need to use UML. In fact, you could argue that UML isn’t a great method for communicating software architecture anyway. If you keep a few simple guidelines in mind, lightweight “boxes and lines” style sketches are an effective way to communicate software architecture.
5. A good software architecture enables agility
There’s a common misconception that “architecture” and “agile” are competing forces, there being a conflict between them. This simply isn’t the case though. On the contrary, a good software architecture enables agility, helping you embrace and implement change. Good software architectures aren’t created by themselves though, and some conscious effort is needed.
Software architecture training
I provide one and two-day training courses that are practical and pragmatic guides to lightweight software architecture, covering the same content you’ll find in this book. You’ll learn:
· The essence of software architecture.
· Why the software architecture role should include coding, coaching and collaboration.
· The things that you really need to think about before coding.
· How to visualise your software architecture using simple sketches.
· A lightweight approach to documenting your software.
· Why there is no conflict between agile and architecture.
· What “just enough” up front design means.
· How to identify risks with risk-storming.
I’ll teach you about software architecture, technical leadership and the balance with agility. The video of my Software Architecture & the balance with agility talk from the Software Architect 2013 conference provides a good overview of what the course is all about. My courses and workshops have been run in more than twenty countries across Europe, the Middle East and the United States.
There are a number of course configurations and delivery options, which include private courses at your own offices. See http://www.codingthearchitecture.com/training/ or e-mail simon.brown@codingthearchitecture.com for further details.