So here I am sitting in my office after a long weekend...and I mean LONG weekend.  I decided to head out with my brother-in-law (a Software Dev Engineer on the Outlook team) to a wedding in Utah.  And I thought a road trip would be fun.  27 hours of interstate driving and I think that my vertebrae have all fused together.  But I did learn quite a bit about Outlook architecture, so I guess it all evens out.  So instead of putting miles on (and buying gas for) my truck, I rented a car and drove that instead.  And it got me thinking just how habitual the act of driving really is to many of us.  Get behind the wheels of a car, adjust the mirrors, find your favorite golden oldies radio station and you're off. 

Then I got to thinking about the same habits in development.  It takes a "habitual" programmer or architect to remember to comment their code, document interfaces, etc.  But in the world of robust operations, service oriented architectures and management/monitoring this is critical.  That same habit of commenting code needs to carry forward to policy definition and interface documentation so that consumers of the service(s) can utilize them without that understanding that comes with tightly coupled systems.  Increasingly as larger scale service architectures are built in extended enterprises, the business owners need to be able to drill down at all levels of the architecture to understand operational constraints, costs and dependencies across the architecture.  And this can only be acheived if those services are documented using available metadata techniques in the development tools and standards.

In Financial Services, the big pushes for operational cost cutting (usually accompanied by some form of outsourcing) are crying for standards or standard patterns for service description, business process management and monitoring of those services and dependencies.  Microsoft's engagement with standards in the industry also is to help them adopt the base technology so that they can leverage this taxonomy infrastructure that allows these services to be described in a rich fashion. A developer, architect or business owner can then interrogate them or report on them for an accurate picture of their operations or even during design of an application to build the best fit architecture.  Even better would be for each application to have a standardized template for service description, interfaces, workflow and integration patterns.  This template would help speed enterprise integration since service abstraction and definition would be embedded and implementation complexity of the larger applications could be abstracted away using this template/toolkit approach during integration phases.

Now if I could only get my back to stop hurting...   :-)