BMC gets even more service oriented

Which is nice

arrow pointing up

Fred Johannessen, VP and program executive of capacity management and provisioning at BMC Software, describes SORM (Service Oriented Resource Management) as the “third leg on our BSM (Business Service Management) stool”.

He claims that BMC has strong Process Management capabilities with its Configuration Management Database-enabled identity and change management tools; strong Service Impact Management to relate business services to its Patrol infrastructure monitoring and management tools; and then, “we can manage the service,” he says, “we can tell you what is causing a problem, and now, with SORM actually solve the problem before it impacts the service”.

Well, that is good, although SORM seems to be mostly a repackaging of what BMC already has. We appear to be looking at, initially, “just in time” (JIT) provisioning of additional, virtualised, resources (real-time capacity management) if monitors detect emerging issues – exploiting the reasonable assumption these days that you're over-provisioned by about 85 per cent for much of the time, if only you can find this spare capacity and share it effectively.

BMC has tools to help you discover and manage your resources; SORM adds the capability of allocating them to business services (“provisioning”) in near real time. Its tools are policy-based and virtualise the underlying hardware infrastructure.

This is almost essential for effective BSM, as modern IT infrastructures are complex and constantly changing. Policy-based systems are more manageable because policies often needn't change when hardware does.

The BMC approach to SORM includes:

However, we think Managed Objects actually formulated the BSM concept SORM suports (that is, the idea of managing operational IT systems in the context of the business services being delivered, not the hardware or software packages that aren't of real interest to the business) in the first place. So we talked to Dr Jim White, Business Technologist at Managed Objects, about his views on SORM.

He claims to identify a key differentiator between Managed Objects' approach and that of BMC (beyond the fact that BMC has an excellent HelpDesk and Managed Objects doesn't see that as being within its scope).

BMC primarily relies on agents for infrastructure discovery – agents can be very intelligent and discover detailed in-depth information about your inventory, but they must be loaded (so they'll miss technology you've overlooked, and there's a deployment overhead) and are potentially invasive (performance impacting), although these issues can be mitigated in a well-designed system.

Managed Objects, however, takes a lightweight, agent-less approach, so its discovery is usually both shallower and wider – and deployment costs are lower. Both approaches can work well if well implemented, and White notes that, in fact, a hybrid approach is emerging – in which agents are installed on your key business critical systems and agent-less technologies used on the rest.

Nowadays, BMC is as much an evangelist for BSM as Managed Objects, and who was first doesn't matter much. What does matter is the completeness of the service management vision and that it is based on independent standards (in this context, ITIL is important) and that it is built on a strong technical foundation (in the present case, this means that a “Configuration Management Database, CMDB, should be available).

An effective CMDB is an ITIL concept and there is more to it than just the name – Gartner, in its "Hype Cycle for IT Operations Management, 2005" report puts CMDB at the "peak of inflated expectations" with the "plateau of productivity" some 10 years out. It should be logically centralised, physically distributed, model the structure of IT service delivery and be maintained by some form of automated discovery. Both BMC and Managed Objects appear to have a CMDB worthy of the name, but don't underestimate the effort and maturity needed to actually implement one in your company.

In the end, BSM is important because it helps to nail the gap between IT and the business shut – and its prospective implementers have to decide for themselves which BSM toolset (there are others too, from IBM Tivoli for example) suits them.

Nevertheless, underlying all this BSM and SORM vision is an assumption that the parent organisation is reasonably mature – that it is committed to knowing or measuring what it has and how it is performing (for purposes of improvement, not blame), to documenting its goals, and to reducing the gap between reality and aspiration. This could be one of the reasons Gartner put CMDB maturity some 10 years out. If you work for the sort of company that values fire-fighting heroes and technical efficiency over effective business service delivery, attempts at implementing BSM or SORM may be doomed to failure.

And what does this have to do with developers? Job security, that's what. The business pays for IT resources in order to do business more effectively. It doesn't, in the end, care whether you can process 500 transactions/second 24x7, it cares about how many new customers it can process in a day and how quickly it can complete whole business transactions (and your 500 tpi 24x7 system may still deliver a two week overall turnaround for new contracts, say, if manual or batch bottlenecks aren't removed).

Unless developers can deliver complete, working business systems that are resilient and easily managed at the business level, developers may well fall foul of one of several nasty (from their point of view, and possibly only their point of view) kinds of outsourcing. BSM is part of ensuring that IT not only delivers manageable business systems but also is seen to deliver them, and SORM helps complete the BSM vision for BMC's customers. ®

Sponsored: How to determine if cloud backup is right for your servers