Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Configuration Automation functional architecture

Configuration Automation is the ability to automate infrastructure and application deployments and changes across physical, virtual, and cloud environments.

It requires:

  • Heterogeneous discovery
  • Fine-grained configuration information
  • Role-based access control
  • Virtual and physical infrastructures

BMC provides:

  • Fine-grained configuration items
  • Comprehensive configuration content
  • Platform-independent transparent packaging
  • One-to-many ad hoc changes

The key metrics for Configuration Automation are:

  • Percent increase in change success rate. This metric can be reported using the Dashboards Percentage of Changes Resolved Based on Service Target Pod and the Analytics Number of Successful Changes Report.
  • Percent decrease in incidents associated with change. This metric can be reported using the Dashboards Incidents and Problems Associated with Changes by Company Structure Pod and the Analytics Changes that Spawned Incidents Report.
  • Percent increase in the device to admin ratio. This metric can be reported using the Dashboards Service Automation Productivity Pod.
  • Percent decrease in change execution time. This metric can be reported using the Dashboards Change Lifecycle and Process Efficiency Pod.

This section describes the functional architecture that supports the following capabilities:




The capability to ascertain the existence of applications and infrastructure within an IT environment, along with configuration and dependency details, in near real time.

Policy-Based Operations

The capability to enforce business policies and change management.

Configuration Policy Management

The capability to enforce business-level policies on who and what can be changed within an IT environment.

Infrastructure Provisioning

The capability to establish heterogeneous virtual and physical resources within an IT environment using unified methodologies.

Software Distribution

The capability to reliably, efficiently, and securely disseminate and install software within an IT environment while enforcing business-level polices.

Patch Management

The capability to prioritize, analyze, and disseminate patches at a service level using unified methodologies within a heterogeneous IT environment

Service Provisioning and Repurposing

The capability to establish heterogeneous virtual and physical resources from the bare metal through software installation and configuration using VM Provisioning, Infrastructure Provisioning, and Policy-Based Operations.

VM Provisioning

The capability to automatically establish virtual resources and associate those resources with service-level policies.

Virtual Machine Lifecycle Management

The capability to provide self-service establishment and reclaiming of virtual and physical resources based on business-level policies.

Application Release Management

The capability to model, package, disseminate, install, and roll back applications are a service level within a heterogeneous IT environment while enforcing business-level polices.


The diagrams in this section depict the logical components of the system, the communications of the components to one another, and the products to which these logical components belong.

UML robustness diagrams describe the flow of information and components involved in a complex system. UML robustness diagrams are used throughout the functional architecture documentation to describe the various products and components necessary to implement specific capabilities within the BMC BladeLogic Automation Suite value paths.

Each capability is divided into Actors (a person), Boundaries (typically a graphical user interface or a console), Entities (a database, or other external user artifact in the system, such as a server), and Controls (usually a BMC product). Arrows between the various components indicate the flow of information between the components. The following symbols are used:



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

Use cases

Was this page helpful? Yes No Submitting... Thank you