A data layer is all about abstracting the explicit boundary between the application/ domain model and the persistence datasource.
Although this boundary can never be totally transparent, the data layer does its best to expose the persistence data in a way which can be easily and suitably utilized by domain model. A simple example is accessing a file through a reader interface which abstracts the user from the underlying details of reading a file from disk. A more complex example is accessing relational databases which abstracts the user from the underlying storage mechanism and enforces a number of domain specific rules in an effort to keep shared data consistent.
This requirement is totally orthogonal to whether SOA or traditional 3 tier architectures are being utilized. I am continually amazed how various people in the industry are suggested that SOA means the end of objects and the data layer. To me, a vast majority of services are going to be written in OO languages and still need to persist data. I suppose one could say that data persistence will just be another service (a very special service at that) – but this is just adding a façade to the same requirements and the same code. In fact, I would guess that a significant amount of ASP.net code is doing this precise task on multitudes of production systems today.