Todd Biske: Outside the Box

Do you have ERS? Jeff Schneider had a great post outlining the symptoms of Empty Registry Syndrome. One of the things that struck home with me was his last suggestion on how to cure it.

Verify that your registry doesn’t stink. Here’s the test: If you search for a service that doesn’t exist does it return with:
A) No results found
or
B) No results found, would you like to request a new service?
If the answer is “A” please call your vendor and let them know that their software is spreading a disease known as ERS.

Prior to becoming a consultant, I was at an enterprise where we were just beginning to explore the registry/repository space. We had one vendor come by and give a demo, and I asked them, “Is there any way to put services into the registry/repository that are in a planned state?” “Umm…. that’s a great idea!” A couple months prior to this, a project team contacted me about a service they would need. No one had implemented it yet, but we sent out a notification to the development teams about this request, and in came flooding all sorts of requirements, with no more effort than an email. It’s amazing what a little bit of communication can do, and think of how that effort could have been facilitated by some tools. The enterprise was embracing workflow technologies. I’m starting to see some potential here.

1. The project architect is building out the candidate architecture, and as that happens, the service library is searched.
2. If there’s a match, the architect can immediately register interest in the service. There may be tasks spun out of this to either the project architect or the responsible service manager.
3. If there isn’t a match, the architect has two option. Request that a new service be created, or create a planned new service.
4. If they request a new service, this results in tasks for a governance group to determine who the right owner should be, and schedule out a project. The project architect of that new task would update the service to a “planned” state from a “requested” state.
5. For services that enter the “planned” state, notifications would go out to the appropriate development teams with pertinent information, allowing them to contribute to the service requirements.

This scenario that I’m painting is an area that I’m going to call “Service Lifecycle Management.” Governance is a part of it, as shown, but there’s much more to it than that. It’s also not SDLC management, either, although that too is part of it. The service lifecycle doesn’t end when the service has been developed. The service lifecycle only ends when the service is decommissioned.

I think this area is one that is ripe for opportunity. I commented about this last year, but this topic still hasn’t received much attention from the vendor community. Mindreef was heading down this path back in Dec. 2005 with their Coral product, but there’s no mention of it on their website anymore (perhaps it was incorporated into SOAPscope Server). The challenge with lifecycle support for vendors is that it has to be about integration. Any product that tries to own the entire lifecycle will probably struggle. I see this space as being a combination of workflow/bpm, registry/repository, service management, and a service lifecycle management tool, at a minimum.

Look for a more in-depth blog on the Service Lifecycle soon. In the meantime, if you’re interested in an introduction to my thoughts on Service Lifecycle and being a Service Manager, a good starting place is this podcast I did with ZapThink last year.

4 Responses to “Facilitating the Service Lifecycle”