I have seen how it is built many times:
Department A has database, Department B needs to build a system that needs some info form the Database of Department A, but the database of Department A is behind a firewall, and you can not connect to it using a single port (it uses a random port range, or worse, a random port range connecting back in to the client computer) unless you make a major reconfiguration of the database server, and even if you could change the database configuration easily, the Network Department has a strict policy of only opening the 80 port (you can, of course request for a change in the firewalls/router configuration to higher management, but since the Network department has too much work, or has a political war with Department B it could take months before you get your requested configuration change).
So... what do you do? you use PoliticsOrientedArchitecture (also known as ServiceOrientedArchitecture) and build an XML based webservice and put it to run in a server inside the network of Department A, since it is in a web server, it uses the 80 port, and since it is already open, you can now build the system for Deparment B. XML and POA are the answer to all the problems (who cares if you could have achieved the same effect with a plain JDBC connection, or with a link at the database level). 1 year later you are preparing to buy an EnterpriseServiceBus (who cares if you could have done the same with some table views and some java coding, it is just too much trouble to deal with the Network Department, and it is just too easy to solve this kind of problems without speaking to anyone by adding another webservice, and now with you ESB, things are only getting better, years could pass by without you having to speak a single word with the Network Department).
And that is why SOA, I mean POA is such a success. SOA/POA is a technological solution for a people problem. And it is so much easier to deal with technology than with people.