Shearing Layers - Part 3

In the previous Shearing Layers post, I was talking quite theoretically about the rate at which stores could change their layouts to suit some time period. E.g. changing seasonal merchandise, etc.
How about we get even more radical. Perhaps we could (and maybe should) rearrange the store by time of day.
The traditional grocery store (at least in the USA)  remains relatively stable in layout (produce and deli at the edges, dairy and other cold stuff at the back, frozen food in the middle, other processed items in their own neat aisles). This well arranged for the weekly shopper. However for the quick in and out shopper this is not particularly convenient.
Let's do some imagineering here:
There is some body of shoppers who would like to go to the store more frequently and buy less stuff at once.
This group comes in in the time before dinner so they can buy what they need for dinner.
This group is intimidated by having to go all around the store to find what they need
We know what things are bought at which time of day.

Perhaps if there were a way to understand these kinds of habits we could arrange the store layout so it is a bit easier for these people to find what they want for dinner that evening.

Use small temp displays that can be prepared in the mystery area at the back, and have them rolled out to the specialized area. Create an ad campaign that matches the philosophy. Give extra points/rewards or whatever for people buying the dinner time special items. Vary the items a bit by day so you don't see the same can of beans each time.

The bottom line - Think about what can be changed easily (simple shearing layer), look deeply into the data you already have (and can get) to see if there are changes that might be beneficial. Make the changes quickly and cheaply (it shouldn't be an expensive operation - if it is you are at the wrong shearing layer). Measure effectiveness. Rince and repeat.

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.

Narcissistic Applications and Architecture

This post comes out of some work that I am doing with a client. Getting to the essence of event processing and what needs to be in place.
As many have observed, the metadata is often as interesting to the enterprise as the actual data. The trouble is that the enterprise doesn't necessarily know ahead of time what may or may not be interesting. perhaps applications that manage the state of domain objects should tell the world when they have changed the state of a domain object that they manage.
It is only when applications start bragging about what they have done that the enterprise has the ability to draw conclusions that range across the domains.
So while the current state of an interesting domain object may well be locked up in a transactional database somewhere, that the state change occurred could (and should) be made available to any/all interested parties.
Let's think in terms of an intelligent (but fictitious) home environment that we will call the IHE.
Our daily activities in the house include:

• Using hot water 
• Turning lights on and off
• Accessing computers
• Watching TV
• Sleeping
• Opening/closing the refrigerator
• Cooking
• Eating
• Managing the trash
• Managing the recycling
• Filling the dishwasher
• Dressing
• Doing (or having done) the laundry 
• Opening/Closing exterior doors
• ...

I have this feeling that my home bills are too high, so it might be interesting to see if any of my activities are inefficient (I leave lights on sometimes - so we have an event, followed by a negative event), if some of my activities can be co-related. Perhaps a change in one suggests an opposite direction change in another.

Now if, hypothetically, all my activities resulted in events being notified and somehow analyzed, then perhaps (and this is a big perhaps) I have the opportunity to look at my patterns and make some changes that result in savings in time, energy or general annoyance.

Of course we do the obvious ones. When we sleep, running the dishwasher is a no-brainer. But what about multiple uses of the oven? What about leaving lights on? What about leaving doors/windows open correlated with when the heating/cooling are running.

The point is that all of these state changes describe the minutiae of my life and I don't have the time, not the energy to capture them. That detail should be captured at the time it happens - if I am truly interested. It shouldn't wait until after the event when my recollection is hopelessly flawed.

Johnny Cash on Technical Architecure

Yes, that Johnny Cash aka the man in black. He of the deep voice, great songs, San Quentin concert...
I was having a cup of coffee at a local Starbucks yesterday when a friend showed me an "architectural diagram" of the technology components that a customer of his had shown him. Very proudly, all based on open source (because they don't want to pay license fees) they unveiled this masterpiece that they had taken several years to build.

Immediately I was reminded of this terrific song....

http://youtu.be/5GhnV-6lqH8

We architects do need to work on ensuring a few things:

• Don't overdo the technology
• Open source may be the way to go, but joining disparate things up can get expensive fast
• Ensuring that the pieces can connect (bolts and bolt holes anyone 2:05?)