Books are not a substitute for personal experience, but neither is the world a boolean place. Ignoring the experiences of others is akin to re-inventing the wheel just so we can learn how to drive. Given how long it took to develop the wheel the first time, there’s probably more productive ways we could spend our time. The combination of good books and our own experiences can help us advance our skillset, understand common methods instead of having to reinvent them, and learn a common language and terminology that other will be able to understand.
Last week[-ish] I published a pair of books for software developers, this week is software architects, next week is next week.
Architecture
Starting to get interested in the tools necessary to build a framework that enables application design? Of building an application that comes together smoothly instead of coming apart at the seems? Or maybe just trying to bridge a communications gap?
Microsoft Application
Architecture Guide
Microsoft Application Architecture Guide
MS Patterns and Practices Team
This book may have been produced by a Microsoft group and tend to reference Microsoft technologies as practical examples, but I still think it is one of the best survey courses in application architecture I have read. The guide covers application architecture, what it is, terminology, when it is appropriate to use general patterns, and what it means to use them. While most of the information can be found in other books, this book brings it together into a central, organized structure. An added benefit, if you work with Microsoft technologies, is that it comes from the viewpoint of a group that is intimately aware of the tools and services Microsoft provides, giving us insight into the intended congruence of those tools and the architectural patterns.
Software Architecture
for Developers
Software Architecture for Developers
CodingTheArchitecture.com
Knowing the technical components we can use to build an application is only part of architecture. The collection of essays that form this book discuss pragmatic methods we can use to help define an architecture, methods to help us prevent over-architecture, topics on becoming an architect, and a lot of focus on how (and what) we communicate.
Focused on the architect, rather than the tools of the job, this series of essays helps us understand what it means to be an architect and how we can go about defining an architecture, and it does so in the pragmatic, rather than ivory tower, view.
Patterns of Enterprise
Application Architecture
Patterns of Enterprise Application Architecture
Martin Fowler
PEAA is part reference and part information on architecture; what it is, how to define it, and what purpose it serves. The first 1⁄3 of the book is an 8 chapter introduction that covers everything from what a pattern is to the type and groupings of patterns in the book, from the need for architecture to the purpose of layered design, and from the individual components to how to put them together. This book will not make you an instant expert, nor will you suddenly have the ability to elicit requirements and design a framework to meet them, what it will do is provide you with a broad base of understanding of common terminology and concepts that are commonly used in our field and pointers on when and how to use those concepts.
These aren’t the only books on software architecture, or even the only books that I have read, but I do think that these three form a good foundation for understanding the technical skills, communications, and purpose of architecture.
My roles have included accidental DBA, lone developer, systems architect, team lead, VP of Engineering, and general troublemaker. On the technical front I work in web development, distributed systems, test automation, and devop-sy areas like delivery pipelines and integration of all the auditable things.
