As outlined in Part III of the series, the vision of BPM/SOA convergence has a flavour of a ‘holy grail’ of application engineering – it promises to keep the two worlds (business and IT) separate yet united by the shared concept of reusable ‘service’ playing the role of the bridge between them (see
Part II ). Crusaders with either emblem claim readiness to share their horses on the way forward if not declaring outright victory (especially if they are in the vendor’s regiment).
The more realistically minded come up with lists of requirements needed for the vision to materialise. Conspiracy protagonists allege ‘the other side’ of having a hidden agenda (probably of hijacking their own hidden agenda). Sceptics point out that they have seen it all before.
Bizarre stories begin to emerge and one of them is especially relevant to our topic: at a recent OASIS symposium a panel that included distinguished architects working on standards for SOA was unable to produce a final word on what SOA is (see article). ‘Lack of clarity in defining SOA makes it difficult for software architects to sell it to the business side of their organizations’, said one of the senior panelists.
What is a root cause of this fundamental problem (of defining SOA) that undercuts successful attempts to bridge the business-IT gap? In my opinion, the answer lies in the very concept that SOA is based on – that of Service.
Closer examination of Fig. 1 in
Part II showing Service as a transformation (convergence) enabler imbedded into Business Activity reveals that it’s a gross oversimplification of the reality: in fact, the business and IT definitions of Service are divided by several layers of abstraction – the ‘holy grail’ of BPM/SOA convergence simply does not exist in the form presented on the architecture charts and without it crossing the waters separating both sides is a treacherous trip indeed. The question emerging from this discussion is: how should the methodology ‘bridge’ spanning BPM and SOA be designed?
Experience from first SOA projects strongly suggests that none of the existing methodologies, even when enhanced with some new SOA-like concepts, is on its own sufficient to support BPM/SOA convergence paradigm (see article). The simplest approach to start with would be to find a definition of Service that can be used from both business and IT perspectives and serve as a cornerstone of a common language used by both parties. As mentioned earlier the major problem with this approach is that business defines Service as a high level workflow of activities that provides business value to its customer(s), while IT definition is bound by system operation level which is way to granular from the business perspective. Providing a definition of Service that is vague enough to be interpreted as any of the two hardly resolves the problem – some kind of transformation method is needed to match them.
Two ways of doing that have been proposed:
Top-down approach starts from the business side and uses process models to arrive at service specifications required from IT systems to support them. The opposite, bottom-up approach tries to combine IT/legacy assets into something at the higher granularity level that can be used as a service by the business. Both have one thing in common – they are guaranteed to miss the target in almost any case. In the first scenario, by the time business arrives at the level of services’ specification, without taking into account practical reality and complexity of IT, most of the services identified won’t be as implement-able as specified. In the same manner, the bottom-up approach ignores business context and is likely to result in a plethora of ‘reusable’ (from IT perspective) but useless (for business) services.
Most importantly though, both of these approaches lack structure and discipline and don’t even begin to address the SOA lifecycle. Service-oriented development has to be supported by a methodology that encompasses best practices in service identification, specification, understanding and reuse. In particular, service-oriented methodology (let’s call it SOM for the purpose of this text) should recognize different levels at which service can be defined, provide development standards for each of them and technics for making a transition from one level to the next. Based on these principles, ‘meet-in-the-middle’, iterative SOM can be formally defined. The word ‘iterative’ can not be overstated as it’s highly unlikely the service-oriented development process will be completed with a single go. By its interdisciplinary nature SOM will need to combine elements of existing methods from BPM, Object Oriented Analysis and Design and Enterprise Architecture with several new disciplines required for the purpose. Agile modelling technics can prove highly useful in creating this type of methodology.
At the current stage, we are only recognising the need and making first steps in this direction. However, the first pillars of the design spanning the business-IT divide start to emerge on a drawing board in a form of constructs based on decomposing the concept of Service into several levels, corresponding to layers of SOA itself (see Fig. 3; arrows denotes invocation, diamonds - aggregation):
1. Operation level: most basic level of service consisting of two sub-types: elementary CRUD operations which simply perform a database transaction and more complex methods (such as OO class method) that in a course of their execution can invoke other methods and elementary operations. Both sub-types have pre-defined operation signature specifying input attributes and result. For example CreateClient(Name,ID)can be defined as an elementary operation that creates client with a name provided as a value of its input attribute and returns system generated, unique client ID, while CheckClientStatus(ID, Result)might be a method returning its Result value (e.g. ‘Active’) depending on values of other attributes (e.g. such as LastOrderDate) which it needs to get and interpret using other elementary operations and methods.
From an SOM perspective, an operation level is the identification level of the services to be harvested which belongs to IT domain.
2. Component level: service component represents logical grouping of operations. For example, Immigration Department’s FindClient service component can have separate operations to find client based on name, travel document, previous visa number etc.
Depending on business need, service component can contain both types of operation level services (already defined at level 1): elementary operations (if directly required by the business) and methods. New services combining/invoking those already defined at both levels are added at this level and operations of level 1 are refined to support full realization of component services. Services of one component can invoke services of another but the final design should adhere to loose coupling principle.
Components are responsible for maintenance and quality of services they offer to the business layer. Component level services should be able to collectively fulfil organization’s business processes and be aligned with business goals.
Figure 3. Bridging business-IT gap: Service decomposition.
Component level specifies not only standard syntax of the services, but provides templates and other documentation (such as glossary, guidelines etc.) to describe service semantics.
From SOM perspective, service component is the aggregation and categorisation ‘meet-in-the-middle’ level of services. Services exposed to the business at component level are composite constructs i.e. their specification can be interpreted from both business and IT perspectives. SOM should provide traceability technics and methods for transferring its member services in both directions (to operation and business level). The alignment of component level services with both operational and business level is a critical task in the process of BPM/SOA convergence and can take several iterations to complete.
3. Business level: business process represents a flow of activities performed to achieve a business goal - usually a specific business outcome. Examples of business processes are: Process Visa Application, Manage Client or Prepare Report. Definition and execution of business processes belong to BPM discipline. From SOA perspective, business processes typically include multiply service invocations. The selection and sequencing of these invocations is called service choreography. Business services are constructed as composites of services made available to the business by service components from level 2. Typically, a business service invokes a series of services from one or more components at level 2.
From the SOM perspective, business services belong to BPM domain and are constructed based on requested outcome rather than related functionality. Thus, the set of business services will be subtly different from the set of service components e.g. business level services can include services performed manually or external to the business in scope.
Three levels of Service decomposition depicted in Fig. 3 provide a conceptual roadmap on constructing SOM that can support BPM/SOA convergence. The separation of implementation (level 1), description (level 2) and binding (level 3) provides unprecedented flexibility in responsiveness to business change and opportunities of reuse of component services by various business compositions in the business process flows. More architectural layers could be added to the picture (see article) such as presentation layer extending the business side and systems layer underlying IT level but from methodology perspective the three layers presented in the article will play a key role in SOM. Once the key SOM practices and standards are established other important disciplines such as business rules analysis, project and change management, testing etc. can be added into the picture.
In this article, we have discussed BPM/SOA convergence in the context of bridging the gap between business and IT domains. We started from showing that the core of BPM/SOA approach to business-IT alignment is very similar to what have been proposed before (
Part II). We continued with short description of BPM and SOA architectures and potential benefits that can be achieved by combining BPM/SOA into agile business solution.
However, as emphasised in Part III at the current stage BPM/SOA convergence is just a vision that requires clear methodology support to deliver on its promise. No such methodology currently exists and early experience with SOA projects strongly suggests that this new methodology should be an interdisciplinary combination of existing methods with the concept of Service at its centre. As described above, the definition of Service should be sufficiently decomposed to allow for an innovative, ‘meet-in-the middle’ approach that bridges the business-IT gap, corresponds to architectural layers of SOA and clarifies the definition of Service itself as a composite concept that can be specified from both business and IT perspective in a coherent and traceable manner. The closer we get to achieve these objectives the less it will feel like walking on water while trying to cross business-IT divide.
About the Author
Dr Zygmunt Jackowski is a System Innovation Staff Member of DIMA (Department of Immigration and Multicultural Affairs) with several years of international experience in IT industry. He specializes in methodology and architecture disciplines as perceived from both business and IT perspectives. His research and publications include Extreme System Analysis, Agile Business Process Modelling and Enterprise Architecture. You can contact him at email@example.com.