Practical AgileSOA - Making the first services

The question that always comes up is:
"How do I know where to draw a service boundary?"

Answering that question requires some more investigation.

Begin by looking at the piece of functionality that the client wants to cast into a service.
Let's take a universal example: getCustomer. All companies have customers, and many companies have a multitude of customer data sources, be it through isolated IT projects or through Mergers and acquisitions.

Some questions that come up at this point are:

"What do I use as inputs?"
"Do I return the intersection or the union of all the data from the various customer systems?"
"What if some data exists in system A and not in B?"

We need to step back here and ask ourselves:" What is it that you want this service to DO?"
Well, I want it to return customer information.
OK, and what do you want to use as search criteria on our first attempt to make this service?
I want to use, uh, first, last and company name.
Very well. We now have something to start with.

"...but what about returning duplicate records, and mismatches, and... and ... and..."

Relax, it's Agile! We'll fold exception scenarios in later.

Let's now make this service.

First, we make a client that invokes the projected service. Do we want to use a SOAP stack? If you must, sure. If not, that's fine too. Suffice to say that this client will act as our service "test".

Now we make a simple service that just returns data from a preloaded file.
Then we expand it to invoke one of the legacy customer data sources.
We continue to expand this service by adding another legacy data source and work out how to consolidate duplicate information.

At this point we may find that submitting first, last and company name is not detailed enough, so we need to add a parameter to the request. In essence, our service has now changed its interface and therefore is a new version.

Next post: Versioning services