Are there People in my Service?

Too often in discussions around SOA the focus tends to be on the systems, rather than the people. Applying SOA in a business context involves aligning the services with the organisational structures and business processes they support. As such, people play a big part in service definition.

In truth, a service involves more than just the IT systems, it includes the people that support the function performed by the service (assuming the service is not completely automated, in which case there would be no people). This is because the people that interface with the service (via a UI) make various decisions that support the business logic of the service.

Usually we automate the structured decisions within the service with programming, and rely on people to make the unstructured decisions. People are an implementation detail of the service, encapsulated behind the service boundary.

To make my case I'll use an example. Say we have a service that performs risk assessment in an insurance company. Initially let's say the service is implemented such that when a risk assessment request arrives, it is routed to a worker where it sits on his or her work queue.

The worker eventually pulls the item off the work queue and performs the risk assessment against the risk assessment service via the UI. The system then sends a risk assessment response back to the requesting service.

Let's say then at some point, the business decides to automate this process. The worker is taken out of the loop, the risk assessment UI is thrown away, and a rules engine is put in its place. The service contract has not changed, so to the outside world, the service remains the same; but we have now removed the worker.

The worker is therefore an implementation detail and sits squarely inside the service boundary.