It’s been very exciting here in Quest land in these last few weeks. I’ve officially been with Quest for 1 year and I’m as excited as I was the first day. The breadth and depth of the offerings around Foglight is simply amazing.
Building on the last post, Service Level Management also has a few definitions in the Industry. The most widely accepted and used is the ITIL version:
“The Process responsible for negotiating Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on Service Levels.”
If you look at this definition for deployment in a domain, this isn’t a surmountable project, but if you look at tying this information from a domain to an application that spans the enterprise, it can be daunting. In fact, for quite a few companies it has been as billed as impossible after a number of failed projects.
So how does a company deploy SLM and not end up with a failure? There are many well documented approaches that will help get an organization equipped with all the necessary processes, alignments, etc. There is a long standing argument that the past implementation failures are related to project personnel, the vendor’s solutions, etc. I’m going to avoid that whole can of worms and focus on the building blocks for a success implementation that adds instant value with low maintenance in personnel and dollars.
The Plan: You can call this a design or plan, but if you don’t have a documented strategy, you’ll never know how well you did, how you can improve your next phase or know when you are done. Having been a customer for many years and working with many different vendors I’ve found that a well developed plan gives your projects a shot at success. It’s like building a car and not having an idea of what it should look like or if it will even have wheels.
The Plan should not only include your goals, it should lay out the structure or architecture of the Service Level Management strategy with details on the model, goals, processes, applications, domain deliverables, etc. I’ve always believed that you should be able to take a vendor agnostic approach to the architecture. However, I’ve realized over the years that this might a bit naïve view of the real customer world. Meaning that there are some point products that have been purchased and are strategic for other reasons within a company. I’ve had a few tell me that it would probably be a job ender if they didn’t factor them in when building out their architecture. Although for all practical purposes, the solutions you use should be able to support the processes and applications you are building in the architecture; otherwise the ROI on replacement of an antiquated product just may be worth it. Lastly, it should have well thought approaches on being able to deploy in phases, iterative ROIs, simple customization and low maintenance to keep the solution up to date.
Believe it or not, vendors really need to go through this same process with the twist of being able to be configurable to support just about any process or architecture. Ok, some don’t really do this approach J. For a variety of reasons they may choose not to or they have an architecture with little or no flexibility. Vendors should be able to answer these types of questions: What is your strategy on solving my SLM initiatives? How can your solution be easily customized for my plan/design? What automations do you offer for low maintenance? Etc.
Next up: More details on the architecture and additional building blocks for SLM success.