Events, messages and state

I have recently had the need to think about messages, events, and state. I may have finally caught up to where Nigel Green was three years ago!

These three ideas are often bundled together, but really they represent different things. And when we try to treat them homogeneously we run into difficulties.

Dealing first with a message. messages are units of transmission. They provide a mechanism for moving some bits from point A to point B. The arrival of a message is an interesting "event" in the technical domain.  Useful for capturing statis, handling billing, etc. But it is not really the business trigger for business functionality.

The events amy well be bundled up inside a message. A message may well contain information about multiple events. In the airline reservation world, w might have events that create a new reservation skeleton, add passenger(s) to that reservation skeleton, add itinerary information to that reservation skeleton, etc. In other words events that indicate lifecycle happenings to the reservation. However, during the reservation business process, the various happenings may all end up being bundled into a single message. Or they might be separate. remember the message is about transmission not functionality.

Then there is state. By state we mean the values of all of the attributes associated with an object of interest. yeah, I know, a bit vague :-(. So the state of a reservation is the state after the various events have affected the reservation. That state might be notified after just the itinerary has been built, or it might be after the itinerary + passenger + pricing. The  state is set at a relatively arbitrary point in time. That's a packaging issue.

In some cases, message size limitations will demand that multiple transmission units (messages) be required to transmit the complete state.

Bottom line EAI type patterns generally assume some kind of unification between message/state/event, but in reality they are separate concepts and should be handled differently. 

Victim of a professional with attitude - a requirements story

Again, a post that isn't so much about architecture - more about miscommunication, but this time with me as the 'user'. It illustrates how the poor 'users' feel when we behave like Scott.

First the back story. In our kitchen we have french doors leading to the back yard (garden for my non-American followers). They have double paned glass and mini-blinds between the panes. So we get insulation and privacy. The whole assembly (doors, threshold, etc.) is in a single unit.

If you think about it there are essentially 4 configurations possible.

• Doors open outwards, left door is the main door
• Doors open outwards, right door is the main door
• Doors open inwards, left door is the main door
• Doors open inwards, right door is the main door

Of course, the beginning of the issue  can be seen in the above definitions. Left/Right - from which perspective? In/Out - from which perspective.

The first mistake that I made was that I didn't know that most of the time the building codes here specify that french doors open inwards. So I described what I needed to the salesman (let's call him Scott - that is after all his real name). I explained that I wanted the left door facing outwards to open. So, he did the mental gyrations and pointed me to the one he thought I wanted. It wasn't - it did have the left door facing out as the opening door. But the whole assembly opened inwards - and is not reversible.

So I had to return it and order the proper one. Now I am not an expert in the internal naming of sides of doors, conventions in the industry etc. I have a requirement. Open outwards, left door facing outwards must open. So the developer - oops, Scott again translates my requirements to the specification (the order) and asks me to sign off. I naively assumed that the requirements would have been correctly translated to design - silly me. What did I get? Outward opening, right door. And since it was a "special order", I would have to pay again to get the correct one.

There is presumably some assumption about how doors are specified. Is the specification left/right as determined by the direction of opening? Is there some other way? I don't know. That is part of  the technical world of doors, not part of my desire for use.

With all that rigmarole, I came to a few conclusions for us as practitioners:

• Our users don't know our vocabulary
• Making users sign off on specifications when they don't know the vocabulary is costly
• When we then make the users pay twice because of miscommunication we are failing the people that we should be delighting. 

All in all a bit humbling for me - when I assume that the user actually understands my jargon/terminology I am usually wrong. Note to self, when providing a service, don't jump to conclusions in your translation from the world that the user inhabits to the world you inhabit.