This post got attention on InfoQ.com in their Architecture community.
Here's the link: http://www.infoq.com/news/2008/03/architect-resources
Great post.

I think it's Simon that deserves most the credit for the SAD guidelines, not me! But I'll take it nonetheless :P

Thanks for the comment. Mid-march wasn't all that long ago but we're always working on new content and updating other pieces so if there's anything specific you think is missing from the guidelines or needs further detail then please let us know so we can get that into the next version.

This document is a masterpiece even though it is V0.1 I can't believe the clarity with which the requirements of what such a doc should cover are conveyed. I've been looking for something to convey to a team and we are not using any bloated methodologies at this time. I find that the trick is first to convey what is required and tools are just there to help, but the requirement of what goes into such a doc is not first understood then tools are a waste of time (i.e. garbage in, garbage out). I find that a lot of sites and companies punting methodologies leave this out and one simply gets lost/bogged down in a quagmire of technobabble that is meaningless. This document at least sets an expectation (or objectives) against which you can measure any document that is produced. In closing, do you have anything against someone like myself utilising sections of this almost verbatim? Once again thanks for a very imformative document!

Many thanks Simon!... Will do One more thing, do you have anything covering what a Functional Requirement type doc should convey?... Including installation and support documentation (for operational teams)

I think it makes sense to keep the non-functional view and justification separate.

In my mind, the non-functional view captures the non-functional requirements - it sets out what your architecture is trying to achieve. This is sometimes a document in its own right, sometimes owned by someone other than the architect. Nonetheless, the audience is often non-technical, being required to agree that your interpretation of the NRFs is correct and complete.

The justification of the NFRs is for traceability, to show that the proposed architecture is up to the job. Again, this could be separate, the results of prototyping or industry benchmarks.

For certain sets of requirements there's no doubt benefits to merging the two, perhaps where a simple "requirement/design decision" matrix will suffice.

Is it worth us adding something to the guidelines to capture this flexibility or even creating an "SAD-lite" version?

If you have identifiable NFRs then the justification section is more a foreign key relationship than a denormalised view ;)

As for their juxtaposition, I have wondered about that in the past. Sometimes it's easier to reference the design decisions after they've been presented, sometimes it's not... The SAD is often better as a hyper-linked tree of information than as a linear Word document in either case. The subtree of interest (and reading order) should be dependent on the viewer's need, not the author.

There are other similar synergies a lite version could appeal to: logical and interface views can often be superimposed, the design view might be driven by the functional view, the deployment view is often implicit in the infrastructure view. That said, most of this could simply be covered by the removal of a section from the existing SAD guidelines.

With you now... sorry, the suggestion was more that there were two templates, one for technical, tactical or derivative projects and another for slightly more green-field ones. Certainly not implying that you'd maintain two version of the SAD for a project (although you might want to offer several views onto a Wiki or similar).

Thanks for the heads-up ... I'm pretty amazed that somebody from Microsoft would do that in public! :-)