Invocation v Intention

Just a quick note here on Invocation v Intention. In the SOA Methodology there is the "Why" bit that talks about why services (and actors) communicate.

I thought it was worth briefly explaining the difference between invocation and intention in these communications.

The invocation is the actual act itself, it is one service initiating the communication and asking for a specific capability to be delivered. Simplistically the invocation could be seen as an event reception by a service, a message being sent from one service to another or a standard procedure call. The point is that the invocation is about the capability on the destination service.

The intention is why the consumer made the call in the first place and why the producer wanted them to. What was their reason for doing it? Now the uber simplistic view is "to cause the capability to be delivered" but that is just "to get to the other side" to chickens. It doesn't really explain why an invocation was made.

So lets take why sales talk to finance. Nominally the invocation is "Report Sale" or some such. This can have some nice pre-conditions and post-conditions around what that invocation will do but it doesn't explain why Sales every actually calls the capability.

The reason Sales makes the invocation can vary. If they are bonused then the intention of the invocation is "to get paid my bonus". If they are measured on the reporting time then its "to comply with policy". Understanding these differences helps you understand what IT needs to do. Where it needs to smooth the way (policy) and where crappy IT will be overcome by the end users (bonus). This isn't to say you can deliberately have crappy IT if the sales guys are bonused but it does mean that while the users will gripe about the issue they will be personally driven to overcome it.

The other bit is on Finance. What is the intention of finance when they receive that report, why do they want them? Partly it is to measure the sales team and partly to make the finance departments life easier by having accurate numbers. The point here is this.

If your sales numbers suck because of a poor IT solution then you can look at the intentions and see if they can be changed to get around the IT, e.g. if the sales team aren't bonused can you bonus them in a way that is cheaper than replacing the IT system but means the reporting accuracy goes up. If you can't then its quite clear that the IT project to improve the sales reporting to finance isn't something that Sales will be very interested in (after all its a Finance policy they are complying with), this means that the people who will pay for the project will probably be Finance. If the current Sales system does a good job for the sales people but gives crappy reports for Finance then there isn't a motivation for Sales to focus on that area.

This is why its important to understand both the Invocation/Capability and the Intention when modelling services and their interactions.

Technorati Tags: SOA, Service Architecture