Recently, we talked about reviewed Principles of Service Orientation or SO principles and discussed different aspects of relationship between the business functionality of services and the data processed by the services. It is the time now to summarise our arguments.
The major business goal of a service-oriented solution (SOS) is to provide flexibility in adopting business changes and, by this, to support efficiency of the organisation's business. The mechanism that the SOS uses is based on the SO principle of Composability: majority of business changes are addressed by creating new service compositions or modifying existing ones. Higher flexibility may be achieved by more universal, i.e. complex, solutions or by better separation of concerns. Here are a couple of examples.
Suppose, we have a bucket. We use it to carry some goods or materials. Does the bucket care what material it is used to contain? Does it own the contained material? There is only one rule exposed: the better a material matches the shape of the bucket, the more efficient the bucket may be utilised. If we can wrap the material by a special cover (water and dust resistant, for instance), we can place water, oil, sand, or stones into the same bucket in different situations. That is, we can reuse the bucket in different execution contexts. At the moment when we start to modify the shape of the bucket for the advantage of particular materials or tie the bucket to particular source of materials, we loose flexibility of the bucket utilisation.
In another example, we use a credit swap transaction (CST) as a business data model. The Model comprises 42 different information elements (data fields), which we can consider as a CST ontology or structure. The CST is used in several business services, e.g., Risk Exposure Calculation service, Client Reporting service and Netting service that operate with groups of 14, 3 and 12 information elements from the CST business data model respectively. These data groups have some overlapping data.
If assume that the business service owns the data it uses, which service owns what data in the example with CST? Also, we have to put into consideration that tomorrow the Risk Exposure Calculation service might need a little different set of data as well as there may be a new service constructed that deals with CST as well. The proponents of canonical data model will, probably, suggest that to solve the problem of variety of CST presentation within different services, each service has to take the entire CST canonical model but use only the data it needs. However, none of the services and service management bodies will agree to this approach due to very simple reason: 'my service should not suffer because of somebody else's problems'. This statement is based on the fact that particular service does not want to deal with what it does not use - the extra data - due to security and performance reasons as well as because such sharing is the de-facto coupling with other services via mandatory to-be-used CST canonical model: 'in SO, I have a lot of dependencies for my service already; why I have to have more that I even do not use?'
A 'service-oriented'-like approach to data access becomes popular and it usually states: if a service A can access some data and another service B needs this data too, the SOS should be in that the service B use the service A for its data rather than accessing the data directly in the data store. Well, I think this is one-time solution. Over the time, the service B's need in data may slightly change, not much, just for 10-20 per cent. In spite of significant overlap in data needs, the adoption of 10-20 per cent of differences may outlay 90-80 per cent of efforts, time and cost in the service maintenance. I think, it is too expensive to accept such risk of maintenance; business data is one of the most volatile element of the Business and I would prefer having dependencies in the more stable business functionality sphere than in the data sphere.
Let us suggest that we bind the business service with universal (in the organisation) data model and with related data store where the data is persisted. If we do such thing, we create two unnecessary extra dependencies - on the shared data model and on the data store. Both shared data model and data store are out of the service control (usually). You cannot own what you do not control, so, the only way for working with shared data model and data store is to put your relationships with their owners on the contractual basis.
Thus, a business service must be the owner of the service's business functionality and service results - Real World Effect. Dealing with shared data sources and data is out of the scope of service ownership. At the same time, a business service may and have to require certain data for processing. To be independent from external factors in this matter, the service has to define its own business data model and related data semantics. The compromise between individual service needs and corporate value of collected data is this: each business service may create its own data semantics and engage a level of data services that, in turn, maps business service's data view onto the corporate canonical data model. These are the data services that are responsible for the operations on the corporate data preserving the corporate policy of Master Data, which may be implemented in this or that way but transparently to the business services.
Leave a comment