System 7 ties in Opsware’s two most recent acquisitions: iConclude, which is the process automation piece, and Creekpath, which handles storage automation. On the process end, instead of having to switch to a separate system to view and configure IT automation workflows, they appear directly within Opsware’s core server, network, and storage automation pieces.
That enables a couple key capabilities: consolidated and more granular compliance reporting and application-specific views on how the various pieces of IT infrastructure (from physical and virtual servers, storage, and network devices) are provisioned and configured to supported individual applications. Put together, it enables Opsware to deliver a consolidated dashboard that is updated in real-time to reflect changes in provisioning and configurations for specific applications that could impact compliance.
And, as part of the bundle, Opsware is expanding the range of ITIL process workflow templates that are supported through its process automation piece. It has added roughly 1000 pre-built generic workflow templates.
The new release also includes a new customization capability called Opsware Platform Extension (OPE). In effect, Opsware is publishing APIs to its data models so you can develop custom IT automation applications that may includes analytics, and it provides a run time so you can run it within the Opsware environment.
These are among the highlights of the enhancements for System 7, which is being announced as the company is midway through the process of being acquired by HP.
The stage was set for the announcement by last’s month pre-announcement that Policy Automation, which was the acquired iConclude piece, would be fully integrated to the core product set. Until now, you could define policy in a separate module, and then apply it in Server Automation, which was Opsware’s original product. Now policy automation is incorporated inside each of Opsware’s server, network, and storage products.
For instance, when a Service Desk application generates a trouble ticket, the workflow for responding to the trouble ticket could be configured a template with ITIL terminology and sample workflows. The workflow would include approval steps that appear within the server, network, or storage automation screens. And, depending on the policy for handling a particular configuration change, the resulting action could be implemented automatically or through human intervention. As the policy workflow is executed, decisions made, the results are then fed back to the respective Opsware automation modules.
And with compliance, integration of the server, network,, and storage pieces is critical to establishing an audit trial as to whether policies are consistently followed. For instance, it’s one thing to validate server configurations, especially when communicating to networked storage devices. With System 7, you can reconcile assumptions, such as that servers connect with full duplex to network devices and that there are multiple paths to storage, actually match with the settings in respective network and storage devices.
Our View
Opsware is addressing critiques that while its individual offerings (primarily the server automation piece that was its original product) picked up where traditional systems management frameworks left off, its products have been poorly integrated.
Paradoxically, the integration of its products not only multiplies the list of possibilities as to what an integrated IT infrastructure change management suite can deliver, bit it also reveals more clearly the gaps. For instance, as you can now piece together an individual application’s consumption of server, network, and storage together, wouldn’t it make sense to get the full picture with input on expected application service levels?
You can’t fault Opsware for the omissions as it obviously couldn’t boil the ocean at once. But what seems obvious in retrospect is that the company was probably engineering its product roadmap around the assumption that it would eventually be acquired.
One of those gaps was around CMDB (configuration management database), which is stipulated by ITIL as the system of record for how IT infrastructure is configured. So you’d think that a vendor whose product tracks system configurations would obviously have its own CMDB. Opsware essentially said, why reinvent the wheel, our customers use other product to manage the actual operation of their IT infrastructures, so may as well not complicate matters with yet another CMDB. Once the acquisition with HP is closed, that obviously takes care of that question.
And it also provides hints as to what might eventually come next: there’s obvious synergy with the Business Availability Center, which came largely from Mercury. That’s where you correlate service levels, with operations, and with the Opsware offerings, configurations of all the pieces in the data center or out there in the cloud.
But all that is at least a year down the road, as the acquisition must close first.
