Change Lifecycle Automation use case

Each use case has a UML robustness diagram associated with it. A robustness diagram depicts the core components of a system and how the components communicate or collaborate with one another to satisfy a use case. Arrows between the components indicate the flow of information between the components.

The following symbols are used:

Symbol	Meaning
	Actor — User role that interacts with a component in the system
	Boundary — Component that represents an interface with which Actors interact
	Entity — Domain objects within the system that typically present a persisted state of that object
	Control — Components that connect Boundary and Entity components and implement some logic to manage the interaction between them

The goal of the Change Lifecycle Automation use case is to illustrate how change requests are initiated and managed through fulfillment.

This use case has the following steps:

To provision a new change request, a user uses BMC Service Request Management. For purposes of this use case, BMC Service Request Management comprises seven key components — Service Request Portal, Service Fulfillment Engine, Service Catalog, BMC Change Management, Task Management System, BMC Asset Management, and BMC Atrium CMDB. A user, using the Request Entry console, selects a service offering that represents the provisioning of a virtual system and associated software. Depending on how the service request has been configured, the user might be asked a series of questions regarding such things as server capacity or software to be deployed.
When the user submits the request, it is passed to the Service Fulfillment Engine.
The Service Fulfillment Engine invokes BMC Change Management, passing all required information. A change request is created with data values transferred from the service request through the Service Fulfillment Engine.
Alternatively, IT Support users can create change requests directly through the Change Management Console or through the Incident and Problem Management functions of BMC Service Desk.
Change approvals are processed within the BMC Change Management process workflows. Changes might be preapproved or might require approval.
Within BMC Change Management, the change request acts as the parent object to change tasks that are created through the foundational Task Management System. When the change request is approved, tasks are activated.
Tasks are processed in a serial, parallel, or successor-predecessor relationships. Tasks can be integrated to external systems via the CAI Integration Subsystem. For example, mechanisms as basic as scripts or as robust as BMC Atrium Orchestrator can be leveraged to integrate individual tasks with external fulfillment systems such as BMC BladeLogic.
Tasks can include activities to update the CMDB or Asset attributes through BMC Asset Management or through the Asset Inventory component of BMC Change Management when BMC Asset Management is not present.
When all tasks are completed, the parent change request is completed.

Change Lifecycle Automation use case

Comments