Recently I re-read the visionary article "SOA's Business Value" written by Neil Ward-Dutton, Research Director, Macehiter Ward-Dutton, back in 2006. Explaining the real value of SOA, Neil said: "You must focus on the problem domain in which SOA can yield real benefit - and that is in the area where business meets IT. This domain is increasingly being modelled as sets of clearly defined business processes, which are partly automated through the use of integrated business application software functions. The ideal "service domain" where you focus your SOA efforts should not extend, initially at least, too far down into business functionality that is already implemented in application software... It should also focus in areas where IT flexibility, rather than cost and efficiency, are paramount. That's likely to be in support of business activities and process that differentiate the business". This was very well described approach to SOA, especially if we consider the "business activities and process" in business, not technical, sense as the areas of business functionalities rather than physical actions and sequential operations, i.e. processes. However, the time has passed and initial approach requires some adjustments.
I've looked for them into IBM SOMA recommendations on decomposing business environment for the purpose of technical implementation along the service-oriented architecture. Unfortunately, the recommendations still see into the business not further than operational services. That is, looking into the business bottom-up doesn't help much in understanding the reasons why the there particular process are in place, what business tasks they address and whether these task are actual and in line with the business strategic line of thinking. In the facts changing business environment, automating given state of the business operations can easily lead to the waist of money, resources and time. To support business advantage in such environment, IT must know what business is doing, what it thinks to do next and why. There may be many opportunities to create real business value for the organisation by replacing existing business process in full with automated solutions (if IT know what and why is needed).
I also looked into papers from Oracle and Software AG on this topic and found nothing more than improvements of business process efficiency via infrastructure enhancement and business process management (BPM) methodology. While BPM significantly helps in understanding of abstraction of a business process, so valuable to SOA, it does not explain the reasons for particular process and inter-process relationships; the process is still considered as a value-adding stand-alone entity. This simplifies decomposition of Business Operations for the purpose of automation but also carries a significant risk of missing vital information on the process position and role in the overall business activity picture (which makes service orientation almost useless). Thus, in the absence of alternatives at this moment, let me explain my approach to the decomposition of Business Operations for the purpose of SOA.
I think that a view on the business functional structure from the IT perspective as at the structure of processes that might be automated using BPM tools and that utilise technical services (of business service type) to implement the process' actions promotes dangerous oversimplification of the task. This is resulting in isolated two-layered structure: automated business process engages technical services. The reality is much more complex.
First, a technical service should not necessary be fully automated; the examples are to name a few: a workflow, or an e-mail based interactions, or a message-based interactions triggered by manual inputs into the systems. This means that it is absolutely perfect having a service that invokes a process. Following this line of logic, any process may be encapsulated by a service of the hire level (opposite is incorrect).The view of process and sub-process as the business world organising elements is nothing more than semantics because 1) any process may become a sub-process; 2) a process does not need any sub-process. The process as an ordered sequence of activities needs only the results of these activities regardless their implementation; they may be the sub-process, or the services, or anything else that results in the required Real World Effect.
If we move up along the structure of business processes/sub-processes, we will reach the business organisational level where no or very few processes exist - it is the C-executive level, which operates with the business tasks and business functional services. If we move down along the structure of business processes/sub-processes, at the very bottom, we will find business activities that do not encompass any lower level processes; these activities are the lowest level business services that at given moment do not require any further business decomposition. Overall, the structure of business processes/sub-processes appears imbedded into the structure of business services in technical terminology. This, actually, explains the essence of the Business SOA to IT Architects.
Based on all said, the decomposition of Business Operations for SOA starts with identifying the lowers level of business services, i.e. formalised business activities that realise stand-alone business function or feature that should not be divided into the smaller business activities (they do not make sense from the business perspectives). This set of the lowest level business services is the foundation for entire business service structure of the organisation. I am talking about service structure instead of the process structure because there is no principle difference for a business activity to serve internal or external consumer, e.g. process actions serve the process while the process itself can be an activity in another process, and so on.
In the next step, we need to identify the business services of the higher level and related business rules used to compose the lowers level of business services into units with cohesive functionality. In SOA, such units are formed by the means of orchestration, which is the same thing as process business logic. An orchestration as well as a process is the answer to the question HOW the task is realised. The service implemented via orchestration is the answer to the questions WHAT the task is and WHO performs it and for WHOM.
Then the steps repeat up to the level where the business considers potential help from the IT. As a result, the structure of isolated processes transforms into the structure of targeted inter-related services. The major benefit of this view is the service-oriented mind that leads to the vision of business capabilities constructed by composing self-contained business services into business collaborations. At the service level of abstraction, it is much easier to observe and discover what may be the task for automation and re-composition. From the moment when the business and IT start to share the same understanding of the business service structure, the opportunity of agility materialises. Having service-based business view, IT gains common grounds with business and finally reaches the point where it can demonstrate its business value and really contribute to the business values of its organisation.
Leave a comment