Work Journal for March 25th, 2014

 

The real problem with module 2 seems to be that it isn't founded on an actual business goal. "Including user interaction" isn't really a business goal at all. It's a requirement that product features can help fulfill. It's close to a business goal, but it isn't one itself. 

A business goal would be more along the lines of "improve customer satisfaction", or "reduce user requests to IT". Orchestrator can allow users to request certain operations be performed. It can also provide greater exposure to end users about the status of processes. I find it difficult to make that argument. Exposing workflows to end users in this way is something I can't imagine being done often.

What I assume would happen instead is that developers would tie orchestrator into an ticketing system and set it to respond to requests. In that way, instead of users invoking the workflow directly, they are given the JobID and are provided greater visibility into the process. 

Even so, I still find that difficult to see. You wouldn't want to give this product to someone outside of the support or integration team. It's simply too detailed. I know I wouldn't want to get a non-technical end user within 10 meters of the user control panel. It simply provides too much noise, too much exposure. 

So what would it be used for?

First tier support personnel are who come to mind. They accept requests from end users via the phone or ticketing system. Then, they can use these workflows to restart servers, provision software, or check status. To be honest, there's not that many instances where this feature would be used. Most of the time, I imagine orchestrator is purchased in order to replace scripts and purely human-driven processes. It's automation glue. That's why first tier support personnel seems like a perfect fit if I need to talk about user-driven processes at all. 

Huh. "Automate user-initiated processes". That's a business, or at least an IT goal. 

It also suggests a nice narrative. Adding first-tier support staff can be a challenge. Either you need to reduce what they can do before transferring a request to second tier staff, or provide extensive training. With a constantly changing IT environment, rolling out new features can be slowed by the time necessary to train new staff. Orchestrator can make that easier by granting access to the user control panel. Each group of support staff can be granted access to a limited set of workflows they may invoke on-demand. If changes are made to the environment, the workflow may change without affecting support procedures. New workflows may also be added when necessary, simplifying the creation of new support procedures through automation.

Damn. That's good. I can see both the plausibility and the value.