If interop b/w disparate and/or legacy systems is really the problem in these scenarios (as opposed to poor/lazy IT departments or customer service reps), then I really hope these companies are paying attention to web services and the interop they afford (and who isn't now-a-days with the hype machine in full effect) - Because, if they are taking notice and adopting web services, then I think we're going to see noticeable, measurable improvement in some of the basic services that we're accustomed to. Here's to hoping.[Just The Facts]

While Jon Udell gives a great success story Phil Windley wonders why Sprint couldn't do the same, here's a story of one of the abject failures. Web Services could help in this case, but as Phil pointed out earlier , it takes more than technology to get there. And I'd venture that the real problem here is people.

As a side note, given the way that the airline industry's getting shaken up, I wonder how Delta will fare, and how much of that could be attributed to IT. As a further side note, with the trend towards companies getting bigger through acquisition rather than "organic" growth, there's a lot of people out there who need to figure this out.

one of the design problems i used to see a lot at companies was when architects were trying to model a concept such as Employee or Customer. each project had their own idea of what such a thing should look like, and so it was almost impossible to create a first-class object that satisfied everyone's needs. attempts to create a common subclass were nasty, since even an agreement on what was common was hard to get, and even then this would change over time.[what's next?

Graham Glass is talking about the shortcomings of OO thinking, and his point here is the classic problem that you run into. I'd say that the other problem with OO is that the point is to bundle behavior and data, and frequently you're just dealing with pure data. This leads to either having lots of behaviorless data objects, or improperly adding behavior into objects, because there must be some useful operation you could do with it. One classic example that I see in the travel industry is with industry codes such as airport codes. Programmers commonly create objects that provide a decoded value, i.e. Dallas/Fort Worth International Airport for the code DFW, and pass these objects into the objects that build transactions that go to the mainframe, all the way up to the presentation layer, where the output gets formatted nicely for humans. It seems like a nice way to bundle up all the functionality surrounding airport codes. It turns out that this is usually a huge liability in systems that need to be internationalized, and what you find is that decoding belongs in display logic, which knows what language the user would like, not the business logic, which doesn't care. Even though you as a human think this is a useful function for an object, it's not useful for the object's actual user, a computer program. Plus, when you design objects that do decoding, they need to know about the data layer, so now you're dragging the data layer into places that should never see it. This is how tightly coupled systems come about. Sometimes, a string is just a string.