Thanks to the people behind the SE News newsletter I came across the announcement of the book 97 Things Every Architect Should Know, to be published by O’Reilly early 2009. The site looks a bit sloppy, it’s a badly formatted Wiki, but if you take your time you can find little gems like the one below.
I’m not sure if this book is going to be more than a bundling of 97 ideas from random people, but the fact that the site will remain even after the book is out will give us a chance to decide.
Anyway - this one is fully in line with what I am teaching at the PDEng programme at the Stan Ackermans Institute in Eindhoven the coming 15 months. Just think about it… These three paragraphs capture a problem that approaches like those of the Agile movement are trying to address, but this is one of the briefest and to the point descriptions of the problem. It makes me wonder about the other 96 items selected for the book.
One of the most attractive temptations on a software development project is to consider it successful if it simply meets the written requirements on time and on budget. When the pressure is on and deadlines are approaching the requirements list makes for an appealing defense against the struggles of a project and its architecture. The problem with this outlook is that it does not take into account the premise of any software project: to make the lives of the users better.
Architects treating the identified requirements as the cumulative to-do list for a project are placing an implicit roadblock to discovering the real needs of the client. They run the risk of choosing an architectural approach that would seem foolish if the requirements were reasoned about to discover the deeper meanings within. By taking this viewpoint the architect places himself aligned with the words of the requirements while rejecting their intent. There is no driving need or desire to discover those intentions since expanding on the requirements means the project will have increased scope to deal with to be “successful”. Meanwhile the client is left with a project that risks being little better off then what they could verbally express.
Instead an architect should consider the current set of discovered requirements as a living list of open discussion points. The relationship between the architect and the client now becomes one of shared discovery instead of trying to see how many requirements can be checked off as complete. Each requirement forms an entry point into a conversation to a deeper understanding of the problem and the boundaries for the set of possible solutions to choose from. By taking the view that a requirement is simply accumulated current knowledge an architect is encouraged to approach each one as if the problem will change or at least might be better understood tomorrow. The architect is driven to produce software that is a joy to use and makes the user’s lives better.