Why Orchestrator is incredible and I will probably never use it.

System Center Orchestrator is a wonderful product; A visual automation tool with arbitrary integration into dispirit systems that allows vendors to define high-level tasks that can be bound together into business specific automation packages that can react to changes in the environment. The use case for a global integration system is huge, and a well supported automation system has massive benefits to every organization. What’s not to love?

well, I have a few issues with Orch:

  1. The design of scorch run books, primarily the way data is imported and used, makes structured programming hard. If you are used to traditional programming logic, then the way that runbooks generate and use data seems backwards.
  2. Runbooks are a purely visual language. There is no concrete code behind the interface.  This is why you get example runbooks including images like this. It also means there is no reliable way to determine what a given runbook will do; you can’t “read the code”. an example: Using the image linked above, ask yourself what the conditions on the first link is, then ask yourself if you are thinking of the same link that I am.
  3. The scheduling system in orchestrator is unfriendly at best, and downright hostile in some cases. I know of at least two methods for scheduling runbooks outside of orchestrator, and I have a few coworkers who only use orchestrator for the Microsoft provided solution accelerators, because scheduling their own runbooks was more effort then it was worth. A Colleague of mine told me that he usually writes a scheduling loop inside the runbook, then just kicks off the runbook manually.

Now my primary area of responsibility is Service Manager, which adds a few more down sides.

  1. Orchestrator isn’t well supported for Service Manager, which is where it’s abilities would really shine. The integration pack for SM has design issues that make it hard to use. It could easily be improved, and I believe Microsoft is working on better integration packs.
  2. The runbook connector for service manager has some serious limitations. Performance is one limit; more then once I’ve seen it choke out the whole server when synchronizing. Admittedly this isn’t a Orchestrator issue, but it shoots the idea of putting runbooks into service requests right in the foot.
  3. We already have an easy method to schedule PowerShell scripts in service manager (via workflows), and good PowerShell support for lots of products (even competitors like Citrix & VMWare). Using SM’s workflow engine alone has a lower per-run cost.

you probably think I’m nitpicking, and you’re right; I am nitpicking. Apple’s dominance of late should have taught us that good design can sometimes overcome bad function, and that the reverse is equally true. I have the same problem with Metro the interface formerly known as Windows 8 Modern; it’s beautiful, elegant and a joy to look at, provided you don’t make me use it. (LCARS, anyone?)

It’s one of those genius ideas that has huge potential, provided you can overcome the minor problem of adjusting the universal constants so that it can work.

one last point: I am known for my ability to be confidently wrong. I had reservations about PowerShell in 2007. It was exclusive to exchange and there was no consistency between snap-ins. It (can I say “rapidly” for something that took close to 3 years?) found a use in other products and the module paradigm, along with other improvements in V2, cleaned up a lot of the consistency and implementation headaches. I hope Orchestrator can overcome it’s faults and be the great product it has the potential to be, but I suspect some of those nits are in pretty deep.