Home » Orchestrator » Orchestrator Scorecard

Contoso.se

Welcome to contoso.se! My name is Anders Bengtsson and this is my blog about Azure infrastructure and system management. I am a senior engineer in the FastTrack for Azure team, part of Azure Engineering, at Microsoft.  Contoso.se has two main purposes, first as a platform to share information with the community and the second as a notebook for myself.

Everything you read here is my own personal opinion and any code is provided "AS-IS" with no warranties.

Anders Bengtsson

MVP
MVP awarded 2007,2008,2009,2010

My Books
Service Manager Unleashed
Service Manager Unleashed
Orchestrator Unleashed
Orchestrator 2012 Unleashed
OMS
Inside the Microsoft Operations Management Suite

Orchestrator Scorecard

I in this blog post I would like to share an idea around measure how much time you are saving by using Orchestrator. Many organizations  spend weeks building cool runbooks, but are they really saving hours, or did the building phase took more hours then they will ever save? My idea is to build a report that show number of hours saved and compare it with number of hours building the runbook. To do a report on this we need some info about each runbook

  • How often is the runbook running?
  • How long would it take to do the same task manually?
  • How much would manually hours cost us?
  • How much did it cost to build the runbook?

There is another important aspect on this. Runbooks will always be executed the same way. When someone is doing a task manually there is always a risk that the do something wrong and we need to spend hours/day fixing that. That “risk” is difficult to estimate. If a solution includes multiple runbooks it could be difficult to estimate each runbook, then it might be configure hours on the “parent/root” runbook and not all the child/functions” runbooks.

All this info can be stored in the Service Manager database. I extended the runbook class with extra attributes.

  • Runbook owner: Engineer responsible for the runbook
  • Runbook Category: a category from a list item, a way to group runbooks
  • Manual hours: Number of hours it will take to perform the task manual
  • Manual cost: The cost per hour when performing the task manual
  • Build cost: The cost to build the runbook

20130303_Runbook_Extension

We can query the Orchestrator database to get runbook instance history, from the Microsoft.SystemCenter.Orchestrator.Runtime.RunbookInstances view. We can query the Service Manager database to can get runbook cost and hours, from the MTV_Microsoft$SystemCenter$Orchestrator$RunbookItem table. But out of the box Orchestrator only store 500 entries of log data, we should also try to keep the Orchestrator database small, so it is not a really good data source for this report. Instead I have created a new database where I write a daily summary for each runbook.

20130303_logdb

20130303_logdb02

 

I have a runbook that read from the Orchestrator database and writes to the Log database. This runbook gets all runbook objects from Service Manager that have a “Build Cost” specified. Then it query the Orchestrator database for success and failed jobs for previous day,  and writes that to the Log database. It also writes a summary of number of hours saved (SM Manual Hours x Number of success jobs) and total amount of money saved (SM Manual Hours x Number of success jobs x manual hours cost).

20130303_Runbook01

 

We can then use SQL Report Builder to build a report to show the data. In my example I have a table and a smiley face icon. The smiley face icon show if I have saved more money then spent on building runbooks. I can also drill down into each runbook category and see data about each runbook. The report includes two parameters, start and end date, to report time frame.

20130303_Report01

 

You can download my example files here, OrchestratorScoreCard. It includes the Service Manager extension, the runbook and the SQL report file. Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution, just a idea and an example. As always, thanks to Patrik for support and good discussions around System Center.


6 Comments

  1. Love the idea! Show upper management how much they’re saving by automating..
    Thanks!! Keep’em coming!!

  2. mmm actually the RDL has a formula to sum the devCost so the total cost of development is devCost*number of days (you can try to reproduce this, inserting 2 or more line for the same runbook)

    by the way this is a great idea! I’ve made some personalization and my CEO spends all his time to refresh the report 🙂

  3. Hi, thanks for reading my blog. That is correct, the devCost is constant so we don’t need to multiple with that. But I don’t think we do, I just store it at each runbook row to make it a bit easier in SQL Report Builder.

  4. Great job 🙂

    I did not understand why multiply the devCost value for the number of days you are searching for?

    the devCost is a constant or i’m wrong?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.