Patterned after this

One of the big objectives for us next year is to deliver architectural patterns, as public content, that outline all of the top applications of our platforms and products and how to design them as independent solutions or into core infrastructure or to be delivered as services. Of course this brings up the age old engineering requirements vs. use cases debate and the architects’ struggle to define a methodology for knowledge transfer that is universally acceptable.

I am still undecided on the approach from a documentation perspective, but one of the most interesting things that I have seen regarding this in a long time is a paper that was authored by Matt McKenzie and Duane Nickull. I noted that it is not version 1.0 yet so I hope I dont get in trouble linking to it, but the location of the document is http://www.nickull.net/work/MacKenzie-Nickull_ArchitecturalPatternsReferenceModel-v0.91.pdf

In this document, Nickull and MacKenzie propose a meta model that constrains instances of patterns in order to “provide a framework for the decision-maker to view the business from a different perspective from the engineer.”

Based on this, if we were to publish reference architectures that mapped to such a meta model then architects designing solutions that include our applications could have questions answered, RFP responses filled in, sub-patterns applied to their patterns, and business level descriptions of the solutions provided in context of their overall recommendations.

The interesting thing about this approach is that architecture could become both an instance and a reference, and both static and a living set of documents or patterns. The parent child relationships could scale up to the business case and down the OS-specific mappings for requirements.

For example, things like performance benchmarks could be easily inserted alongside physical deployment models, and directly correlated to geographic failover policies. The logistics for providing these services could then be referenced from external service providers.

This would change our thinking about accountability, responsibility and the delivery of thought leadership within the context of a properly managed discovery process. The creative input of the entire team would always remain in context. And most importantly, the tedious business of proposals could now contain an exciting level of detail that for the most part, would automatically be rendered at runtime. This render would be up to the minute collaboration and purely based on the quality of creative thought that was applied to the problem.

Of course like anything that is services oriented, this could be harder at first, but, IMHO, the payoff would be well worth it.