PMG Service Catalog

Thanks to a referrals from James McGovern, I spoke with Andrew Kramer this morning and got a quick demo, of PMG Service Catalog. Overall, it was interesting in the same way that Opalis was (see below) and seemed like an open enough platform for fitting in with other IT management options. Conceptually, as with much of ITIL-think, I wonder if there’s not a little too much abstraction into parts between a help desk, problem/incident management, and a service catalog. By the book, it all fits, but in practice I’m curious how much separation is helpful. The usefulness of any service catalog is predicated on the usefulness of that distinction, so it’s worth considering.

But, first, just what is a service catalog?

Service Catalogs Display What IT Can Do For You

A Service Catalog is an ITIL concept that’s similar to a “run book,” as last seen in the Opalis briefing we had recently, but more inline with the concept of “services IT offers.” For example, provisioning a new user, installing new software on any given machine, or getting a new laptop. That is, here you’re managing change requests.

I forgot who I first noticed mentioning this meme, but service catalogs are sort of second tier in attention given compared to service, or “help” desks and CMDBs. Why is this? Without too much ungrounded speculation, I suspect that a help desk and a CMDB are a good mix of immediate value to customers and long-term project/concept lock-in for vendors. That is: a help desk takes care of your trouble-ticket situation, while a CMDB sets you on the long-haul to ITIL implementation. More importantly, if you’re going with loosey-goosey ITIL, you can consolidate some of the functionality of a service catalog into a general help desk.

Part of ITIL Workflow

Like Opalis, PMG Service Catalog lets IT folks define workflows for that describe processes in IT. But, unlike Opalis, PMG Service Catalog is more about fulfilling requests not associated with problems and incidents (broken things in IT). Now, to an ITIL-head, that’s obvious: you’ve got change requests, incidents, and problems, and why conflate them all?

That’s rhetorical question of course. Ideally, what I’m looking for in IT management platforms is simplicity either in providing a complete solution or, more likely, being a well behaved part of a given solution rather than a loner. That is, I like to see IT management applications that work well with others.

While I obviously can’t vet how well any given software works in an hour-long phone call, from what Andrew told me, integrating with other systems — help desks like Remedy in particular — is key. PMG Service Catalog is in .Net, but there are web services for other integration. Also, the workflows you construct when fulfilling a request can be programmed with scripts and calls to web services, given another point of integration.

Self-Service

As with most request driven processes, the provider of those processes (the IT department) benefits from as much self-service as possible. PMG Service Desk is built on-top of portal technology, so it certainly offers self-service when it comes to filing the initial request and checking up on the status of request. I really liked the feature that allowed requesters to get a visual of where they were in the workflow used to satisfy their request. That is, instead of sending your request into a black-hole, you can track the request visually along a workflow diagram. Kind of dorky, but better than plain old text in email or web pages.

Collaborative Systems Management

Andrew and I also talked about my old hobby-horse of collaborative systems management. In the case of PMG Service Catalog, you have all these people defining workflows — here’s what we do to create or re-provision a new user — so it seems like a natural chance for sharing across fire-walls. That is, you could see a web-site where people could upload the request fulfillment workflows they’d created and, like Klir does for thresholds and reports, allow users to vote on the best ones. Users could then suck in those good looking workflows.

Increasingly, more and more vendors and projects are offering what I’d call “collaborative systems management” or have told me it’s in the their short to medium term road-map. As those are delivered, I’m hoping that the ability to share “knowledge” (as Microsoft would call it) across fire-walls will become a valuable and taken for granted feature.

Like all co-creation and knowledge/effort sharing based ideas, the effect on the bottom-line for companies is spending less money. That is, once sharing becomes easier, knowledge becomes cheaper because, well, it’s not locked up in consultants heads. End-users are more likely to freely share info than vendors whose prime business is rising up the price of best practices by limiting access to it.

Talking about this with Andrew, I realized it’s the classic vendor/partner relationship dilemma: when you do sharing and co-creating of workflows and best practices, you’re cutting out the consultants and integrators who, in large page, sell that know-how packages up in customized implementations. To that point: disintermediation such as this is one of the prime business-strategy features we have in IT now-a-days: it’s low hanging, if painful to chew fruit for differentiation.

(And, to answer McGovern’s first question: no, I don’t think OpenID is on the road-map ;> But, they do give respect to the mighty Active Directory.)

Disclaimer: Microsoft and BMC are clients.

Technorati Tags: pmg, servicecatalog, itil, opalis, workflow, briefings, klir