Editors' Blog Almost 30 years ago when I first did my IT training, part of it was spent in ops, mounting tapes and trying to keep important systems operating efficiently.

At the same time, I met a programmer who took pleasure in "keeping the operators awake" by making them mount tapes pointlessly. Then I went into DBA, which (in those days) was a sort of "halfway house" between ops, development and good practice training.

Ever since then, I've been convinced that application design should include operational design. Any good application will be used for a lot longer than it took to develop, and throughout that time it will need performance tuning, recovery, upgrading, and so on – all of which represent special "user requirements".

So, I was interested to talk to David Aiken (http://blogs.msdn.com/daiken) (a Microsoft "developer and architect evangelist") recently, about design for operations (http://www.codeplex.com/dfo), which (it seems) will be a key feature of Microsoft's System Center Operations Manager 2007 (http://www.microsoft.com/systemcenter/opsmgr/default.mspx/) approach (there's an overview whitepaper here (http://download.microsoft.com/download/a/0/a/a0a7e90b-d20d-4052-8930-53edac404fe0/Whitepaper-System_Center_Operations_Manager_2007_Overview.pdf)).

Oh, and there's even a DfO show here (http://channel9.msdn.com/shows/The_DFO_Show), where Aiken "shows you how, once you have designed your health model, you can easily generate the implementation code using the new Visual Studio Management Model Designer (VSMMD)".

According to Aiken, developers and ISVs need to build manageability into their applications, but you can't just tell developers to make visible anything and everything you might need for management. Because they will – and thus overwhelm the operators with impenetrable and unusable detail.

"Ops people must be treated the same as end users," Aiken says - with requirements, a need for a pleasant user experience, and so on - and this changes the developer mindset. You need to consider operational "use cases" - what can go wrong, how will we fix it, what information will we need?

Aiken claims that Ops Manager 2007 provides all of the functionality needed to support this approach. Indeed, there's a wizard-driven Distributed Application Designer to help IT administrators quickly create "health models" and "management packs" for IT services, and the Management Pack Authoring Console for building management packs for custom applications and other technology components. And the Operations Manager 2007 Software Development Kit (SDK) provides programming interfaces so developers can automate operational management processes.

Nevertheless, it seems to me that support for how to go about this with "good practice" is (currently) fairly basic. However, as is not unusual in the Microsoft world, it's promised that the next release will be a lot better, with built-in management patterns and scenarios to build on; and the use of Microsoft's DSI (http://www.microsoft.com/business/dsi/default.mspx/) (Dynamic Systems Initiative) and model driven management to produce "living operational designs".

Well, vapourware is always perfect and we'll have to see what is actually released, but if Aiken is typical of the people working on this in Microsoft, it certainly has the expertise and vision needed to do a good job of it.

In the meantime, I took away three main points from our discussion:

1. Treat ops staff as first-class users of your systems, with requirements, use cases, etc. Applications spend longer in operational use than they do in development – and cost far more to operate than to develop. So, if they are hard to configure/reconfigure, tune and troubleshoot, this is expensive – and will be career-limiting for their developers.
2. Exploit the power of Ops Manager 2007 to abstract away from the raw instrumentation data – to add meaning to impenetrable error messages. Obviously, we should design the application for manageability in the first place – but if we haven't, we have a second chance to add operational guidance in Ops Manager – without rewriting or breaking any code.
3. Consider the "operational experience" – if it is poor, operators/administrators will make mistakes. There is a choice between a GUI and a commandline approach – each might be appropriate in different circumstances. And, with Microsoft Management Console on top of Windows PowerShell (Aiken's key enthusiasm), you can have both.

OK, so these are couched in terms of the Microsoft management environment, but I think they have a general applicability. There are proven operational management environments – on mainframes, for example - that have been around for a lot longer and (with the possible exception of the GUI) have all the tools you'll need to help you "design for operations" already. It's good that the Microsoft management environment appears to be joining them. ®

Related stories

CruiseControl builds for the Enterprise (20 June 2007)
http://www.theregister.co.uk/2007/06/20/new_version_cruisecontrol/
Of HP's Virtual Connect (13 April 2007)
http://www.channelregister.co.uk/2007/04/13/hp_virtual_connect/
Microsoft and EMC go both ways with new tool (28 March 2007)
http://www.theregister.co.uk/2007/03/28/emc_microsoft_network_management_partners/
Scaling the heights of Microsoft Management (4 October 2005)
http://www.theregister.co.uk/2005/10/04/best_of-microsoft_management-summit-2005/
MOM grows up as DSI takes off (1 December 2004)
http://www.theregister.co.uk/2004/12/01/mom_dsi_microsoft/