Bridging the IT-Business Gap With BPM and SOA (Part III)

Are we through the rapids yet?
Focusing on the second issue posed in Part I, we question the novelty of BPM/SOA combination especially in regard to addressing the business-IT alignment problem. Let’s start from taking a look at each part of it. (Click here for Part II).



Looking at an architectural model of SOA, one can not help getting an impression that what they are looking at is a rearranged structure of architectural artifacts and solutions that have been around for some time already. Indeed, experts’ comments on the subject confirm that impression, one of them simply saying: “There's nothing truly new or revolutionary about SOA; we've been there, done that before.” This impression is not helped even with a newly added flavour of Web-services which are expected to drive SOA implementation to the mainstream. In fact, the main problem SOA is designed to address is the other kind of ‘web’ on the opposite side of its architectural model – that of disparate legacy systems developed with a plethora of competing technologies accessing equal diversity of incompatible databases – all that often done with a strategy line no longer than the nearest due date. To encapsulate this unwieldy reality into something as elegant and usable as service, which hides all the gory implementation details and is available to its external clients, is the remedy promoted by SOA.

On the other side, BPM has evolved from Business Process Modelling techniques which were rapidly developed in the 1990s (also known as Business Process Re-engineering, Business Process Improvement, Work-flow Modelling and the like), as means of visualising, analysing and improving business processes at various levels (high level organisational flows down to workflow level).

The two main problems of the BPR revolution were lack of in-built execution mechanisms and a conceptual/methodological inability to bridge the gap between business and IT domains. Because of the former BPR tools were long considered to be merely some kind of drawing aids and even today the most popular Business Process Modelling tool is MS Visio. The latter problem is even more of an eyesore as BPR takes pride in addressing so-called ‘silo phenomenon’ and replacing the organisational silo structure with horizontal end-to-end process model. In spite of that goal, BPR has been a kind of silo itself when juxtaposed with its IT counterpart in an organisation.

The execution problem has been effectively resolved with the advent of BPM technologies which, often with cooperation with business rules engines, allow for executing, monitoring and dynamic change of the flow and rules of running processes in an integrated environment. With such powerful capabilities, BPM has thrived without a firm understanding of SOA and can continue to do so. The same is true about SOA - one does not need BPM to build a composite application that makes use of SOA. Any development approach that can make a call to the SOA-derived services can be used and that’s how IT systems have been built so far.

However, the combination of SOA and BPM is more powerful than either alone: SOA exposes services, and BPM, which executes the process flow, consumes services. Used together, BPM and SOA enable tight alignment between business process design and its IT support layers while allowing the two (flow and service layers) exist independently. The service portfolio can be created and maintained independently and leveraged by BPM flow composition into new composite applications. This configuration provides greater than ever agility, and is a great motivator to develop BPM/SOA based solutions.

So does the combination of BPM and SOA solve our business-IT divide problem?
The reason I can’t answer with a big ‘Yes’ to this question is that at the current stage, BPM/SOA convergence is more of the vision rather than an existing solution. Even though creating such a vision is a crucial part to accomplish any mission, it is only a first step in a process and does not in itself guarantee a full success. Successful realization of the vision depends among others on accurate assessment of a current situation, identifying critical success factors and addressing the related risks, and developing relevant and realistic plan of realizing the vision so the success factors are met.

Lack of comprehensive organisation assessment in terms of its people, business and technology is the most common factor that changes even the best conceived vision into illusion. Assuming that the success factors with the problems that put them at risk are obvious and unambiguously understood by both business and IT counterparts and focusing on the BPM/SOA solution instead more often delivers bitter disappointment than state-of-the-art solution. Finally, expecting that people representing different architectural viewpoints (BPM and SOA) will just follow the shared vision lead by a team of ‘experts’ (often external to the organisation) is another common example of ‘visionary-illusionary’ rather than well-managed approach to reality.

Using the analogy from the title of this part of the article, we are only entering the rapids ahead, and don’t know exactly how the raft handled by a combined crew of business and IT teams (if they both agree to board at all!) will cope with the white waters ahead - more on that in the last part of the article.

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 zygmunt.jackowski@immi.gov.au.

More by Zygmunt Jackowski, PhD