College new-hires and the zen of BPM

I'm supposed to be preparing a one hour lecture for some college new-hires on: "Basic and Advanced BPM Concepts"... but yet I blog instead ;-)

For those of you who know me well, you'll probably think that my biggest concern is that I only have an hour. I tend to go on and on (and on) about topics that I am passionate about, leading a former co-worker to coin the term "johntification" in my honor.

Explaining BPM is what I do - focussing pretty much on what's now being called BPM-tech more than BPM-bus. When I first encountered BPM I felt like I had found the missing link... a paradigm and technology that closed the gaps between what I knew how to do and what my business colleagues really needed.

I was blown-away by BPM because I had experienced the pain of the problems that BPM addresses. This stuff fixed something that I knew needed fixing.

My worry about introducing BPM to college new-hires is that they probably haven't experienced "Process Pains"... at least not from the perspective of one who writes or maintains software, or from the perspective of someone who tries to get the "right" software written.

When I describe the problems that BPM tackles they may say "So what?". They may scoff at the magnitude of the problems - and they probably assume that the solutions that BPM provides have always been around.

With my standard BPM audience I'm fairly assured that heads will begin to nod in recognition of shared pain in thirty seconds or less...

Most in my audience have experienced meetings where a dozen people had to be present to figure out how that incoming *application* finally ended up as an outgoing *disbursement* (*substitute the inputs and outputs of your own business).

Most in my audience have also experienced "Office Heroes" - those harried individual who on a daily basis keep a company running through shear force of will. Whenever anything falls through the cracks... Whenever anything gets lost or derailed... Whenever any critical deadline is in danger of being missed... Office Heroes jump in and save the day. If a truck hits an Office Hero your business will really have to scramble to recover.

BPM helps business people understand how their company really runs, and it helps reduce their company's reliance on Office Heroes. BPM helps IT people provide tools that make it easier to run the company, easing the burden of the Office Heroes.

My college new-hire audience will certainly understand what I tell them about BPM - but will they relate? Can I make BPM relevent to their own experiences, or will I just sound like an old guy droning on about the old days: "When I was your age, computers only had 4K of memory....."

These "kids" are smart... they just haven't had as much experience. Instead of relying on shared experience to grok BPM I'll have to find another approach... When (or if) I figure it out I'll let you know.

Applications as Process Activites

I return to this topic a lot... BPM solutions automate the transitions between Activities in a Process, but they don't necessarily automate the Activities themselves. Some Activities can be automated, but others require Human interaction or Human judgment to complete. If we are convinced that BPM is a good idea, and we want BPM to be as pervasive as spreadsheets, then we need to make it easier to implement the Human-centric Activities that our Processes need.

Many BPM suites support building Human-centric Activities within the suite itself, but sometimes you'd rather re-purpose an existing application to do your bidding.

Let me walk you through an example from my own wonderful life as a Travelling Guy...

When I get a new assignment there are a lot of things that I have to do. I've got a mental checklist that I follow, but I'd really rather have a Managed Process to keep me from screwing up.

Most of my gigs are somewhere else, and that makes it very important for me to make travel and lodging arrangements. I almost always need a flight and a hotel, and based on the location I might need a rental car.

To perform this Activity I use my company's preferred Travel site - it happens to be Orbitz, but it could just as easily be Expedia, Travelocity or any number of sites. Each of these sites supports the concept of a "Trip" and each lets me make flight, hotel, and car reservations. These travel sites also provide feedback - they'll send me email when a reservation is confirmed or "something" changes.

As I am going through my process of getting ready for a gig, I log on to Orbitz and make the necessary reservations. When I am "done" I will "check off" that task from my list of things to do.
This happens a lot in BPM solutions. An Activity (a task) is assigned to an individual Participant. The Participant gets directions on how to perform the Activity (what it is that they need to do) but they have to use some "external" application in order to actually perform the task (in this example, the Travel site). When they are "done" with the task they "check off" the task and the process continues.

Processes that are implemented like this can be really error prone. The Process Manager has to rely on the Participant's assertion that the task has been performed correctly. You just have to trust the Participant to do the right thing.

If you had the time and if you had the money, then you could build all of the tools that the Participant may need to use in order to complete their tasks. Quite frankly, that would be a huge waste of both your time and your money.

The better approach for all concerned is to encourage the makers of those "external" tools to become Process Aware. Get then to modify their existing applications to be aware of Process Flow.

Let's go back to my "Get Ready for a Gig" Process... Some time after the Process starts I will need to perform the "Make Reservations" Activity. The Process Instance knows the Location of the Assignment, and it knows the Dates of the Assignment (the Process was started by a message that contained this information).

When I run the "Make Reservations" Activity from my Task List I'd like Orbitz to open with the Dates and Location of my Trip pre-populated. After I make my reservations, I would like the site to send (structured) confirmation information directly to the Process Manager.

Based on the information that Orbitz returns, the Process Manager would either move on to the next task, or require me to try again. For example - if Orbitz says that my reserved flight is on the wrong day the Process Manager should tell me.

If you are a Programmer, then I think you can easily envision how you would make the Webapp that implements the Orbitz Travel Site "Process Aware". The trick is in recognizing that there is a beginning and an end to planning for each Trip. Modify the Webapp to support "Dates" and "Location" on the invoking URL - along with a "Return Address". When the Webapp determines that planning for the Trip is complete, use the "Return Address" to send structured information (most likely XML) back the the Process Manager.

