The importance of common reference points

Recently I've had a couple of occasions where a major issue was created from something quite simple because a perceived common understanding just didn't exist. What does this mean? Well it means that one team thought that the definition of X was something and that the other team thought it was something else. Because however it was so clear to both teams they didn't check and it became an issue.

The point was that the common reference point wasn't what everyone thought it was. This isn't about canonical data models, which can still suffer from issues of definition, its about the cultural aspects of a programme and about the importance of defining a few basic elements that people can agree on. A core piece on these basic elements is that everyone agrees on a specific definition and any change to these basic building blocks can have lots of unintended consequences.

Since then I'd been looking for an example that lots of people could understand about how important this was. Well thanks to the wonder of the previous US Administrations I have one.

Daylight Savings time.

For many, many years the whole world switched to Daylight savings, or summer, time at the same point. This helped to some degree with power consumption but the point was that everyone who was going to switch did switch. Some countries didn't (e.g. India) but at the top of the Northern Hemisphere everyone switched at the same time.

Then some bright spark in the US Government somewhere decided that while the rest of their energy policy was a complete shambles they could at least sow more confusion by making the US switch a few weeks earlier, which meant that the poor Canadians had to change to match the crazy neighbour.

So historically there was a set of dates that everyone agreed on and where everyone switched at the same time. This meant that calendaring solutions could work globally in a simple manner and you wouldn't have to upgrade them as it was all known well in advance. It also meant people could know "East Coast = UK + 5 hours" or "India + 5.5 = UK in the winter and 4.5 in the summer" and then combine the two to get a 3 way call going.

Now however those basic rules have failed for a few weeks of every year because the US moves earlier and drags Canada with it. This means that for a couple of weeks I've had lots of calls that have "missed" due to the timezones as people just don't expect a fixed reference point to move like that.

So the point of reference points when you are working in distributed teams are simple. Firstly make sure they REALLY are clear and secondly make sure they REALLY are fixed. Whether this be something as simple as an XML schema and a data dictionary or as complex as a full business strategy the important element is that both sides need to agree on the starting points and on where they interact.

This is the basic principle for me behind my SOA method, creating a simple reference point that all people can agree on from both business and IT and defining the boundaries between teams. This makes the reference points explicit and massively helps reduce the communication problems, best of all I don't have a US Government making adhoc decisions to change parts of the the model mid-way through the project.

Technorati Tags: SOA, Service Architecture