IT BizOps

Insights

Introduction

Scoping the business and technical context
BPO (Business Process Outsourcing) companies are forced increasingly to use IT technology as a key enabling factor for their business proposition. To such companies one of the most relevant technologies is BPM (Business Process Management) platforms, given that competitive pressures force them to automatize their processes to a considerable extent.

However, more often, such companies also need to accommodate an increasing number of customer specific “variations” whilst, at the same time, they still need to aggregate the common aspects of the various business processes outsourced to them by their customers.

Furthermore, each time a customer (usually another company) asks to introduce new specific features in their outsourced business processes, they expect a short, aggressive time-to-market and competitive project costs from their BPO partner.

Time and cost pressure, but more importantly a lack of a coherent architecture with well defined and proved patterns, invariably leads toward “ad-hoc” solutions.

Such repeated “ad-hoc” solutions, over time invariably result in an increasingly difficult to maintain a “spaghetti” architecture. The latter in turn produces ever longer time-to-market, increasing operational costs, decreased IT reliability, etc.

It also produces the rapid obsolescence of their BPM platforms of choice. This typically happens also on the back of a disillusion process often started by its business stakeholders.

The reason is simple: The large investment made years before to select and implement the ‘then’ new BPM platform has not yielded the business value hoped for. So, the now aged BPM platform (sometimes more than one) is increasingly under question and the search for a better technical alternative is started again with the aim of solving issues that lie elsewhere. Indeed, they often derive primarily from the lack of a clear and relevant architecture.

So, to sum up, the architectural problem that needs to be solved is twofold:

Can business processes variations be thought of as Lego blocks?

Let us first better scope the key problem of designing a coherent set of variation mechanisms able to flexibly implement customer-specific business processes whilst avoiding an explosion of complexity.

An inspiring “30,000-foot vision” to achieve all that leverages the concept of a self-contained business process, sometimes called ‘smart process’. A quite evocative name indeed!

The implied objective of such vision is that end-to-end business processes together with their variation mechanisms can be quickly realized (and subsequently changed) by assembling a library of pre-existing ‘smart process,’ just like assembling together a number of different LEGO pieces.

As it is the case for every high-level vision, the challenge is how to translate it into meaningful technical problems accompanied by accurate enough definitions to make them solvable.

(By the way: the only way to identify suitable technical solutions is to properly scope the technical problems that needs be solved! This obvious truth is invariably overlooked.)

Below is how I proposing to translate the above business challenges into more concrete set of technical scoping questions:

The purpose of this paper is to provide a conceptual definition of a ‘smart process’ by using the terminology of the BPM discipline, and also to indicate a viable approach that can be adopted by a BPO company to successfully implement them whilst modernize their current legacy platform.

The organization of the remaining part of this article is as follows:

What is a meaningful definition of a smart process?

Before such definition can be provided it is important to contextualize the concept within a relevant reference architecture model.

To this purpose, the picture below shows the reference model of the Workflow Management Coalition (WfMC) that describes the major components and interfaces within a workflow architecture.

Figure 1 Workflow Reference Model – Components and Interfaces

At this stage, and for our purpose, it is important to focus on the core module of any workflow systems, indicated in the diagram as workflow enactment service. It provides the run-time environment that controls the execution of the workflow.

The key point to highlight is that, for technical or managerial reasons the workflow enactment service may use multiple workflow engines. The implication is obvious: A single workflow engine can only handle specific subparts of the end-to-end business workflow.

That means: a single end-to-end business process, single from a business and customer point of view, can well be implemented via a number of workflow subparts that invoke each other at the relevant moment of their executions.

Each of these parts can be executed within a different workflow engine. In turns, such workflow engines can be hosted in a single platform, e.g., all of them hosted in a single platform together, or hosted in different platforms but still be properly coordinated to appear a single business process from its business users’ point of view.

To sum up: a single business process can be executed in a single platform, e.g., a single workflow enactment service (centralized workflow pattern) or in different platforms each provided by a different vendor (distributed workflow pattern).

Further to that it is important to note that a single end-to-end business process could well be modelled by using a number of independent smaller workflow templates, irrespectively from where they are going to be executed (e.g., which workflow engine or enactment service).

As illustrated by figure 1, a workflow template (the definition of the business processes or a specific subpart of it) is created by using one of the available (in the platform of choice) Process Definition Tools.

Below is a pictorial example of how a hypothetical coordinating workflow template (left side of the picture), can make use of a specialized workflow template (right side of the picture) to implement, in a self-contained way, a customer specific variation within a common and shared business process. Indeed, task A3 (left side of the picture) is the one used by the common business process. However, under specific conditions, for instance, for a specific country or customer, task A3 will make the automatic decision whether or not to invoke the workflow on the right.

