People and Service Boundaries

In previous posts, I've been very clear in pointing out that services shall not ever share data except by way of exchanging explicitly defined messages. However one way in which data can be legitimately shared between services without exchanging messages defined by their service contracts is via people shared between those services (if you'll recall, people sit inside the service boundary).

Consider two autonomous services each containing separate applications shared by the same user. Now consider that as part of a cross-service business process, this user must perform a task within one application immediately followed by a task within the other.

It is possible that the user may have to take information displayed on the screen of the first application and enter it into the second. This is a classic example of swivel chair integration that we would ordinarily resolve with a composite application. But for now let us assume that we are dealing with separate applications.

So, what actually happened here? As it turns out, we have transported data from one service to another without the use of a message! Is this actually a problem? Well no as it turns out. In order to understand why, we need to consider the fact that people actually only participate in the activities of one service at a time.

Although there are many tasks that human beings can do simultaneously (such as jog and listen to music), people cannot actively focus on two problems at the same time. Sure people can switch quickly between problems, but this just gives the illusion of multitasking. The fact is, you cannot interact with two applications at the same time. You need to use one application, and then switch to the other.

This process of turning your attention from one application to the other effectively moves you from one service to the other. As a result of this process, information read from the screen of one application is transported to the other.

Now the fact of the matter is we still haven't exchanged a message conforming to either service's contract. However we have exchanged a message; just not in the traditional sense. Unlike messages sent and received by computer systems, this message has no syntax. It only has semantics.

The message was constructed in the mind of the user when he or she read the information displayed by the first application. When the user then swapped to the second application, the message was "transported" to the second service where its contents were then used to enter data into the second application.

Granted that this message did not conform to any service contract. But this is because the message has no syntax. The message is already understood by the user (and by extension the service in which the user is participating) and as such the service contract is not relevant.

Composite applications can automate this process so that our users do not have to manually copy data from one screen to another. When we do this, we need to be careful that data is not moved between services in a way that is not known to and approved by the user.

Composite applications should only automatically populate screens related to one service with data retrieved from another - they certainly should not automatically start shuffling data from one service to another without the knowledge of the user. To do so certainly would violate our service boundaries.

Consider the example illustrated below.


An underwriter enters some basic information about a new customer into the composite application, which then retrieves an insurance premium quotation. This activity is occurring as part of the Premium Quotation Service.

If the customer decides to proceed with the policy, at the request of the underwriter the composite application takes the previously entered customer information as well as the premium quotation and pre-populates the policy creation screen ready to accept the rest of the customer's details. The underwriter enters the rest of the customer's details and then saves the new policy. This activity occurs as part of the Policy Administration Service.