Opalis adds the last cornerstone to the SC foundation: automation.
If you can see past its currently outdated and simplistic looks, you will discover that it has much potential once integrated with SC’s other products.
To briefly summarize how Opalis works (I will try to add more technical examples in later posts):
Opalis uses workflows to perform various tasks on its own. These workflows are created by the user using an easy to use designer, and defines which tasks have to be performed on which condition in a certain order. Workflows can be branched and coupled, making it a very flexible and consolidated way of managing process automation.
Imagine the following scenario’s:
A development server is needed to test some software, a request is logged into the ticketing system.
Usually, an IIT worker accepts the ticket, determines if the request should be carried out and then rolls out a virtual machine using a template, and finally performs some custom configuration. The IIT worker closes the ticket by notifying the developer that the VM is ready.
Many time is wasted at this point:
– If a dozen devleopers are requesting resources, it will take some time to provision all machines
– In the meanwhile, the IIT worker looses time over clicking on a template and select ‘Deploy’
What will happen when we put this procedure into Opalis?
– A request is logged
– Opalis picks up the ticket and determines that it’s a request for a new VM
– Optionally, approval can be asked to the IIT worker (who only needs to click ‘yes’ or ‘no’)
– Opalis will command SCVMM (of course!) to roll out a new VM, once this is done it will alter the network settings to accommodate the developer’s needs
– Opalis notifies the developer that his VM is ready and closes the ticket
Without Opalis, the IIT worker had to perform 4 actions (pay attention to the request, rollout the template, customize it and then notify the developer).
With Opalis he just has to press ‘yes’ or ‘no’.
Although it seems negligible, you have to see this on a bigger scale: if 30 of these request come in per day (let’s assume it is a really big company), you go from 120 (4 actions x 30 tickets) to 30. Add human error and delayed ticket acceptance to it and suddenly quite a lot of time is gained for both the developer and the IIT worker.
You all know it: Operations Manager reporting a full disk…
Usually full disks are fixed by some good old temporary file cleaning.
But, imagine this happening at night with a customer having a 24×7 support contract:
– Operations Manager rings the alarm bell on an ordinary C-drive who just had that one byte too much written to it
– The automated notification system calls the engineer on duty, who had just fallen asleep
– The engineer, both pissed and still half-asleep hears that ‘a disk is full’
– Either, the engineer just runs a temporary file cleaner (which usually fixes the problem) and misses some sleep, or ignores the error altogether (lazy engineer and angry customer afterwards)
Opalis can be hooked up to Operations Manager, and monitor the monitoring system (how ironic) for new alerts. The scenario can be played out as followed then:
– Opalis sees the error of the full disk
– it updates the alert to accepted (and grants the engineer his sleep)
– it runs a temporary file cleaner (built-in function!) on the affected machine
– Opalis rescans the disk size to determine if the problem is solved
– Yes? Then close the alert. No? Put the alert in a resolutionstate (eg ‘Opalis-Engineer Required’) which will be picked up by the notification system and passed on to the (unlucky) engineer
This will keep your engineers happy while still honoring the customer’s contract.
Again, see this on a larger scale: there are lot’s of common alerts which can be fixed easily, but still requires an engineer to perform a very simple procedure.
So what’s the ultimate benefit of this?
Instead of manually performing the same procedure over and over (wasting oh so precious time), enter one well-designed workflow into Opalis and never be bothered again unless it is really necessary. Effectively, Opalis could be used as a limited 1st-line support engineer, thus leaving more real (and mostly smarter) people to do the serious work.
One who might think that letting Opalis handle all those tasks is one hell of a scripting job, has yet to hear one of the best new innovations of the product: Integration with System Center.
Opalis uses Integration Packs (or IP’s) to add workflow objects, this ranges from Active Domain tasks to simple file operations. You can compare this to the management pack function of other SC products.
Now Microsoft has bought Opalis, every SC product except Essentials and Opalis itself will have its own IP, making the workflow design a simple drag and drop with some passing of parameters (using Opalis’ databus, which stores all produced variables of a workflow object).
There you have it: hassle-free process automation, which will save your business a lot of time and money in dealing with everyday tasks and allowing more focus on the core business of the company.
Opalis will get the new System Center IP’s Q4 this year and a fully Microsoftized edition of Opalis will be released in the beginning of the coming year. This one’s a keeper!