Where do your responsibilities end?

For those of you who don't know, I live in the Washington, DC Metro area.
For those of you who don't know, snow - ANY snow - completely terrifies and paralyzes the city.

While I was watching the news this morning, I caught an interesting quote. In DC and parts of Maryland, homeowners are *required* to shovel the sidewalks in front of their houses. If they fail to within a certain number of hours, they get a bill from the city for the shoveling along with a $25 fine. While this isn't huge, I thought it was fascinating that although you are allowed to exert no control over it, you are still responsible for the sidewalk's condition. Sounds quite a bit like programming against third-party systems, huh?

I have been working on a rather large XML-based system which is highly dependent on the output of a series of third-party systems which we have zero control. Unfortunately, when one of those systems changes - normally without notice - our system can't immediately adjust and know how to retrieve, map, and/or parse the new data. When the end user sees wrong or incomplete data, who's fault is it? Who's problem does it become? Does the customer really care - or believe - when a problem like this pops up?

Service Oriented Architectures are great, but once we're dependent on third-parties, how do we handle it when these systems break? Can we risk going into production with systems of unknown quality and unknown stability? Can we risk having to build these systems ourselves?

Within CaseySoftware, we're working on a pair of integrations of SugarCRM with external systems. For one of them, there is a commercial entity which it is their business to provide a fully functional system that provides the services we need. It's a pretty good assumption that this system will stay online with minimal downtime because it affects their bottom line For the second system, we have no such guarantees. In fact, in the case of some external systems (I'm looking at you Google!), things are in perpetual Beta and although there are API's available, we don't know when - or if - they'll be changing.

Is Design by Contract and option? I believe "Yes, but with a pretty big caveat." We still don't have any way of enforcing these requirements, but this may be a way of testing them and therefore being able to react to problems more quickly. Regardless of how much I love Unit Testing and even Enemy Unit Testing, these are reactive and not proactive. How do I prevent these problems from happening in the first place?