There still seems to be a lack of understanding out there around how data architecture and management relates to SOA. The confusion is around the fact that most see data as just there, and while they do leverage it from services, they typically don't bother to reach the architecture back to the data -- or can't.
There are a few reasons for this:
First, those who control the databases may not like those who are building the SOA and block all efforts to add middleware-delivered data abstraction and virtualization layers. Moreover, they won't allow changes to the core database. Thus, those who need to create services just deal with it programmatically, which removes much of the agility value from their SOA.
Second, the legacy databases are typically in bad shape. It's like the one room in the house that is a disaster area: Nobody wants to take the initiative and clean it up. Also, there is risk in doing so. Thus, it's easier to create services on top of the data that mask the problem but do not solve it.
Finally, there is no data talent on the SOA team. A common problem is that nobody bothers to understand the links with the emerging SOA and the existing data, since they is nobody on the team who understands it.
This is a true risk to delivery of SOA. In essence, we're reinventing the architecture and thus most consider all systems holistically, including the data. However, the data is typically where there is both a lack of understanding and a lack of effort, and thus SOA becomes the lipstick on the data pig -- not good.
Don't be the lipstick. Make sure there is a comprehensive data plan that is systemic to your SOA. This includes some back-end changes or the use of a well-tested data abstraction and virtualization technology that can fix data issues within the middleware. It's not an option to simply ignore the data issues. Your SOA will surely fail if you do.