Cisco Cisco Process Orchestrator 3.0 User Guide

set current. For example, resource management can be more efficient when externalized. Moreover, a 
CMDB typically represents actual elements and not potential elements, and since orchestration is often 
responsible for provisioning, the orchestrator may have data prior to its life in the CMDB, which it might 
write to the CMDB as it is instantiated. Even if Process Orchestrator service models leverage data in 
CMDBs, performance is improved by keeping this data in Process Orchestrator target properties to 
optimize queries. Process Orchestrator allows a local representation of only those services that relate to 
what you want to automate, so that the implementation is right-sized and lighter than complete CMDBs. 
Updates are more real time and targeted to the need of automation. A conceptual alignment to ITIL and 
CMDB principles creates the flexibility to right size the implementation and unify with CMDBs when 
needed.

Also, ITIL prescribes key process records such as alerts, incidents, and change requests that drive the IT 
operations process. Process Orchestrator provides a native representation for these concepts. This allows 
content to be abstracted from how these concepts are provided in a company. For example, content that 
detects an IT incident does not have to encode the specific service desk used by a particular customer.

Content that enriches incidents with further diagnostic data can also do so independent of tool selection. 
Process Orchestrator alerts, incidents, and change request records allow reusable content independent of 
tool selection and company-specific ITIL extensions. A separate body of content can integrate 
orchestrator incidents with a specific service desk like BMC Remedy. Processes can trigger when 
incidents are created or changed in general automation and push those changes to Remedy. Updates 
within Remedy such as incident closure trigger synchronization processes which update the Process 
Orchestrator incident. Processes in general automation can then proceed from incident resolution. For 
example, the incident can be verified to prove that the problematic behavior no longer manifests. 
Moreover, ITIL prescribes that these records have a relationship to the element which failed so one 
knows what services may be impacted. Process Orchestrator incidents provide a link to:

The target defined by the target type for the service

A secondary configuration item field to link arbitrary external CMDB references when a CMDB is 
present

The following table summarizes how Service-Oriented Automation blends aspects of these industry 
standards as well as common best practices like object-oriented programming. Users who are familiar 
with one of these domains might find it easiest to map the concepts with which they are familiar to 
Service-Oriented Orchestration features. As you can see, the feature synthesizes similar concepts that 
have very disparate terms across the industry. Process Orchestrator attempts to provide the most intuitive 
terms within orchestration, and especially with prior Process Orchestrator users.