Risks of Data Sharing
In a siloed enterprise, each piece of data is encapsulated in its own data management system, and the application itself can control access to the data. In contrast, data in an agile enterprise can be shared, replicated and distributed on-demand around the IT infrastructure and there is no single application or data management system to control access to it. In fact, it is often very difficult to identify which services and applications are using a data resource. This is known as the 'Hidden Sharing' problem, and is one key aspect of what has become widely known as SOA Chaos – the loss of control and understanding that can result when the SOA vision is implemented in an enterprise.
For example, a designer builds a new application A1 that uses service S1 and data set D1.
As far as the designer is concerned, the application sends requests to S1 and D1 and receives responses from them (illustrated on left). Because of the encapsulation offered by services she has no idea of what other services S1 calls, nor what data sets they access. Therefore, she does not know that S1 accesses a data set D2 that is already used by other services S3 and S5. Further, data set D1 was already being used by one other application A2, but neither she, nor the designer of A2 know that it is now shared (illustrated on right).
In the following example there are two applications sharing data.
A danger here is that Application 1 may have been designed and built to operate on its own siloed data. Deployed on a Grid, its designers would have identified no need for techniques to control sharing.
Later however, Application 2 is written and deployed to operate on the same data. If Application 1 is not modified so that sharing between these two applications is controlled, by mechanisms such as transactions, then severe problems will occur.
In some cases, an application will require access to data in one or more databases, in which case more advanced techniques such as distributed transaction coordination may be required.