Bits to Bolts

I am giving a presentation at TechEd 2006 in Boston on something fairly obvious in our industry: the pain and suffering resulting from developed applications not being designed for operations.  The title of my presentation is Bits to Bolts: Bridging the Gap Between the Solutions and Infrastructure Architecture (yeah I know the title is a little gimmicky but after all, it is TechEd).

Lately, this topic is getting a lot of notice at Microsoft as e-mail threads abound.  After much sound and fury of the verbose commentators, the general consensus is that 'operations need to be involved from the beginning'.  Now there's an idea!  Would having a system engineer sit in scoping/analysis meetings, requirements gathering meetings, and software design discussions solve the problem?  What would need happen in the participation of these meetings that would make the difference?  While I do agree that Operations should have greater involvement throughout the lifecycle, that statement alone doesn't solve anything nor does it explain why countless attempts for operations to be involved from the beginning has resulted in less than operational systems.

Again, the primary theme of this blog is context.  There is a much larger context that needs to be considered in this critical problem that extends far beyond resolving to involve operations from the beginning.  I don't want to expound all of the planned discussion for the TechEd session here but like most problems in architecture (and IT in general), the solutions are typically non-technical.  An example is the recurring ideology surrounding an Enterprise Data Model.  Having a master data model for all data in the enterprise has been the fabled panacea of many ideologue architects and developers for as long as I can remember.  So why hasn't it happened?  Is creating a super, superset of enterprise data technically impossible?  I am not suggesting that it is technically easy but the technical difficulty pales in comparison to the non-technical, softer side of the problem.  So, in my opinion, is the issue between the Solution Delivery and Service Management sides of IT.  With that said, what needs to be addressed is the holy triumvirate of People, Process, and Tools (in that order of relevance) and that is what I plan on doing at TechEd and through a series of articles and whitepapers (if I could just get them finished).

If anyone is interested in talking more about this, or has thoughts on the matter - let me know!