Guess you've never been to the other side of that. The other side of that is a set of applications that are good enough to win your company the business, but that don't work together at all.

You can say "you should have thought about that in the first place, good design would have cleared that up" but good, thorough design that attempts to make everything work together flawlessly results in long development cycles and lost business.

Our company won, we built the best products and got the market share, and now we've got a set of applications that our customers expect and want to work together, and we are struggling to deliver it.

SOA is one way we can help with this problem. We can add SOA interfaces to each application, and start constructing the one integrated product our customers want, in an orderly way, quickly, without re-writing all our apps, and piecemeal. We can add SOA interfaces to each application's back end, one at a time, prove it works, and then work on meta-applications to combine the results.

We built much of the software to handle this ourselves. There are OSS options for most pieces of this architecture if we wanted to use an ESB engine (check out Mule for example), and with our VM environment we should not need significant investment in infrastructure. We just need time to build it, and hence corporate wherewithal.

SOA (and ESB and the like) in-and-of themselves will not provide a solution to enterprise integration, any more than the EAI engines of 10 years ago, but at least they provide a common technology to build around so that other developers can tap into the functionality of our applications.

The same kind of arguments were made in support of C: that hard-to-maintain spaghetti code is not the language's fault, it's the developer's. But the bottom line is this: if the language fails to enforce some basic good coding practices, then the code won't be easy to maintain. It's difficult, if not impossible, to find and hire the kind of talent across your organization that can keep the code maintainable and readable. It's just as hard to review all the code to ensure it meets your development standards, and train junior engineers on how to do it properly. Therefore, just having Perl or C code to maintain means you are almost guaranteed to have harder-to-maintain code, that has to be worked by more-senior developers. Those very developers are who you need plugged into new projects that require senior developers and out-of-the-box thinking. If they are tied up cleaning up the spaghetti that other engineers produce, you lose productivity across your organization, and your senior guys want to quit.

Java, .NET and other shiny new languages help in significant ways in making software products easier to develop and maintain. So Even though I can code nice C code, and I can handle pointer arithmetic and memory allocation well, doesn't mean I can find all the resources I need to ensure that same level of development in all my products.