Posted on 24 January 2011
The concept of Business Service Management and why it is good for IT (and the business) is reasonably understood by most people. The reality is that people tend to buy BSM solutions for the features it provides not just on the definition of BSM. For some organizations, a BSM product is purchased within some type of internal project like ITIL or a Dashboard project. When it comes down to it, those projects have requirements and they tie to specific features needed in the end solution such as;
- Console consolidation
- Root cause analysis
- Impact analysis
- Service Level Management
- End to End visualization of Services
The list tends to go on and on. When it comes down to it, BSM is something that you do within the solution (Managing to the Service, not the technologies), the features and functionality tend to be part of the BSM solution and where the purchasing focus should be. One of the core features required for BSM is the ability to integrate to many sources. There are many upon many tools within a large enterprise and many opportunities to pull in specific silo’s of data in order to provide a more complete view to the end users. Large enterprises need the luxury of swapping out underlying tools/application in the future due to over priced maintenance renewals, bad support, acquisitions, poor software and numerous other reasons. If the BSM solution is limited or not highly flexible in the ways in which it integrates to third party products, you may be stuck with some of those underlying technologies.
When evaluating BSM solutions, ensure that the solution has a robust integration feature. Some BSM solutions are only good with integrating with their own companies products, this is a bit limiting. Ensure that the are a few different options, ie: more than an SNMP trap or CSV import.
Posted on 13 January 2011
I ran across this article the other day by Doug Mueller and it reminded me of the multi-layer Service Catalog. I’m not sure if this is an actual term or not, but it’s a good description of what it is. If you take a very large organization that is broken up into distinct areas such as the teams that support:
- Hardware & Operating Systems
- Technologies (web servers, databases, messaging bus, etc)
- Applications (email, timesheet, payment processing)
For mature IT groups, they typically will drive towards a list of supported hardware and support operating systems, they will also typically drive towards a list of support technologies that will be supported within the environment. On top of these, some common applications (or services) are then provided to the employees such as email and the corporate web server.
If you walk through this, each of those teams has their own Service Catalog (and as Doug said, a Service Request Catalog). Someone in the technology area, after significant research wants to make this new technology available for sharing documents. The person requests from the hardware group for hardware and an operating system to be provisioned for this technology to run on.
Someone in the application area then decides to tie the document sharing, email, web and video together for a collaboration solution, so they in turn request services. The end users then request access to the collaboration service.
I have seen a few different approaches to this such as different links on the internal website to request hardware w/OS and another set of links to get applications/technologies installed to simple help desk requests. Regardless, while it may not be a full fledge electronic Service Request Catalog at each layer, there are lists of approved hardware, operating systems and technologies for many companies.