Orchestrator Integration Packs

DIY or Ready Made Integration?

Many people have made large investments in both Microsoft System Center and other Datacenter Management Tools.  Historically integrating these multi-vendors product sets has been challenging and time consuming.  With System Center 2012 Orchestrator, Microsoft has laid the foundations for a much easier and speedier interaction between product suites.

The challenge with any integration and automation product is keeping the interfaces to vendor products current and when you have many different vendor management products to integrate this only becomes more complex.

System Center 2012 Orchestrator makes the job of integrating multi-vendor management products together much easier due to its published databus technology, standard activities and its suite of ready to use Integration Packs.  These ready to use Integrations are provided as part of the System Center distribution by Microsoft and by Third Parties as chargeable options.

In addition to these capabilities, in Orchestrator the User has the option to build their own Product Integration rather than use an existing Integration Pack.

One of the first questions I always get asked about Orchestrator is why should I buy an Integration Pack when I could build my own solution?
If you are advocating the implementation of Orchestrator you are going to be asked exactly the same question.

The simple answer is it is quicker and cheaper to buy an IP than try and build and then maintain you own DIY solution.

Now some people don't believe me when I say that, so let me give you information on what is required to build a DIY integration against what you get from a ready build Integration Pack and you can make up your own mind.

Do It Yourself Integration What’s Involved

You can build your own integration to a third party application in Orchestrator using the Orchestrator Integration Toolkit. Most applications allow integration via a Web Service API and within Orchestrator you can utilise the Standard Invoke Web Services Activity.

To create a DIY integration with a third party product you need to have completed the following tasks:

  • Understand in great detail the Published API so that you know which methods to use interact with the API and know how the results will be returned to you from the API.
  • Know if you need to generate a Web Service Security Key before you can interact with the Web Service API to insert or extract data.
  • Create a Pre-processing Runbook to generate the Security Key which has to be passed to the Insert Into or Extract From API Interaction Activity
  • Create a Post Processing Runbook to manipulate the output of the API extract call into a format which is easily useable within Orchestrator

 There are also other considerations;

  • The published APIs to many third party products are not straight forward to understand and take a large investment in time and effort to comprehend particularly when most are not well documented
  • The APIs often change between version releases of the product.  If this happens it is now your responsibility to insure that your solution will work with the latest version of the target product, so you have to undertake detailed testing to prove that the DIY solution will still work.
  • The many post processing steps required in a DIY solution take time to execute in Orchestrator and so often a DIY solution is slower to operate than a full Integration Pack solution.  With a large volume of interactions this soon adds up and comes apparent in end to end performance and operation
  • Support and maintenance of the DIY solution is the responsibility of the person who built the Runbooks and is therefore a large overhead and single point of failure in a DIY solution.

The Integration with a target system will be made up of an number of discrete interaction steps which ultimately form individual Activities in Orchestrator.

In a DIY solution it often takes 3+ days to create a single interaction you want to achieve with the target system.  This is fine, in principal, if you only want to do one or two simple interactions with the target system but if you are looking at say a Service Desk application as a target you won’t be looking at just one or two interactions, you will want many interactions; create incident, update incident, close incident, create change, update change, close change etc.

Before you know it you need 10 to 15 separate interactions and your project now becomes 30 to 50 days worth of effort and you haven't even started to build the automation Runbooks yet.

Ready Built Integration Packs

Ready built Integration Packs are fully engineered integrations to Vendor Management Tools.  They install straight into Orchestrator and give you instant interaction with the Vendor product.  Now you only need to concern yourself with designing the processes in Orchestrator and not with wondering how to interact with the Vendor product.

The use of an Integration Pack relieves you of all the complexity of API comprehension and support and allows you to concentrate on building the end to end automated process in your Runbooks rather than handling individual product interactions.

By using a ready built integration pack even the most complex end to end process can be automated in Orchestrator in 30 days.  So using an ready built IP you have built your automation solution before the guy doing the DIY solution has even got his System Interaction working.


Let me try and summarise this into the key constituent points.

With System Center 2012 Orchestrator Microsoft have significantly simplified the integration challenge involved in a heterogeneous datacenter but the individual Management Tool APIs are still as complex as ever.

Understanding those APIs and determining how to interact with the individual methods is hard work and very time consuming.  The coding and Runbooks required to actually achieve the integration are highly intricate and labour intensive.  Then having just completed your integration the vendor releases a new version of their product and you have to start the testing and checking all over again.

Many people who choose a Do It Yourself integration path significantly under estimate the effort that will be required to create and maintain their integration.  A functional Integration takes significant time to create and then needs resource to fix and test per Vendor Product release to keep in step with the API changes.

At this point it becomes impractical to use a DIY solution over purchasing a ready built Integration Pack as the amount of time required to build and maintain the DIY solution is far more than the cost of the Integration Pack.

I hope you find this information useful and it simplifies your discussions with management as you drive forward your Orchestrator implementation.