Business Ecology Initiative & Service-Oriented Solution

The first and commonly known case where the SO principle of Service Separation of Concerns shows up is design of service granularity. Then, it becomes very important in the design of service interfaces. Finally, this principle plays significant role in the construction of aggregate or composite services.

If we take business functionality as the concern, we can get a tip from the business model on how separate the concerns. Business model defines business services, business functions, business features and business processes operating on business services, functions and features. A combination of mentioned entities makes a sense only if it represents cohesive business functionality. The entities may be split into smaller functional entities until those smaller entities make business sense, i.e. visible from and valuable for the business model.

For example, assume we have a business process of calculation of cost and at one point of the process the calculation results have to be passed to a party that validates them. In this process, the 'pass' is implemented as manual filling of a spreadsheet, which is mailed to validating team by internal mail. On the sender and receiver sides the spreadsheet is registered in books. If we make the spreadsheet available on the computer, e.g., in Excel, and will be able to attach it to the e-mail, do we change the process? No, we do not. If we create a programme/application that performs Excel functions in the user interface and wires calculation results to the validation application, do we change the process? No, we do not. The business process does not care how the calculation results pass from calculation point to the validation point; all related activities are not business activities but one or another form of implementation. This means, that we should not split our business process further and represent a business sub-process of data transmission between the point of calculation and the point of validation; there is no business process in such transmission and there is no a business services correspondingly.

It is interesting to note that the principle of Service Separation of Concerns works differently from the business and from the technical perspectives. Let us take a business function of generating a business report. This function has a few features such as: a) generate report only; b) generate report and notify all interested parties about this event; c) generate report and produce a hard copy (print); d) generate report and distribute it to the subscribers. Described is the business perspective. Technical perspective would be having a report generation service and independent notification, printing and distribution services. The latter three services can perform their tasks on reports, on commands and on any types of files. From the business perspective, only report generation service is meaningful; business is not interested how notification, printing and distribution are implemented whilst their QoS are acceptable.

This line of logic leads us to, at least, two consequences from the principle of Service Separation of Concerns:

1) business functionality that cohesively address one business task and can be reused as is should not be split further even if it contains more than one concern. For example, from business perspective, a report on a paper makes sense while a printing capability is pure technicality because the same report may be printed, written by hand, photographed, painted, etc., on the paper
2) technical functionality that supports one business task and can be reused as is for another task (i.e. being business subject independent) can be separated as a concern and implemented as related technical service.

Since flexibility of the business services directly depends on the flexibility of the supporting technical services, any extra dependencies in the technical services area affect business efficiency. Here is another line of arguments leading to the same conclusion: the concept of business continuity demands that all business functions have to be accessible and available when needed; if a business function depends on a technical service, which is a single point of failure, there should be another combination of business-technical services available that can bypass the failure if it occurs and perform the business task as expected. Thus, if a business service generates business reports, it has to be sure that the technical data service would provide for the data for the report in spite of any problems with the data store or network. Where the data service gets the data from (whilst the data is correct), whether the data stores are clustered and redundant or data service caches the data - all these are not the concerns of the report generating service, i.e. the report generating service has to be separated from the data service.

One more conclusion may be made based on principle of Service Separation of Concerns. The services that implement processes or compositions-aggregations include two types of serving entities: the working entities that provide their results for the composition and the managing entities that provide logical decisions of which working entity should work next. Both entities may be implemented as services that may engage other services, i.e. represent other compositions in turn. The SO principle of Service Related Autonomy states that ownership relations between the composite service and the services engaged into the composition are contractual, i.e. they follow the general rule of 'services that serve my service are not my services'. The same rule is applied to the relationship between the service consumer and the service. In other words, the service consumer should not know and does not want to know what services are engaged by the service facing the consumer. This means that the composite service is fully responsible (accountable) to the consumers for all offered functionality, which is irrelevant to who factually provides it - service itself or the engaged services.

At the same time, the principle of Service Separation of Concerns narrows the ownership of the composite service to it's own functionality (relationships with other services are contract-based). The combination of expanded accountability joined with narrowed ownership constitutes new operational concept that significantly distinguishes service-oriented environment from application-oriented environment. I am talking here about not only technical relationships but also about managerial, human relationships as well.

Working with services under separation of concerns principle creates unique operational conditions in both business and technology. The accent of these conditions is on service-ability rather than on delivery. That is, the delivered results are valued only if they serve the business needs. The principle of Service Separation of Concerns facilitates dedication to the collective results versus individual ones and defeats perfection in one area of the business service organisation at the expense of the other areas.