Business Process Musings

For the past few months I've been working with a very polished Business Process Management (BPM) suite from Lombardi Software , and I have to say that I am as happy as a clam. I feel like I have discovered a tool that I've been missing for at least 20 years, maybe longer, and I'm delighted.

It's hard to explain BPM to those who haven't experienced it, and to complicate matters it seems that each BPM vendor defines the space a bit differently, but I think that the dawning availability of high quality BPM suites is going to have an impact on business programming that will be just as significant as Object-Oriented programming was to programming at large. Quality BPM suites will usher in an era of Process Driven Design, and the wide-spread adoption of that paradigm is going to lead to a renaissance in business process engineering.

Okay, so you are now thinking that I've found another shiny penny, and that I'm vaulting back into hyper-enthusiast mode... Well... Not really. This is pretty much the same song that I've been singing for the past few years, but a different verse.

Remember SOA (Service Oriented Architecture)? Remember how folks couldn't really grok the difference between Services and CORBA and EJBs?

The answer is surprisingly simple... There really isn't much difference between Services and CORBA and EJBs in terms of functionality. The difference is in terms of "composability", and that's where BPM tools are making the difference. BPM tools give you the ability to compose (in a very agile fashion) multi-party process-oriented applications that can incorporate Services.

At this point you may be thinking that I'm describing BPEL (the Business Process Execution Language), but BPEL's only a small subset of what BPM offers (BPEL doesn't even handle human interactions yet).

BPM suites allow you to create multi-party process-oriented applications from scratch, deploy them to production, and maintain them over the long haul. You begin by diagramming the business process using a graphical notation such as the Business Process Modeling Notation (BPMN). The resultant Business Process Diagram (BPD) captures the highest level requirements in an executable process definition... This is one of the great things about BPM, the mapping between the requirement and the implementation couldn't be more straight-forward. The BPD can be stepped through with the business folks ad-infinitum to make sure that it's really correct, and together you can add in all of the (business) exception flows and caveats until everyone is happy.

Meanwhile, the activities that make up the process have to be fleshed out in detail. Some activities will require human interaction, others will be fully automated. Some activities will leverage pre-existing services, others will require new services... Good BPM suites contain tools for creating UI's, constructing light-weight services, and connecting to existing services (Web Services, Java objects, databases, packaged applications like SAP, etc.)... Most of the BPM suites that I'm familiar with are Java EE based, so what you're getting is a process-oriented veneer on top of all the Java functionality that you know and love.

Once the activities have been fleshed out and tested, the resultant application can be deployed to a Process Execution Engine (PXE) and made available to the masses... just like a Java EE application. But unlike a generic Java EE application, the PXE's generally provide a great deal of support for process-level instrumentation, and this is where Business Process Engineering comes into play.

Software Engineers generally care about infrastructure metrics. How fast is a query? What's the latency of response time for an incoming message? How much space is left on the hard drive?

Business Process Engineers deal at a different level. How long does it take to process an order? Where is the bottleneck in the process?

A good BPM suite (which includes a good PXE) allows the Business engineer to ask these questions directly. Each process can be instrumented in a natural fashion to obtain the answers that the Business engineer needs. If you've ever worked in an IT department you've probably had to scour through log files to answer a Business question that you thought they'd never ask. You've probably also had to develop some sort of ad-hoc instrumentation in your applications to capture metrics that might be useful someday, but will most likely never be evaluated.

BPM suites go a long way towards curing those headaches for you by coupling straightforward process instrumentation with focused reporting tools. Drag a few instrumentation points onto your BPD, create a simple report, and now your Business Process Engineers have the data that they need to really tune their processes.

None of what I am describing is really new, but the combination of these features into a truly usable environment is something that I hadn't experienced before, and you are probably going to have to experience it for yourself to truly grok the value. Unfortunately the Lombardi tool that I am using has no community edition, but there are some pretty good alternatives out there to sink your teeth in. I haven't had a chance to use them yet, but Intalio's Open Source BPM and JBoss's jBPM both look promising (and you can try them for free).

If you are a nuts and bolts infrastructure guy, or a game designer/simulation god, then BPM probably won't be your cup of tea... but if you're a business programmer, BPM is probably going to make your job a lot more fun.