Grady Booch on the Microsoft Application Architecture Guide 2.0

Grady Booch blogged about our patterns & practices Application Architecture Guide 2.0, which is our Microsoft playbook for the application platform.  It's a thoughtful post and he obviously took the time to figure out the structure of the guide.   The guide is probably particularly relevant for him since he's working on his Handbook of Software Architecture.

Booch on the Application Architecture Guide 2.0
Here's what Booch has to say:

"I find this work to be very interesting (and useful). Architecture is all about making significant design decisions, and this guide focuses on a number of such decision points, including caching, communication, concurrency and transactions, configuration management, coupling and cohesion, data access, exception management, layering, logging and instrumentation, state management, structure, validation, and workflow (collectively, Microsoft calls these "architectural frames"). Full of best practices and patterns, I particularly liked the enumeration of architectural styles the authors have collected: client-server, component-based, layered, message-bus, model-view-controller, n-tier, object-oriented, and service-oriented. Congruent with these styles is their concept of application archetypes, which include mobile, rich client, rich internet, services, and web. Combine the these styles and archetypes, and you have an interesting language for describing a large class of applications. While I don't necessarily agree that these styles and archetypes are orthogonal (nor are the lists complete) for the general domain of software architecture, for Microsoft's purposes, these styles offer an excellent operating model into which one can apply their patterns and practices."

For whatever reason, I can't figure out how to link to the individual post, so I'm linking to the page that includes Grady's post on the Microsoft Application Architecture Guide.

My Take
I agree with Grady that the list of application archetypes and arch styles is not complete (at least the versions that we've shared online).  We only shared a subset.  We do have some pretty rich Mind Maps that are more exhaustive, but they're somewhat unwieldy.  It's a trade-off.

We basically forked the app types.  The app types that we shared are optimized around technical types that customers quickly identify with.  We also have a set of business types, but the problem is these are more long-tail and there was less agreement on naming.  Worse, customers couldn't quickly identify with them.  There was a slight learning curve.  I think we can potentially tune them and share them downstream, more as a visual catalog.

On the arch styles, they're not necessarily orthogonal, but we found it helpful to first identify the overall app type (web, RIA, ... etc.) and then shape the app with the arch styles.  For precision, I think of the architecture styles as sets of principles that shape an important dimension of the application (such as deployment, structure, domain, communication ... etc.)  It's like a bunch of martial arts systems for different styles of fighting.  They have their pros and cons, but you can only evaluate them in context and measure effectiveness.

Key Take Aways
Here's my key take aways:

• Architecture Frames.   The arch frames are useful for cataloging the patterns and practices into actionable categories: caching, communication, concurrency ... etc.
• Architecture Styles.  The arch styles include client-server, component-based, layered, message-bus, model-view-controller, N-tier, object-oriented, and service-oriented.
• Application Archetypes.  The application archetypes are a language for describing classes of apps: mobile, rich client, RIA, services and Web.

Someday, I'd like to synch with Grady and show him all the stuff we haven't exposed at this time, including our technical capability maps, pattern capability maps, application patterns, quality attribute maps, ... etc.  While a lot of it is half-baked, we have some good foundations for elaboration.  Unfortunately, there's only so much we could share in a six month project where the dominant focus is writing a book.

Comments

• Anonymous
  January 08, 2009
  The comment has been removed

• Anonymous
  February 06, 2009
  The comment has been removed

• Anonymous
  February 10, 2009
  Why not to use the term software architecture instead of application architecture? I noted that when in the guide comes the definition of application architecture (page 8), authors use the term software architecture.

• Anonymous
  February 10, 2009
  The comment has been removed