Figure 2

For example, let us suppose that tasks A3 be a human task instead. In such case, such decision can be left to the judgement of the human operator who is the assignee of task A3.

The reference architecture recommends that, as one of the possible mechanisms to pass work items between heterogenous workflow enactment services is by the WAPI interface, envisaged as a common set of API calls and related interchange formats.

In our earlier example, which means: Task A3 should be able to invoke an API that will instantiate (e.g., run) the customer specific business process template (right side of the picture). The controlling template (left side of the picture) does not need to be aware of that. From its point of view, it is simply running task A3 and waiting for it to be completed.

Equally, the specialized workflow does not need to know it is run from within a controlling template. Once finished it will return the control to whoever process it originally spawned it.

Finally, it is also via WAPI-Interface 2 that a workflow enactment service is supposed to communicate with its client applications to assure maximum interoperability, as illustrated by figure 3. That implies a decoupling between workflow engines and UI interfaces.

Figure 3 Reference Model – Interface 2 details

And now back to the definition of a smart process

So, a smart process can simply be defined as a ‘smaller’ self-contained workflow template designed with a specific business focus (for instance to implement a customer-specific variation), that can be instantiated via an API call.

Once instantiated, it will run without the need of being aware of the controlling process that has invoked such API.

That is a good definition of a smart process because:

So, the two properties above clearly assure the required degree of self-containment both from other pieces of business processes and the related UIs, which thing is at the core of the smart process vision.

What are the selection criteria of ‘smart processes’ realization platform?

Now that a rigorous definition of ‘smart process’ has been provided from a technical/architectural point of view, we would need to ask ourselves a key question from a delivery point of view. A question that would need, eventually, be addressed given its paramount important from the business value realization point of view.

We should ask ourselves how to select a suitable realization platform where we could implement a ‘smart process-based architecture.’

(Later we will clarify how to harness the same platform to phase out the existing legacy BPMs, bit by bit, whilst avoiding the too dangerous big bang approach.)

Below, some key criteria are listed, as a title of example, as guiding principles for selecting a suitable platform. It needs to provide the followings:

Recommended approach to modernize existing legacy BMP platforms

In the previous sections we have stated that a ‘smart processes-based architecture’ is the suitable architecture construct to implement customer specific variations and we have explained why and how.

However, such architecture construct can equally be used to modernize existing legacy platforms in a step-by-step approach, avoiding risky big-bang approaches. And this is remarkably relevant for many BPO companies.

We have already provided a precise definition of a smart processes within the context of the BPM reference architecture. Further, we have provided some examples of the way they can be orchestrated within the umbrella of a controlling workflow.

However, it is important to stress that a successful modernization programme also depends heavily on the quality and accuracy by which the end-to-end business process is modelled in terms of its smaller constituency components and the precise nature of the customer specific variations.

All that requires first the elaboration of a robust business requirement conceptual model, i.e., a set of abstract concepts and the rules (both in terms of subprocesses and application data) that preside over their interplay.

That phase of the modernization programme is of paramount importance and needs be carefully planned in terms of its scope and level of complexity to be tackled. Without that any specific architecture patterns and solution is at risk of failing.

The scope and complexity to be analyzed at the outset should be enough to be representative of the final state but not too big to become cumbersome.

Having said that, from a mere architecture principles and patterns point of view, it is easy to imagine what is the recommended high-level strategy.

The existing legacy systems will initially stay and carry on as mere orchestration mechanisms. The implication is that no more modifications should be allowed within them to implement variations.

Meanwhile, little by little, they will be carved out, as soon as new specialized pieces of processes will be added in the new headless workflow platform, accordingly with the scheme illustrated in figure 4.

Such new specialized ‘chunks of processes’ (or smart processes) can be added both to realize new customer specific variations (as in the left side of the picture below) or as a mean to refactor existing legacy pieces of business processes that used to run in the legacy BPM (as in the right side of the picture below).

Figure 4: A pictorial representation of the legacy BPM modernization approach

The highlighted approach implies that, as time runs by, less and less business processes will be hosted in the legacy platforms since all new variations will have been implemented in the new platform whilst, at the same time, some legacy processes will be migrated bit-by-bit.

This is an approach that can also be seen as carving out business processes from legacy platforms in small chunks at a time.

Eventually the legacy BPM systems are left only with empty shells. Once this happens, they can be safely phased out to complete the modernization programme.

Conclusion

This article has delved into an important business and technical problem particularly relevant for BPO companies.

It has illustrated in detail how to address the challenge of being able to provide customer’s specific services whilst maintaining overall complexity at its lowest level. And it has shown it within the context of a BPM reference architecture.

References