Interoperability this, interoperability that… it is clearly an important conversation in our industry today, and one that spans the whole range of vendors, technology areas and end users.
Frequently conversations around interoperability get pulled in the direction of the technology that is in use, but while there is clearly work to be done here it is important to recognize that solving this problem also means tackling a number of other dimensions of the issue.
In 2004 the IDA in Europe issued their first version of the European Interoperability Framework, several IF documents had proceeded it but as far as I remember this was one of the first documents to look beyond the technical issues of interoperability and begin to examine other challenges that would need to be dealt with to provide truly interoperable systems across agencies in Europe.
On a very simplistic level the document broke the interoperability challenge down into three distinct layers;
Technical Interoperability – lets move on…
Semantic interoperability – this involves looking carefully at the language that is in use between agencies and business processes and lays down a goal of harmonizing elements where it made sense to do so. The goal being that a descriptor that might be used to define a part of a process within one agency would be understood to mean exactly the same thing in another agency. If I am tagged as an individual receiving child support benefit in one system then all other systems should know exactly what that means.
Organizational Interoperability – this section talks about something that is clearly a huge challenge for any organization, looking at how business processes intersect and what type of organizational changes need to be made to ensure that those processes work seamlessly together, at least when viewed by the consumer of any resulting service.
So, with the history lesson over lets get back to the point of this post. Over recent months I have been rolling the IDA model around in my mind, and keeping an eye open for examples of interoperability where only the semantic and organizational layers of the problem have been dealt with to fix a particular business challenge.
Two weeks ago I was at a Microsoft global get together in Thailand and happened to bump into another blogging friend of mine, a chap that some of you will know by the name of Doug Mahugh. Doug has been in the industry for a number of years and has seen several sides of it, as a result he is a great guy to pose questions like this to, and invariably he will always have a smart answer to hand. This time was no exception.
Doug pointed me to an example on ushero.org that talked about the way that the emergency services work together when they are jointly searching disaster zones for signs of survivors or those in need of help. During the conversation Doug talked pretty extensively about the work that took place straight after Hurricane Katrina in New Orleans, and presented a very simple model designed by the US emergency services to allow several different services to work together without duplicating efforts, and at the same time providing very clear communication about the status of the searches between teams on the ground.
As I say, the model is a straight forward one. As a team enters a building they draw a simple stripe on the outside by the door from top right to bottom left, this tells any other team that comes by that the building is currently being checked. When the team is done they draw a second stripe from top left to bottom right that completes an X and then use the four quadrants of the graphic to convey important information about what they found in the building.
Click on the thumbnail above to enlarge the picture and take a look for yourself.
In my view there are lot of lessons to be learned from this by the information technology community. As a community we get very involved in the technical challenges of interoperability when sometimes, as in the case above, a simple change in the design of the business process or the language used to communicate between teams might have been all that it would take to solve the problem that we’re faced with.
Making changes to business process can frequently meet resistance due to a need to involve senior management or other cross sections of the organization, but as the team looking at interoperability of government services in the European Union had already worked out some years ago this is sometimes the quickest and most cost effective way of tackling a given problem.
If you are aware of more examples like this then I would love to hear about them!
We cannot dismiss the technical work that need to be done, and is being done in the area of interoperable systems.
While it might sound obvious, we often seem to miss the fact that there is great benefit for all involved to look at these issues in the context of the wider business challenge that is being solved.
Sphere: Related Content
I couldn’t agree more. While advances in interoperable communciations technologies are critical to solving this problem long term, the oprganizational and operational issues are equally important. This is particularly true when trying to foster cooperation and communication between groups who are ofter at odds and fight to maintain their status and territory (i.e. police and fire). As an example, look at the roughly $500 billion that has been spent on interoperable communications in NYC. The majority of the problems that drastically increased the number of lives lost on 9/11 still exist today.