Tuesday, December 21, 2004

Introducing Process-driven Composite Applications

Composite applications. SOA. BPM. BPMS. Web services. If you're reading this blog (or at least if you come back again), then you probably already know something about these topics, and also know about how much confusion there is among all of these.

Well, sorry to say that I'm not going to try to clear all of that confusion up - at least not for now. However, I will try to enlighten one specific area of BPM systems - specifically in the area of information delivery as it pertains to end-to-end business processes.

Most people who discuss BPM focus on the obvious - modeling, analysis, execution, optimization. And of course these areas are fundamental. But what has tended to happen is that everyone either leaves out or gives lip service to the whole area of delivering information to the participants within a process - and normally these are people.

Let's face it. Most process automation systems today are simply replacing adhoc 'business collaboration' processes (paper, fax, email, spreadsheets, ms access databases) with an automated, end-to-end system. The goals are generally clear: increasing the speed and throughput of the business, ensuring the accuracy of the information throughout the process, and applying governance to the process overall (policies, auditing, logging, ...).

I like to think of this as getting the right information to the right people at the right time.

Ok, simple enough Dave - what's the big deal? A little process, a little data, a little Visio. Gimme a browser, a process engine, and I'm done, right??? Well, no - not quite.

There are several companies in the BPM market that provide reasonable modeling, design, and process execution servers. There are certainly good and bad things about each system - normally revolving around ease of use, end-to-end closed loop solutions, and automated measurement capabilities. And many of them also claim to provide an offering to design, implement, and execute the information delivery (i.e. interactive application) components of a solution. However, if you take a close look at this particular portion of the offering, it almost always - or in fact, always falls short of what is required.

It's actually quite clear how this has come to be. BPM system vendors think "process" day and night - as they should. And so when it comes to delivering information to people, they tend to focus on the delivery and modification to the "process data" - that information which is carried on through a process from activity to activity. And this is good, but it isn't sufficient. Why is that? Well, let's take a look.

Let's say that you have a process which is for authorizing a work order. A work order has the normal information components that you would think - customer info, work order number, and the all important work order line items.

Good process design must take into consideration several things, not the least of which is scalability. Thus, in designing the work order authorization process model, the designer is not going to place every data element of the work order into the process definition. No, generally a process design contains "references" to content such as this, for instance a work order number. Then, as each activity needs associated information, it is responsible for retrieving that extra data on the fly. And where does this extra information come from? Well, it's the normal candidates - databases in 95% of the cases, legacy systems, maybe some web services, etc. The answer is - from a bunch of different sources. Thus, a key part of the process implementation is the retrieval and potential modification of data elements from multiple disparate data sources.

So, now you come to implementing the portion of the work order approval process which must present the work order for authorization to a person, including line items and other details. Can you utilize the BPM system "UI builder" or "forms processing designer"? The answer at this level is almost sure to be - no. The answer you'd get from a BPM vendor is normally "Our system is open and therefore you can build any application in something like JDeveloper, Eclipse, or anything else that you like - and we'll give you the APIs to integrate with the BPM Engine to accomplish the job."

Of course, what this all means is - lots of coding, by hand. These tools know nothing of the BPM Engine, its APIs, etc. let alone the model that the developer is trying to implement. Thus, it really is at a loss to provide any help to the developer in making this project any easier.

What's really needed is a BPM system component that allows a developer to design and implement these multi-data source, interactive, process-driven applications. What they need is the ability to rapidly create and execute process-driven composite applications (PCA).

In future postings, I will outline the requirements of an ideal PCA solution and how the delivery of this type of solution will drive the usage of BPM systems to a new level.