This is something that has been vexing me on my current project. My client has made a strategic decision to embrace web services, and thereby achieve SOA nirvana. Trouble is, no one here seems to know why an SOA is important, or how slapping web services on the front of all their legacy systems will help. The answer, of course, is that it won't, and that sticking a SOAP interface on a batch job is simply missing the point.
Drift back through the years, and you may remember the fanfare surrounding Bill G's "Business at the Speed of Thought". It foresaw the frictionless interchange of data within an organisation and beyond, bringing companies ever closer to their partners and customers. Executives would demand real-time business critical information, and companies would react to change in a fraction of the time... etc, etc. The idea got lost for a while, but is back with a vengeance along with the SOA, ESB and "real-time enterprise" (e.g. IBM's relentless "on-demand" adverts!)
The RTE redefines the way data is exchanged - it'll be on-demand, event-driven and message-based (you can add in loosely-coupled and asynchronous if you like that sort of thing). Item-level data changes can be broadcast to anyone who needs to know, and lengthy, error-prone, batch jobs will no longer be necessary* (is there such a thing as "downtime" in the global economy?)
This obviously requires rethinking the way your business operates.
So - you can't just SOAP your legacy systems and claim SOA victory. A well-designed SOA must include deep changes in your business processes, and if you find that after the consultants have left you're still working in exactly the same way, only with SOAP requests replacing flat-files, then ask for your money back!
* I realise that batch jobs will still prevail in many areas, where large volumes of data are being exchanged - the important thing is to recognize where they still have value, and to learn to say NO when someone suggests replacing it with a web service!