Exploring the Impact of the SOA Lifecycle

In my last post, I introduced the concept of pre-consumption as a new and unique phase of the Software Development Life Cycle (SDLC) - one that only occurs when you have a SOA infrastructure.  What I want to do now is explore what this means.  What is the impact of pre-consumption on developers that are building services or composite applications?

In this post, I'll take a look at what pre-consumption means to service providers.

For service providers, pre-consumption looks a lot like production.  The difference is that, while your service may be in production, your consumers are still in development.

In the traditional SDLC, once you're in production the majority of problems that occur are operational problems - it crashes, it gets slow, it runs out of threads, etc.  By comparison, there are relatively few functional problems (it did something other than what it was supposed to do).  The reason is that you've gone through development and testing already, and have hopefully worked out all of the functional issues in these phases.  Sure, the occasional functional issue slips through the cracks, but that's the exception not the rule unless you're talking about Vista.

Historically, once something is in production, operational issues were what mattered most.

With pre-consumption, though, the consumer is in development.  What this means is that the service provider will have to deal with a large number of functional issues in production.  Some of these will be real functional issues - you couldn't afford to test all of the permutations of ways the service might be used could you?  Some will be the consumer not understanding the quirks of how the service behaves - despite the exceptionally thorough documentation you wrote for the service.  Yes, you'll often hear the consumer saying, "I sent the right information in, but your service didn't work right," whether it did or not.

So, even though you might think your service is in-production, if you are really in pre-consumption, you need to focus on being able to diagnose functional problems.  Dealing with operational problems will be secondary.

As a service provider, the other side effect you'll see is that because consumers will often have unique needs, to serve your consumers well you'll end up having to version your service a lot more often than you might be used to (when consumers and services are designed at the same time).  So, this will put additional burden on your ability to manage versioning of your services.  This becomes especially challenging as different consumers test or even run services against different versions.

SOA What? As a service provider, get ready to dramatically change your expectations of how you support your service once it's "in production".