SOA Projections, Common Data Models, and eventually Surface Oriented Data Architectures
I admit before writing another line on this subject that I have more questions than answers and majority of my statements here should start with "I wonder ..".
SOA Projections: SOA defines a conceptual object model
Where i work there are upwards of 500 applications. In proportionate numbers are databases to support them. Services are the answer. A common API is the answer. Probably true. So I define a handful services. Some are queries and some are updates changing the state. Each service will take objects or structures as inputs and emit an object or collections of objects as output or none. Although each service is independent and stateless, the outputs of these services are corelated and taken together presents a well defined object model.
Query Services: Similarities to SQL
Moreover a query service has to be cogniscent of the amount of data it needs to return, say for displaying in a "paged" portal page. The same query service may also have to take in a "where clause" to constrain the data. The same query service may have to accomodate "sort" and even at times "aggregation" (such as sum, average etc). In short you need a similar (may be smaller) set of semantics provided by SQL.
Common Data Models
My hunch is that the "collective" output of a set of related services essentially presents a well defined "Common Data Model". So in a round about way the services originating from "n" number of distinct databases presents the picture of a "unified common database" on the other side. Perhaps what do we loose if this "conceptual datamodel" is to be realized in a physical database backed by a number of "data synching" abilities offered by "Master Data Management" technologies.
Say we do. Say we go ahead and realize conceptual common data model in a physical database with proper synching procedures. Now something like a web portal can take advantage of this aggregated/conceptual database using "horizontal portlets" (ex: SQL query populated in a web page is a horizontal portlet, for such a portlet can work with any data as long as it is the output of an SQL). This is not uncommon for reporting needs today by reporting engines.
I am sure there is a middle road. But the agility of horizontal portlets, well defined data models exposed closer to the end users, query like semantics, need for joins across services are questions to SOA.
Surface Oriented Data Architectures
The tendency in corporations is to hide all the data as far away from the end user as possible. In what I am calling Surface Oriented Data Architectures the data is migrated or presented as close to the end user as securely as possible. For instance searching music libraries or finding buying patterns in Amazon: I see them all as essential characteristics of a "Surface Oriented Data Architecture" where data migrates to the "surface".