Home 
Category Based List SOA / SOE Breaking Stereotype: Collaboration vs. Process
Category Based List SOA / SOE Breaking Stereotype: Collaboration vs. Process
Infotainment
The McKinsey Quarterly
|
 It is an emerging understanding that Service Orientation is a solution for gaining maximum efficiency in the market through collaboration between Business and Technology.
The article describes how traditional process-oriented organisation of business and technology may be reviewed as service-oriented organisation, why this is possible and what results may be gained from this.
Coupling service-oriented (SO) architecture with business processes (BP) becomes a common place in nowadays. My search in Google for such combination has returned ‘about 2,080,000’ results. Besides tram-words about SOA goes with BPM, what service orientation we can find in a business process? I can identify two major categories of the service use with regard to a process: a)services may be used as entities providing for functionality of the process’ actions b)a process itself may be viewed as a service, which delivers specific business results. In this context, I consider both business and technical services and processes. The category a) is the commonly understood and used in IT. In Business, the process’ actions are not usually recognised as services but this is the matter of habits. The use of services in the category b) is much less traditional in the IT architecture. This may be odd but it is the fact that the category b) appears more service-oriented than another one. Indeed, business service defines what functionality and final result it provides and, sometimes, who and why has to perform it. We can easily abstract a process via its inputs and outcomes known as Real World Effect (RWE). For the outside consumer, service and process appear identical if they have the same inputs and RWE. Therefore, why would not we treat service and process in the same way? Talking about services, we usually outline that service orientation is the most effective when used for forming different service combinations. We even have an SO Principle of Service Composability, which, in turn, leads to the concept of service collaboration. That is, we are saying that the composition of services that collectively contribute to the solution of given business problem may be viewed as the service collaboration constructed for solving this business problem. At the next level of abstraction, we can represent service collaboration as a new business service. Thus, a process, as a service, and collaboration, as a service, may be positioned at the sale level. It is interestingly to note that service collaboration does not necessary mean direct interactions between services. The service collaboration may exist in the sphere of interpretation of the collective service RWE when individual services do not ‘know’ about their participation in this or that collaboration. This kind of service collaboration may be implemented via service orchestration. Another type of service collaboration is known as service choreography. In choreography, each participant has to ‘know’ a) about all other services it has to deal with, b) how to obtain the decision about its own next activity, and c) how to perform this next activity/step, i.e. what messages have to be sent to and received from particular collaboration participant. Described knowledge is collaboration specific. That is, for each new composition, the service has to be updated with information about new contacts and their orders. This specific obviously demonstrates the fundamental difference between orchestration- and choreography-type of service collaborations. We can understand previous statement by saying that service collaboration is nothing more than a managed process, or self-managing process, or the mixture of them. Well, if this were that simple, service orientation would, probably, adopt process management terminology. Why this has not happened? Why we still distinguish between ‘process’ and ‘service collaboration’? The stereotype of thinking about a process points onto business or management activities. A process associates with instructions of ‘how’ to do something while a service is more about conditions, functionality and final result, i.e. it is about ‘what’, ‘why’ and, sometimes, ‘who’. In a contrast, service collaboration appears as the answer to the questions ‘what’ and ‘how’, i.e. what is the business goal of the collaboration, what entities collaborate and how they do it. If we substitute collaborating entities by the functionality they provide, the collaboration becomes exceptionally similar to the process. In the latter, the action implementation is not important whilst the actions provide for the functionality and results needed in the process. The last ‘process’ specific element – business rules that define what the next step has to be or what the next action has to perform – may be easily externalised and delegated to the rule engines. The latter may be represented by another type of services invoked on demand. Thus, I suggest that any business or technical implementation of a process may be constructed using services in the service collaborations (Figure 1). If the actions in a set of business operational activities (aka ‘business process’) cannot be represented as business services because they are not that significant to be identified as business services, I think that this set of business operational activities may not be called a business process. Such business operational activities are just tactical (temporary) manual implementations of existing business functionality and are the first candidates for the automation. 
Figure 1. Business process is the implementation of a business service Why I am trying to reconstruct process with services? What is wrong in working with the processes? To answer to this question, let me describe the following line of logic. The essence of any process is ‘how’ we do some things or ‘how’ we are reaching particular result. When we construct a process, we use available resources and prescribe certain activities to the processes participants. The definition of concrete process is independent from the surrounding environment if it does not prevent required activities to be performed. Elevating the view on the process, we can notice that the process is isolated from the environment and, respectively, from other processes. The notion of process is about ordered activities and rules that define the order. What the process is for and why it might require changes is totally out of the scope of the process. The less external influences accepted, the more the process stable. In the stable environment, the process provides its maximum value. However, if environment changes frequently and fast, the process-oriented structure is in troubles. This is why it is so difficult to manage process modifications, especially when we have several isolated processes and, according to the process concept, we have to minimise inter-process dependencies to achieve stability in the modified processes. I am risking harming somebody but I associate process-oriented environment with increased level of isolation, concentration on the internal steps, and ignorance to the collective goals or purposes of those steps. Process-oriented business structure tends to live on its own, preserves its own needs and, eventually, disconnects from the goal and objectives of the hosting organisation. When external environment demands massive changes, the process-oriented business structure decreases flexibility of the organisation and downgrades its efficiency. In a contrast, when we deal with services and service collaborations, the collaboration emphasises the goal and reason of activities (‘what’ and ‘why’). The way of reaching the goal, the internal organisation of the service collaboration, is seemed as a derivative of the goal; this organisation status is temporal by definition and ready for frequent and significant changes. The mindset of service collaboration is much more dynamic than the process-oriented one while the collaboration and process can use similar activities and resolve the same business task. If we look for business services and business processes in the business structure of an organisation, the picture would remind us a ‘Napoleon’ (napolitain[Fr.]) torte (Figure 2): the top layer of C-executives talks business services, functions and features; middle and low level manages concentrate on the business service implementation, i.e. on the processes; the presentation layer of technology deals with processes as well (in the form of user journeys); the middle layer of technical resources concerns of the business logic and becomes function- and service- oriented again; the resource layer plays the role of a supplier to the service-aimed middle layer. 
Figure 2. ‘Napoleon’ torte: service-process-process-service (image from Wikipedia) Actually, the service-orientation at the top of the business structure does not disappear in the middle but becomes shadowed by the implementation problems. All ‘business processes,’ working in the business operations, exist in the boundaries of pre-defined business services, functions and features. However, in some cases, business operational personnel do not know that business functionality they implement in their daily work, how and why their activities relate to the activities in other processes. If IT analysts and architects learn the business needs from the business operational personnel, the IT creates a view on Business as on a process-oriented structure. This leads to the cloning of inflexibility in the technical solutions reflecting inflexibility of the process-oriented structure. Now, imagine an organisation in the current tough market or in the process of extending into new market. In both cases the intensity of external changes requires adequate reactions inside the company, i.e. flexibility in the change adoption. In both cases, the company which can modify its structure quickly and effectively would get concrete market advantage: “Enterprises will begin competing with one another, not just on the products … but also on their business models. Enterprises that can rapidly configure new business models based on changing market dynamics will have a distinct advantage over enterprises lacking the … ability to alter business models on the fly”[Tony Murphy, author of “Achieving Business Value From Technology”]. This means that service-oriented approach to the organisation structure and to the produced products is more, if not much more, suitable for changing environment than process-oriented one from the business and technical perspectives. Getting back to the service-based vs. process-based implementation of the sequential business tasks, I have to admit that a single-sided technical realisation of service-oriented model is unrealistic. If Business, which defines requirements to IT, is purely process-oriented, it will not recognise and utilise service capabilities offered by IT; the nomenclature of business requirements will degrade usability of technical business services asking for operational enhancements only. If IT architects and management are able to articulate benefits of service-oriented organisation to the high level business management and facilitate revision of the low level business operational processes, this may result in the retirement of many of those processes and in significant improvement of the organisation flexibility, i.e. this may result in the increasing efficiency and competing abilities of the organisation. As I mentioned at the beginning of the article, service-oriented environment is fully capable of replacing process-oriented structures and solutions using services and structure of service collaborations. Service-oriented environment, implemented throughout the organisation, starting in the Business and following in IT, leads to the Service-Oriented Enterprise that is the advanced model for business operations in fast changing markets. About the author: Dr. Michael Poulin works as an enterprise-level solution architect in the financial industry in the UK. He started to work in service- oriented environment with Java and CORBA in 1996, and moved from pure technological world of Novell and IBM into the financial world in 1999. Since that time he worked as a Service Architect in the IT departments of Deutsche Bank, JP Morgan, and Fidelity Investments. He authored several articles on different aspects of architecture and design - from security to SOA. He holds architect certification in Java, TOGAF, and SOA. In 2001, he was included into the catalogue of International HWO S HWO of Information Technology (IWW Historical Society). Since 2007, he works as a Member of the OASIS SOA Reference Model TC, RA sub-TC, and co- authored the first Public Review Daft of the OASIS Reference Architecture for SOA.
|