BPPM2 - A bridge too far
The Xpragmatic View #50
September 2002
by Marc Buyens, Xpragma
Download as PDF-file 
BPPM (Business Process Performance Management / Measurement / Monitoring) is gradually becoming another hot item. To a large extent, BPPM technology is a very natural evolution or extension of the initial wave of EAI solutions and, later on, of the various BPM offerings. Very decent BPPM functionality is already available today. However, organisations have discovered the business value of such capabilities and are asking for more. Unfortunately, this more might be a little bit too difficult to get - today...
Over the past weeks, I saw some (renewed) interest in what is commonly named BPPM (Business Process Performance Management / Measurement / Monitoring). As already said, BPPM is a further evolution of the existing EAI and BPM solutions. So, what's so special about it?
Traditional EAI
As the name suggests, BPPM has something to do with the management or the monitoring of the "performance" of business processes. Traditional EAI products were not really instrumented to deliver this type of capability. Essentially, EAI products focused on moving data in a reliable and an efficient way between different application environments, a task that was already complex enough. Monitoring and control were merely limited to the supervision of some key components of the environment. More in-depth problem analysis was often not available or you had to use specialised add-on products.
Nevertheless, from the beginning some vendors, not to name Vitria Technology, had the vision that something "more" was needed. They shared this view that the final ambition of EAI was not about integrating various environments, but about running a business in a better way. Still, even for the Vitria solutions, the BPPM capabilities were rather limited.
With the growing acceptance of EAI, also came the need for a more business process-focused approach. As a result, newer versions of the products gradually included some level of process design capability, together with improved monitoring capability.
Still, reality is that the reach of most of this functionality is limited to the narrow world of the integration-specific pieces of the business processes. Consequently, this does not give you a real view on the complete business process. In addition, most of this functionality is not really focusing on real BPPM capability, but merely tries to reduce the complexity of the integration task, by providing higher-level interfacing tools that allow for the configuration of adapters, the sequencing and distribution of events, etc.
BPM: more of the same
With BPM (Business Process Management) things are not really different. The reach of the monitoring, measurement and control capabilities is essentially limited to (those parts of) the business processes that are managed by the BPM solution. Of course, this level of control and visibility is here available at a somewhat "higher" (read: more business oriented) level.
Of course, all of this is valuable information and we have to encourage vendors to continue extending their offering with new and improved capabilities. Recent examples of this can be found in the latest release of Lombardi Software's TeamWorks solution that includes new BPPM-style functionality such as improved problem solving and the delivery of status information to executive scoreboards. Another example of this trend is the recent acquisition of PRAJA, a developer of business activity monitoring (BAM) software, by Tibco.
The promise of BPPM
However, BPPM is something more. "Real" BPPM is something that you should be able to implement for whatever part of your business (processes), independently of the requirement that this specific part already makes use of a certain degree of EAI or BPM capability.
The real promise of BPPM is its real-time character. We already know for years various types of supervisory systems, scorecards, etc. However, most of these do rely upon the (delayed) processing of collected information. At best, they provide a "near-time" view on the business and action is typically decoupled from the detection of a specific event.
With BPPM, this might be different. Most EAI and BPM technologies are essentially event-driven and do act upon (mostly) real-time information. Managers are hoping that this same real-time behaviour can be extended to the highest level of business management.
Therefore, the current offerings are certainly not an endpoint. Making you see that this type of manageability is possible for part of your business makes you want it for the whole of your business. Consequently, the current offering can only be seen as an intermediate phase. It represents what we might call "BPPM Level 1" : the management, control and supervision of that piece of the business that is already integrated or automated by a specific EAI or BPM solution. Nice to have, better than we hoped for, but not enough...
BPPM Level 2 (BPPM2)
As we can expect, the mission statement of BPPM2 is to provide real-time end-to-end management (= planning, design, implementation, execution and control) of all business processes of the extended enterprise. Thereby, the focus is clearly not on the technical management of the various components, but on the management of the real business activity.
As above paragraph suggests, this will have to be complemented with other types of system, application, EAI or BPM management capabilities, but I would insist on having them separated. I do know that vendors of leading management suites will argue that BPPM2 is the natural evolution of their product, but I do prefer two clearly separated management environments.
The reason for this is very fundamental. In real world, there is no such thing as 100% flexibility. You cannot allow questioning every part of your organisation whenever the need for change occurs. Therefore, if organisations want to become "agile", this will mandate that they extend their "architectural" capabilities. What I mean by this is : that part of the organisation, of the procedures, of the processes, of the IT-infrastructure, etc. that is managed according to long-term, strategic directives. Consequently, this part of the business environment is NOT being questioned every 5 minutes.
This does not at all mean that this architectural part is rigid. What is means is that the guidelines for change have been predefined according to long-term strategic goals and ambitions. As a result, this change can occur independently of the more "tactical" changes made by the company.
The "agile" part of the business environment builds upon the capabilities of the architecture but is guided by a completely different set of management principles. Given this completely different managerial paradigm, it is wise to keep the tools that assist in the management of these environments separated. Mixing the two into a single solution will complicate things, since certain events will have to be interpreted as error conditions by the architectural part, while they can represent business opportunities for the agile part.
But let us return to our BPPM Level 2 discussion.
A basic BPPM2 architecture
I suppose that it will be clear for everyone that building a BPPM2 solution is not a trivial task. Yet, the basic principles are rather straightforward.
In essence, you want to give to business people an environment that allows them to plan, design, implement, execute and control their business.
The easiest piece of this challenge is the interface. What you expect to have here is a graphical environment that allows you to build business logic, define rules, define exceptions, etc. This is very similar to what is done in several existing BPM solutions, so this should not be too difficult to deploy.
Once the business people have defined their business logic, rules and exceptions, you need an execution environment. Although the definition of the appropriate logic is very BPM-style, by necessity, the execution environment will have to be very EAI-style. I mean by that, it has to be capable of handling huge amounts of real-time events in a completely distributed environment. Again, technology is available that can do the job.
The real tricky stuff starts when we try to define what "objects" you might want to include (can include) in such business logic. Here we are facing the immediate reality that this goes way beyond the existing EAI- or BPM-enabled environments. Both EAI and BPM can of course provide mechanisms allowing us to get access to specific environments, but typically, the current implementations will only cover (a small part) part of the business environment. In addition, in larger enterprises you can expect to find several types of these EAI and BPM tools.
Therefore, simply getting access to the basic information already represents a huge integration exercise, whereby you will have to carefully balance effort (the investment that is needed to get access to a specific object) and reward (the business value that it represents). Personally, I would suggest translating such "balance" into a number of clear guidelines for the infrastructure guys for gradually increasing the number of business objects that are available for the "agile" business management.
Do take into account that "access to specific objects" can range from simple inquiries up to complex transactional processing. Objects might even represent EAI- or BPM-configuration tasks. Few of this is available today in the form of standard adapters in the existing EAI and BPM tools. Needless to say that what we discuss here can grow to an effort of unprecedented complexity.
Finally, business people will want to define business rules that are based upon aggregate information, so you will have to create some kind of message or event store that keeps track of every piece of information that can be necessary to evaluate any business rule that has been defined.
Waiting for Godot
The above are merely some of the key requirements. Additionally, you will need a fair amount of operational add-ons, reporting capabilities, security... You will have to address the extremely complex challenge of testing, of change management and many more. To put it in simple terms: this is not the thing you do on a Friday afternoon.
Today, not a single or even not a group of technology vendors or system integrators is capable of addressing this complexity for an average-size company. Therefore, the only approach can be to address this in a more pragmatic and gradual way by acquiring or extending the key competences that are needed for the gradual development of such management infrastructure.
Even then, the technological complexity only represents the smaller part of the challenge. In order to transform such management platform into real business value, the organisation has to be capable of using it in the appropriate way. What business rules do represent business value or will detect opportunity? What exceptions have to be defined? What actions have to be taken at what moment? Most of these do require a level of business management insight that is not always readily available. In addition, is the organisation capable of deploying the organisational change that is required in order to grasp the opportunity presented by the BPPM2 tool?
You know the answers. Therefore, it will take a while before we will see the first truly BBPM2-capable implementations. For once, business and technology are in sync: both are not yet ready for the job. However, organisations have to view this in a long-term perspective. None of this will happen overnight, but it will go faster for the prepared one.
Categories: Business Process Management (BPM)
RSS feed: http://www.xpragma.com/english/rss/xpven.xml
