Lean Architecture

When I was a new programmer, the career path that appealed to me was to be an software architect. The architect was the person who had the vision of how the system worked, and the work of the architect (if done correctly) set the stage for all good things in a project, coordinating the development, requirements, and anything else  that you need to build a system. One thing that troubled me was that many architects I knew didn't code, considering the coding a distraction. Having worked on a project or two early in my career with a non-coding architect who was reluctant to spend time helping the team address how difficult his vision was to execute given the languages and frameworks we were implementing with, I thought that something was amiss with the idea of a non-coding architect.

One of the off-shoots of specification heavy projects (no doubt staffed by many analysts and non-coding architects) was the agile software development movement, which has as one of it's principles minimizing Big-Up-Front- Design. In some cases people took that (incorrectly) as meaning to always let the architecture evolve organically.

As I had hoped when I received my review copy,  Jim Coplien's recent book Lean Architecture: for Agile Software Development explains how agile principles and architecture are complimentary, and how, with everyone working collaboratively, a good, lightweight architectural framework can help enable agility, rather than being a barrier to it.  With his usual iconoclastic style, Coplien dispels the myth that agile doesn't need architecture.



As a C++ programmer in the early 90's Coplien's  Advanced C++ Programming Styles and Idiomswas a source of interview material when looking for programmers. It's a good bet that this book may fill the same role for those looking to see if candidates for architect roles understand what it means to be an architect in a Lean or Agile Organization. This book dispels the myth that Agile and Architecture don't go together and explains the balance between Agile architecture and too much Big Up Front Design.

This book emphasizes the importance of frequent collaboration between stakeholders in defining a good architecture and helps you to understand the importance of architecture to the success of agile projects. With code examples throughout,  this book demonstrates that architecture and coding must go together.  After describing some general principles of how architecture can add value to an agile project, the authors explain the Data Context, Interaction (DCI) architecture, which provides an framework for building lean architectures.  My one complaint is that the transition between the general discussions of lean architecture and the focused discussion of DCI was a bit abrupt. This could almost have been two books: one on lean architecture principles and a second (short) book demonstrating how DCI is an useful framework to apply the principles from book one. But this was a minor distraction from an enjoyable and informative read.

Rich with citations and historical context, this book will be useful for anyone who is struggling with how to build systems that need to support complicated user interactions.