For a few years every project I have started has, what some of my colleagues and I have termed, a Technical Architecture Specification. This document sits alongside the standard Requirements/Design Specification, and aims to describe the "how" of the system rather than the "what". It describes the "shape" of the system and is written with express reference to the design patterns used and as such requires a little bit of knowledge to make best use of it.
Unfortunately though, every Technical Architecture Specification I have ever written has been criticized. Not for its content I may add, but more for the very nature of the document itself. I've been faced with the same arguments time after time: where's the benefit in this document; will the customer understand it; why all these design patterns? So, of late I've started to have second thoughts as whether I should produce this document after all, it doesn't really cause me any problems if I don't write it, I know how the system should work!
Thank goodness then, I read this blog entry to help erase my doubts: (http://www.ddj.com/blog/architectblog/archives/2006/09/who_needs_a_sof.html)
 |
 |
