Managing Service Development

I’ve been participating in a thread on a Yahoo group about Service Analysis and Design, and broached the subject of project management. I recently authored a paper on this for a client, and thought it was time to share some thoughts on this. Mark Griffin recently had a post titled SOA Mistakes where he discusses avoiding JBOWS: Just a Bunch Of Web Services. Why do companies wind up with JBOWS? I think a lot of it has to do with the project management culture of organizations.

What is a project manager’s primary concern? Well, it could be one of three things: delivering the solution as defined (scope), delivering the solution on time (schedule), or delivering the solution on budget (resources). Based on my own experience, the one thing that will drive a project manager nuts is when you add scope. Adding scope either lengthens the schedule or adds cost, both of which are probably the thing that the PM’s performance is being judged against. Most PMs I know aren’t evaluated on their ability to deliver what was promised, they are evaluated on whether dates were met and costs were controlled.

Now, the next assumption is tied to the project inception process. Odds are that the project was proposed because of some pain point- a symptom. It’s like going to the doctor and saying “I have a sore throat.” IT goes off and builds some user facing application to address that symptom, because that’s the information they were given, establishing the maximum scope of the project. Using my doctor analogy, it would be equivalent to the doctor simply looking at your throat and giving you a box of lozenges. Now let’s suppose that user facing application that we built required a new service. That service would be built solely to the specs of the user facing application. If you asked the project manager for resources to seek out other requirements, they’re going to tell you that’s out of scope. So, the service then becomes a part of the throat lozenge. In reality, the reason behind the pain point may have been a broader business process problem. It could also be the case that the pain point had become an epidemic and was also occurring in other parts of the enterprise. Using the doctor analogy, I could also have had a runny nose, with itchy eyes, and hives breaking out- symptoms of an allergic reaction. In this case the lozenge is going to do very little to alleviate the problem, just as the IT solution presented probably won’t do very much in the long run either.

There are two things I’d like to throw out there as suggestions that may help reduce your risk of JBOWS:

  1. We need to be performing analysis outside of the context of project, solely for the sake of getting a better understanding of the business and the IT solutions that support it. If we don’t have models that give a broader picture, IT (and the business) will always be in the position of treating symptoms rather than the disease. If analysis is only performed within projects, the scope of that analysis is already constrained. Projects create constraints, just as architecture creates constraints. The architectural constraints should help drive the project definition, however, not vice versa.
  2. Services should be broken out as independently managed efforts. I think the temptation to cut scope is simply too great when a consumer of a service and the service itself are developed within the same project. For sure, if a service is known up front to have more than one consumer, it must be managed independently of the development efforts of either consumer. Unless your organization is able to be flexible when adding scope, the risks are too great. If you want loosely coupled services, then the service development should be decoupled from the service development.

Avoiding JBOWS requires challenging the way we’ve done things in the past. If you’re still building projects the same old way that you have, odds are nothing will change. Services will be built within projects, and people will have to justify breaking a service out as a separate effort. We build to our constraints and assumptions, and if people assume it won’t be reused, they’ll probably build something that won’t be reused. Rather, you should take the opposite approach. Assume from the get go that all services will be enterprise services, and will be reused. If the organization is embracing SOA, people should have to justify why a service shouldn’t be independent, not vice versa.

I’d love to hear other people’s thoughts on this. I’ll be posting some more on the subject, specifically on managing the handoffs when consumers and services are being developed in parallel.

One Response to “Managing Service Development”

  • Todd,
    Good suggestions. It really hits on one of the bigger problems for organizations that have a lot of silo development. Moving into the Services space is a very difficult challenge for these teams. It is a real culture change which should not be under estimated.

    I really think these types of organizations have to establish a COE in order to make SOA successful.


Leave a Reply


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.