SOA and database

A traditional view of data is as a structured collection of attributes. Each attribute provides information: in Bateson's phrase, it is a difference that makes a difference. For example, let's suppose the attribute CUSTOMER CREDIT LIMIT controls the outcome of some business transaction - whether the customer is permitted to place an order, or has to pay upfront. (The difference in the attribute value causes a difference in the transaction outcome.) We are accustomed to having such attribute values stored in a massive database somewhere, and passed around in XML packets. But the attribute value is itself the result of some calculation, judgement or negotiation. In a genuinely real-time enterprise, this calculation, judgement or negotiation would be done in real-time, with zero latency. Of course, there are organizational as well as technical reasons why we don't generally do this.

So the things in the database are simply those items that it happens to be more convenient to store than (re)discover. At any point in the future, some items may shift from storage to real-time discovery. The content of the data layer should not be fixed for all time, but we should expect it to change as the costs of real-time discovery (both in performance and in design/development effort) are reduced.

Thus SOA erodes the traditional database data layer. This is NOT just removing data replication (as Lawrence Wilkes advocated in December 2000), but removing data storage altogether. At the present technological state-of-the-art (SOTA), this is only going to happen in isolated areas.

In his ServerSide article The Fallacy of the Data Layer, Rocky Lhotka imagines the wholesale deconstruction of the data layer, and the impact on the application, although he doesn't go as far as I am suggesting. Then when he is attacked in the subsequent discussion for his apparent SOA enthusiasm, he sidesteps and says he was being sarcastic. But while there may be considerable scepticism about the current viability of his remarks, it seems perfectly reasonable to present this as a hypothetical future scenario, if and when certain technological and organizational conditions are met.