Facilitating the Service Lifecycle

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”

  • I noticed IBM’s WebSphere Registry/Repository has default service lifecycles that include notions of early service lifecycle phases: Identified, Specified, Implementation Available, Operational, Retired.

    I love the idea of providing specification/modeling tools to project architects to specify what a service interface is then farm out the implementation. I wonder if designing a WSDL is the right level of granularity – given a slick tool to remove the grunge?

    Jim Murphy
    Mindreef, Inc.

    You’re correct that SOAPscope Server is the new name for Coral. We realized that we could only market one brand successfully and SOAPscope already had a large and loyal following so Coral -> SOAPscope Server.

  • Todd:

    Thanks for your comments Jim, I was hoping someone from Mindreef would see this post and offer some comments.

  • […] Interestingly, my recent post on facilitating the service lifecycle spawned an email conversation on this topic. The gist of the conversation was that many of the tools out there in the SOA space are targeting the Building Inspector, rather than the City Planner or the Developer/Landlord (developer in the city planning sense, not in the software development sense). […]

  • […] but I was surprised to find that I didn’t. Some time ago (January of 2007, to be specific) I indicated that I would have a dedicated post, but the only thing I found was my post on product centered development versus project-centered […]

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.