Policy-Based Operations use cases

The goals of the Policy-Based Operations use cases are:

• Process and configuration control
• Closed-loop configuration and change management
  • Operator initiated change
  • Remedy initiated change
• Policy inheritance

Operator Initiated Change

The Operator Initiated Change use case shows how BMC BladeLogic Server Automation (BBSA) or BMC BladeLogic Network Automation (BBNA) can be integrated with BMC Remedy Change Management so that automation jobs are approved and documented in BMC Remedy Change Management.

This use case has the following steps:

1. A BMC BladeLogic Server Automation operator schedules a job to be executed. Depending on how the system is configured, the operator might specify whether the job requires Change Advisory Board (CAB) approval or the operator might not have any other option than to gain approval.
2. BMC BladeLogic Server Automation suspends execution of the job and invokes a Continuous Compliance BMC Atrium Orchestrator workflow.
3. BMC Atrium Orchestrator creates a new change request using a predefined template. Depending on the type of change and the template, the change might be preapproved, or it might require manual approval.
4. After the change is approved, BMC Atrium Orchestrator invokes BMC BladeLogic Server Automation, allowing the job to continue.
5. If the BMC BladeLogic Server Automation job is a provisioning batch job, an NGP monitor can be deployed to the newly provisioned machine. If the job is a deploy batch job (such as for an application), an NSH script job can be used to register the appropriate monitors with the NGP server. (Note that batch jobs might contain both provisioning and deploy jobs, so both activities might be accomplished in the context of a single change).
6. Two methods can be used for updating the CMDB:
   • For customers without BMC Atrium Discovery (ADDM), the BMC BladeLogic Server Automation integration with BMC Atrium CMDB is used to provide periodic batch updates.
   • For near-real-time updates to the CMDB, customers with BMC Atrium Discovery can extend the out-of-the-box BMC Atrium Orchestrator workflow to drive targeted discovery and CMDB updates on a per-change basis.

An analogous use case is also valid for BMC BladeLogic Network Automation, except that BMC BladeLogic Network Automation cannot update the CMDB by itself, and it does not interoperate with NGP. Although BMC Atrium Discovery does not currently add network device information to the CMDB, the upcoming BMC Atrium Discovery 8.2 release will.

Remedy Initiated Change for BMC BladeLogic Network Automation

The Remedy Initiated Change use case is similar to the Operator Initiated Change use case, but it starts with a Change Request being created in ITSM Change Management.

This use case has the following steps:

1. Using the BMC Remedy Change Management user interface, a user creates a new change request. The change request is approved.
2. BMC Remedy Change Management initiates a BMC Atrium Orchestrator workflow.
3. The BMC Atrium Orchestrator workflow calls BMC BladeLogic Network Automation (BBNA) to create a request that will appear on the BMC BladeLogic Network Automation console.
4. A BMC BladeLogic Network Automation operator sees the request and creates a job to implement the change. Job data is populated from the change request.
5. The job is approved. BMC BladeLogic Network Automation updates BMC Atrium Orchestrator, which in turn updates the change request to indicate progress.
6. BMC BladeLogic Network Automation executes the job on the network devices.
7. After the job is complete, BMC BladeLogic Network Automation notifies BMC Atrium Orchestrator, which in turn updates the change request with the job status.

BMC Atrium Orchestrator can also optionally invoke a targeted scan in BMC Atrium Discovery (ADDM), for near-real-time updates to the CMDB. This feature will be available in the BMC Atrium Discovery 8.2 release.

Through the Operator Initiated Change or Remedy Initiated Change use case, the goals of Policy-Based Operations are achieved by enforcing all change through workflows created to enforce specific-business policies. These policies are defined centrally, allowing the business to change its policies and have those policies inherited by all policy-based operations. Throughout this section you will see the injection of the Operator Initiated Change use case to allow this enforcement to take place.