SWIM – How much information should we be sharing?

I would like to propose a simple rule: anybody asking how much information we should be sharing in air traffic management should have their Christmas bonus cancelled… Here is why.  
System Wide Information Management (SWIM) is the concept and set of rules, procedures and other needed elements that underpin the net-centric approach of the new air traffic management environment being built by SESAR in Europe and NextGen in the USA.
In a nutshell, the SWIM concept stipulates that the traditional and cumbersome point to point connections be replaced by a solution where those with data to share (i.e. data useful to the ATM community) publish the fact that they have this data (as well as any updates to it of course) and those who need that data simply go search for it or subscribe to it to avoid having to search. This arrangement assumes a kind of directory service not unlike that used on the internet and which helps you find your favorite movie title as it were. Don’t be offended by the comparison, in the world of networking, a movie title or a flight plan are not that different, they are both data. The difference is how we protect and handle the data but that is another story.
You will have noticed the fundamental difference between to-day’s approach to data dissemination and the one being proposed by SWIM.

To-day the originators of data (e.g. the originator of a flight plan) will try to figure out who exactly is interested in their data and then attempt to send it to them. Knowing which Flight Information Regions are concerned by the route may not be that difficult, but figuring out the zillions of other addressees who for reasons known only to themselves also need to be in the know is a good deal more difficult. The consequence? Over and under-delivery resulting in  a generally rather poor level of information sharing across the ATM landscape.
How will this change with SWIM? The originators of data will not try to figure out who is interested. They will just shout loud and clear that they have something to share. Those who are interested will be on constant listening watch for the information, in other words subscribe to it and hence get everything they want to have. If they want something else, they can go look for it, or subscribe to more.
The main thing is: unlike to-day, the originators will not be trying to guess what information to share and whom to send it to. It will be the information consumers who will decide for the simple reason that they are the only ones who know what they need and when.
So why should the question: how much information should we share cost you your Christmas bonus? The reason is simple. By asking the question you are bringing into doubt one of the most important, fundamental and benefit laden aspect of modern information management.
As a data originator, you should have only one concern: if you have data you can share, do it. Do not try to second guess whether there is anyone out there who needs it or who is interested. Let the data consumers decide whether or not they need something.
It is also a fallacy to claim that by sharing everything (within the bounds of data protection of course) the system will get overloaded. People even quote examples where trials to share too much have resulted in failure. Those trials were not set up in a properly constituted SWIM environment! It is not that you would send every flight plan to every node all the time with systems having to sort through all that stuff to select what they need. You publish the news that you have something, subscribers get what they need and others will be able to find your information if a new need arises.
Any attempt to try and pre-determine what should be shared is a throw-back to the current inefficient system and it would severely limit the benefits of SWIM. It would be a bit like building a steam locomotive that uses electricity to heat the water. It would lack the smoke but would not run any faster.
May be taking away the Christmas bonus is not even enough of a “punishment” for asking this question…