I was flying from Montreal to Boston yesterday and we had a flight delay. Not that unusual, but I did what I always do when that happens - I went to the FAA's website to see what was happening.
I was expecting to see the FAA say it was a weather or volume problem. But, what I saw was "EQ:Automation" as the cause. I dug in, and it turned out that this meant the radar systems had gone down (the applications behind it had crashed).
What's even more interesting is the same problem happened at JFK, Laguardia, and Philadelphia at the same time! Now, since nothing popped up in the news, I'm presuming it wasn't a coordinated terrorist attack on the FAA (if it was, the terrorists did a poor job since the systems were only down for about 90 minutes).
But, assuming it was a software glitch, this is a great example of why reuse isn't always a good thing. Even though they would have had separate instances because they were all running the same software, it behaved the exact same way - and some common condition caused all of them to crash. Had they each been running different radar control systems, at worst, one of these airports would have been shut instead of 4.
Of course, the problem gets even worse when you reuse the same instances of an application as you do in SOA. A condition caused by only one of the consumers can bring down the service for all of them.
The advantage of not reusing services would be that you can never run into these situations. Now, I'm not advocating avoiding reuse altogether - just the contrary - reuse is generally a good thing. But it's also often good to allow for a bit of duplication (maybe 2 to 3 different variations of the same service). Healthy competition generally results in better service for everyone - and you end up with some protection from systemic failures of one common implementation.
If only the FAA had been thinking this way, maybe I and tens of thousands of other passengers wouldn't have been delayed yesterday.