Wednesday, November 28, 2007

Run Book Automation and SLAuto

I am attending the Gartner Data Center Conference at the MGM Grand convention center in Las Vegas this week. In between repeating the Active Power Management spiel over and over again to this mostly excellent technical audience, I was able to take some time to catch David William's rundown of the Run Book Automation market. RBA seems very related to Service Level Automation (SLAuto) in my book, so I wanted to see where the overlap really is and isn't.

David's presentation was excellent, in that it provided a concise overview of what RBA is and isn't--think process automation for IT operations processes--and where both vendors and IT organizations are in the definition, planning and implementation of RBA systems. Here are my notes from the session:
  • RBA=>Really just process automation for infrastructure and application management
  • RBA systems must be integrated into existing and new management infrastructures
  • Integration issues are more cultural than technical--IT organizations must be prepared to redefine operational boundaries to answer the question "Who owns what process?". (This will be a future blog topic, as it strikes me that this is exactly the issue that SLAuto implementers are struggling with.)
  • Early users were addressing Fault Correction/Issue Resolution/High Availability/DR type processes
  • Now RBA is predominantly adopted for Change and Configuration Management, with Fault Correction a somewhat distant second. The reason is its easier to actually see the effects of Change/Config Management process automation than Fault Correction automation, especially if there are still human steps in the FC processes.
  • BPM must be considered a very separate system from RBA. RBA is a very focused task set with different reporting and human interface requirements than BPM systems, which must be much more general and open to extension.
  • Good RBA systems should have process development and monitoring as separate user interfaces. Combining the two is not scalable.
  • Monitoring should provide not only current state, but also estimates for when a process will complete
  • IT organizations are overwhelmingly looking at their current IT infrastructure partners to provide this function, not start-ups
  • RBA implementation is not an emergency yet, as the tools need time to mature and IT organizations need time to handle the cultural "homework" required for a successful implementation
  • Of the audience members with voting machines, 39% had no plans to implement RBA, while 21% had plans for 2008. The others either already had some RBA or were between evaluation and implementation now.

If you are at the conference, stop by the Cassatt booth tonight or Thursday and introduce yourself. If not, I'll try to give an update on a couple of other sessions I attended in the next day or two.

1 comment:

Anonymous said...

Run Book Automation is the foundation one lays down for good network automation. Doing so ensures that your automated network can take care of itself and keeps you from having to employ a rather large IT staff and dedicate them solely to the network. RBA should be the first thing people implement.