For Web Services (automated Activities) we've done this for several years. Service providers (like Orbitz) publish WSDLs that define the Services that we can invoke. It's time to do the same for Activities that cannot be Automated. It's time to standardize interactions with what I've called Human Powered Web Services - Web Applications that can serve as Process Activities.

In my ideal world, all Travel Sites would support "the same" interface for starting a new "Trip" and for returning results. That might be a bit much to hope for... but it's a good target to shoot for. Even if every site had a unique interface, we could build adapters for our Processes - a much better situation than today (from a Process Manager's perspective).

If you are a Developer who builds sites where folks go to "do things", then I hope I've inspired you to think a bit about those "things" as part of a larger Process. It's not a huge leap to build into your site the hooks that a Process Guy like me needs to incorporate your site into my Managed Process. I'll be grateful, and I'll bet the users of your site will be too.

Clarifying your ideas

I love the Webcomic xkcd by Randall Munroe... Geek humor for sure, but often very insightful...

"You'll never find a programming language that frees you from the need to clarify your ideas"

Amen to that.

Programming is the act of transforming requirements into something that a computer can execute... but before those requirements can be transformed they'd better be clear. You might think that this would be obvious, but you'd be wrong... In way too many cases the "idea" that spawned the software either wasn't clarified or it wasn't communicated clearly.

Programming languages - both textual and graphical - won't substitute for an idea that hasn't been clarified. But "better" programming languages can help to insure that the idea has been implemented properly (or at least make it clear what was actually built).

Business Process and Activity Interfaces

Business Processes are made up of Business Activities. In a BPM solution the transitions between each Activity are automated, but the Activities themselves may either be automated or they may be performed by Humans (That's why I use the term Managed Business Process instead of Automated Business Process).

Most of the focus in the community of BPM practitioners of late has been on the Business Process Definitions (BPDs) that the Process Managers use to control the transitions between Business Activities. BPDs provide the information that the Process Manager needs to assign the right Activities to the right Participants at the right time. Google BPMN, BPEL or XPDL and you'll find plenty to read.

BPDs are crucial... but they only define the Process Flow. Activities are identified in BPDs, but only the interfaces to the Activities are actually defined (The interface to the Activity defines the information that is passed from the Process to start the Activity and the information that is returned to the Process from the Activity when it completes).

All of the BPM suites that I am aware of generate executable process definitions (in one form or another). Some BPM suites generate "portable" definitions using standards like BPEL and XPDL, but many (including the Lomabardi Teamworks suite that I use) produce proprietary definitions that will only run on their own Process Managers. One of the big drivers between the efforts to make BPMN 2 "executable" is to drive the industry towards "portable" BPDs that can run Process Managers from any vendor. Great idea... but it's going to take some time to see if it gains traction.

Many BPM suites also incorporate tools to implement Business Activities. A Business Activity is really just an application that is tailored to perform a specific task. The Process Manager kicks off the application with some initial information, the application runs (usually gathering information from a Human) and when it completes it passes information back to the Process Manager.

I've had discussions with BPM practitioners who feel that implementing Business Activities should fall outside the realm of a BPM suite. Perhaps I've been spoiled by Teamworks, but I can't imagine creating my BPD in one tool and implementing my Activities in another tool. It's just incredibly nice to be able to drill down from an Activity on a Process Diagram to the underlying implementation of that Activity.

Despite my bias toward integrated Activities, I freely admit that you must be able to implement an Activity outside the limitation of your BMP suite of choice. Some Activities do require a very sophisticated user interface - and in many cases a pre-existing application can be fairly easily adapted to perform an Activity. I've had to resort to "external" Activities on several occasions (for key Activities).

If the implementation of an Activity is beyond a simple Form that the Participant needs to fill out, then you'll have to build some sort of task focused application for the Participant to use to complete the Activity.

BPM suites such as Teamworks allow you to build rather sophisticated task focused applications - but sometimes it makes more sense to go outside the suite and build the application using JSP, ASP, .Net, Ruby - whatever tools make the most sense to get the job done.

The "problem" is the lack of standard interfaces for connecting these "external" task oriented applications with your Process Manager/Process Engine. Most of the good BPM Process Managers provide the necessary interfaces, but they are almost always proprietary interfaces.

In the early days of BPEL, Activities were "just" standard web services. An Activity (web service) that was invoked from one BPEL engine could be invoked by any other.

BPEL (by itself) could only implement processes that could be completely automated. Most Business Processes include Human Activities - so pure BPEL implementations were few and far between.

Unfortuntely we've yet to come up with a standard (or even a de-facto standard) for implementing Human Activities. Some BPM suites (like Intalio) make use of standards (like XForms) to implement the user interfaces for their Activities, but the back-end interfaces between the Process Manager and the Activities are still unique to each vendor. There's no standard for registering an "Activity Application" with a Process Manager There's no standard way for an "Activity Application" to authenticate its user with the Process Manager. There's no standard way for an "Activity Application" to query a Process Manager for Activities that belong to its user.

Until we have these standards, there's really no such thing as a "Portable Activity". I could build a framework that helped me build task oriented applications, but I'd need adapters for any BPM suite that I wanted to interface with.

Hopefully this will change soon. As more BPM suites begin to support "standard" BPDs it will become obvious that we need Portable Activities too.