This is part 2 of the series "10 Things Vmware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.
Number 2. The service catalog is the place where your user can document (communicate) their request
Let me show you an example.
If you to the Dell storefront and choose to look at servers,Dell has broken down their servers into classes (Rack, Blade, etc), which then provides diferent models, which can then be customized within the parameters allowed for that model. I'm not saying this makes sense for your environment, but the break down between classes, models, and then self-service configuration is a useful construct for thinking about your templates.
What are your standard classes of environment you provide? Could it be production, development, QA? What about models? Could those be on-line transaction processing, extranet, intranet HR, basic web server, basic database?
We would want to ask entirely different set of questions and configuration options for an extranet, high transaction database than for a personal development environment, wouldn't we?
It'd also make our job much simpler and faster if we know what parameters were involved for that particular request.
The service catalog is key to enable your customers to:
- Discover what's available to
- Guide me based on my high level needs,
- Help me compare models, then
- Assist me in customizing my request.
And of course all the tracking, workflow and lifecycle management that the service catalog enables. This is what makes a service catalog different from a "web form front-end" to help desk.
By the way, the best way to learn is to try it for free.
Comments