I just concluded my first BarCampESM presentation today on how Business Service Management (BSM) may play out in the Open ESM space. I’ve shared some of my thoughts on what I’d like to know about the leading Open ESM players in terms of their capability to support BSM, industry opportunities for proprietary and open ESM companies, and a conceptual assessment approach to determine how well companies support BSM goals and objectives.
Key thoughts:
- Are Open ESM Tools BSM Ready?
- How can the community move up the value chain?
- How can everyone improve?
My presentation from today is available here: BarCampESM – Where’s the Beef?
Comments on this entry are closed.
Hi Doug,
I really enjoyed your presentation and it provided a lot of food for thought. It elucidated gaps between current generation ESM tools and BSM goals. I was especially intrigued by several industry opportunities you see to help bridge these gaps:
* “SMDB” for the monitoring tools group
* Event profiling that helps EMS teams tune monitoring against best practice policy
* New kinds of visualization
* Edge enabled/fed dashboards (share key metrics to central source rather than excel)
The bottom line is BSM is really about managing IT like a business, and these are key tools help manage software operations environments.
Questions:
Do you envision components like “SMDB” and “Event Profiler” as separate but complementary components that interact with the ESM tools?
I was particularly interested in your concept of an SMDB.
What kind of content would be maintained in the CMS? Do you envision content distributed to other disciplines? Is it a two-way publishing model wherein business analysts are also contributing content?
Does the ticket/workflow engine control modifications to the EMS infrastructure? What kind of workflow do you imagine?
Thanks Alex! It was a pleasure to meet you at BarCampESM. I hope can collaborate on some of these ideas and concepts.
I see the SMDB and Event Profiler as independent components. They certainly complement it, but the real key here is that they operate across a heterogeneous environment. There’s no one stop shop for vendors these days. The concept is that these components operates across the IT mgmt and EMS environment to enable true end-to-end orchestration and “event/metric/kpi” profiling.
The concept of the CMS is that it’s just that – something that the IT mgmt or EMS group uses to manage the management environment and tooling. Ask anyone in the typical NOC, EOC or consumer of a dashboard why something is red or yellow. Chances are they can not tell you why or what it will take to rectify that state. The CMS component helps address this. It’s all of the central configuration information for all IT mgmt and EMS activities. It’s the key relationships between these tools and applications and the things they’re managing, the business and the IT and business requirements for them. I could easily see your platform as one that could consume a “work order” to deploy and provision IT mgmt and EMS components across the IT environment. The business analysts, IT SME’s, application development and support, etc. would interface with this and create the official requirements. The requirements are processed against some “business, IT mgmt or EMS rules” and then an output “work order” is created for automated action. I think this can all be automated. This is what we did when we built this at ELNK. The “policy” was the internal standards for how a server or network device was to be managed, the engine then interacted with all of the right components to provision the “work order” specifications.
Whew, that was a lot. Maybe we should collaborate on this first. I know John W. wants to!
Doug