Anatomy of a Service Project - Part 1

So if we are going to move to Service projects what would a service project look like? What is the plan for Service projects, what do you do first, what are the important principles?

Well first off you need to do the basics, Services don't mean you can ignore the standard good practices this means

1. Iterations - Iterative delivery is NOT "agile", its just plain good delivery.
2. Testing - Unit Tests, System Tests, automated
3. Requirements - defined, managed and tracked
4. Quality - metrics, tracking, code reviews
5. Version Control - all artifacts managed and tracked
6. etc etc etc

Service Projects are still projects, they should be pretty small projects but that doesn't mean you can just hack something out.

Before the Service Project starts you need to know what the Service is, this comes from the Service Oriented Architecture work that you will have done earlier to define the services you actually need, this will have created a service definition which describes the primary tasks and purpose of the service, and if you are lucky links to the actual objects being used. So at a top level we have a pretty simple process for our service project


Not much different to a normal project in fact, the only bit that gets more important is the interface definition.

So a service project is defined from the service architecture, applies standard best practices and makes the definition of the service interface a critical element in the process. Certainly not rocket science. It can be developed in a single iteration, or as many rapid iterations.

As with all decent project approaches a key practice is to attack the highest risk items first, with a service this is most normally the service interface as it has the largest external impact if it needs to change, what you want is to get to a relatively static interface as quickly as possible, future iterations then consider the policy and governance aspects of the interface rather than the actual calling semantics.

TBC...