A Programming Language For Business

Back in my java.net blogging days, I wrote a post that lost me a lot of love by asking the question:

Is Java the wrong language for business programming?

My thinly disguised answer was no.  Java is not a suitable language for business programming... It's great for building the integrations and middle-ware that business relies on, but it's a lousy tool for transforming business requirements into code.

Having alienated all of my Java friends long ago, I guess my next step is to alienate my JavaScript programming friends too...  Here's my rule:

Programming Languages that use  ==  are not suitable for Business Programming 

I am a realist.  JavaScript is pervasive on the Web and will never die no matter what nasty things I say about it... but I truly believe we need a better choice for Business Programmers to thrive.  Google, with their GWT has already shown us the way - Translate the Programming Language that meets your needs into the Programming Language that the Web supports (In the case of GWT from Java to JavaScript).  Define a Business Suitable Programming Language that knows about things like dollars and cents and business days and work schedules and then translate the code that you write with this language into JavaScript.  Problem solved.

Unfortunately, I don't think that Google has any interest in making the world better for Business Programmers - I hope that I am wrong, but I fear that "Business Programming" just isn't sexy enough for the wonder-kids at Google to care about.

If we ever do see a more Business Friendly Programming Language it will probably come from some stodgy old company that cares more about helping businesses run better than about seducing users into clicking on ads and sharing their marketable personal data.

It's a long shot, but maybe, just maybe, I won't be too old to program before Business Programmers finally get a language to call their own.

Government Process Management

There's an article in the New York Times today about a new computerized system that should help prevent NYC police from "fixing" tickets.  While this may be bad news for a few well connected individuals, for the masses this is a very good thing - The powers that be have instituted a process that (if followed) should detect (and deter) public employees from engaging in fraud.

What's not clear is the public's visibility into this process.  If the tracking information for each ticket isn't publicly available, then how will we know if the process is being followed or if it's being faked?  Monitoring a process is a great thing - only if those who are supposed to be protected by the process have the proper view of the process.

For those of us who are maddened by government waste and fraud, this is cause for hope.  Personal privacy seems to be a thing of the past - but perhaps Government privacy is too.

Phil Glibert video

Yes it's a marketing blurb, but this video from Mr. Phil is a pretty good sum up of what IBM Business Process Manager is all about.

The Business Process Application Building Checklist

Your team's process for building a Business Process Application is going to be involved and nuanced, but let's start off with a check list for how to get started implementing any process application:

1. Assemble the core of your BPM Dream Team who will build the process application
2. Identify a "significant" subset of the chosen process that can realistically be built in about 90 days (longer than 90 days and your odds of failing rise dramatically)
3. Create an  Executable Business Process Diagram so that you can step through all the paths of the process with your business owners
4. Create a Functional User Interface for each Activity to insure that each task is fully understood by you and the business owners
5. Define the key Process Performance Reports (PPRs) to insure you understand what's important to the business owners, and add Tracking Points to the BPD to capture the data the PPRs will require
6. Identify all the remaining Human Interfaces to the Process that will be required to support the process 
7. Refine the Process Data Model based on the requirements that you've discovered thus far.

This checklist might seem simplistic... but it's critical to "be sure" to check off all these aspects before you start building anything else.

Update: This checklist has grown a bit since originally published based on some excellent feedback

Process Performance Reports

When working with new-to-BPM clients I often have to help them differentiate between traditional Business Performance Reports and Process Performance Reports.

A Business Performance Report generally answers questions something like the following:

• How many units of X did the Y group process last month?
• How does the X processing rate of the Y group compare to last years processing rate?

A Process Performance Report generally answers questions something like the following:

• How long (on average) did it take Y group members to process an X?
• Why did it take longer for the Y group to process an X in these instances?

Everybody knows how to gather the data that they need for their Business Performance Reports... and once they give it some thought most folks can also grasp how to gather the data for their Process Performance Reports.  They just need a little nudge to change their thinking from "how many" to "how long".

Process Performance is all about "How long did it take?".  If you want to know "How long?" then you have to know when "it" started and when "it" finished. 

If they don't give it much thought, when asked where to capture time stamps in their process your typical business owner is likely to say:

"Track Everywhere!"

That's not necessarily a bad thing - but you need to remind your business owner that the purpose of tracking is to gather timing and business data that their Process Performance reports are going to require.

Before you start tracking anywhere, you really need to identify all of the Process Performance reports that the business needs.  Defining these reports is clearly the responsibility of the business owner, but you may have to give them a little help.  My suggestion is to focus on what questions each report is meant to answer, rather than on what the report is going to look like (bar charts, pie charts, etc.)  There are many ways to present data - at this point you have to be focused on getting the data in the first place.

Here are some questions that might be asked about the rather generic Request Resolution process you can see later on this page:

• How much time do we spend reviewing requests that are eventually declined?
• Do some reviewers take significantly longer to decline a request than others?

The next step towards gathering the data that they will need for each report is to get the business to identity the start and end points for the intervals that each report represents.

Most BPM suites can automatically give you the durations of all activities... but often your report is interested in durations that are measured across multiple activities or whose start and end points are dependent on the path the process takes... as is the case with the questions I just posed.

If it's not obvious where in your process you need to capture a time stamp, then a good place for you to start is to identify the major phases of your process.  For example, many processes have a Preparation, Decision Making, and Implementation phase.  If you track the transitions between these phases, then you will probably have most of the time stamps that your reports will need.

Another good place to start it to identify all of the significant milestones and events in your process.  Often these points correspond to the phases of your process, but there may be other points that are "exception points" in the process, like the withdrawal of a request.

In the following diagram, you'll see that I have added "Tracking Points" where the process flow crosses the phase boundaries and at some significant "exceptions":

This Business Process Diagram (BPD) is from IBM's WebSphere Lombardi Edition - and utilizes the Intermediate Tracking Event to indicate the specific points where I want to capture a time stamp.  Other BPM suites may use other mechanisms, but the point is - I need to know when the process flow passes any of those points.

Once I have identified all the points in my process where I want to capture a snapshot, I need to figure out what business data I need to associate with each tracking point... and that can sometimes be tricky.

If you ask your typical business owner what to track, they will most likely say:

"Track Everything!"

This is an understandable reaction - "Something" may be important, and if you don't track it you can't evaluate its effect on the process.
Unfortunately, it's just not practical to "Track Everything!"  Your tracking data base will quickly become huge, and there will be loads of superfluous and redundant data.

So how do we narrow down what business data to track?

Start with the bare minimum - What do the Process Performance reports need?
At a minimum, we have to track the business data that is required to answer the questions that our reports are meant to answer.   If we have a report that needs the business data, then we track the business data - If not we don't.

Take a look at the process diagram on this page, and let's assume that we want to build a report that answers the question: "How much time do we spend reviewing requests that are eventually declined?"

We've got the time stamps for this report - Start Review is the beginning and Declined is the end.  With the time stamps of those two points we can answer our question.

Now let's ask a different question: "Do some reviewers take significantly longer to decline a request than others?"

This report relies on the same tracking points, but now we have to capture the identity of the reviewer.  Note that we only have to capture the reviewer's identity at Declined to prepare this report.

I am sure you can think of a host of other questions, such as "Is there something about the request itself that complicates the decision to decline the request?"

Perhaps there are a few elements of the business data that could help answer this question, but we may have just crossed the line from data that we should track to data that belongs in the company's system of record.

Data about the request that does not change over the course of the process usually doesn't need to be tracked.  New records are added to your tracking data store every time your process passes a tracking point.  If you also have a business data store - that holds the "current" details of the request, then nothing is gained by also storing that information with all of your tracking points.

We're pretty much done at this point.  We've identified all of the points in the process where we need to capture a time stamp, and we've identified all of the business data that we need to store along with those time stamps.  The only thing left to do is to take one more look at all of the Process Performance reports that the business identified and make sure that nothing was missed.

The process that I've outlined for defining where and what to track is admittedly subjective but it's also pretty easy for a good Business Analyst to follow.

Starting with a Process Diagram and a list of Process Performance Reports, the Business Analyst can (and should) define their Perspective of the Process Data  (where to track data and what data to track).

With the Analyst's Perspective of the process data defined, we're one step closer to finishing our process application, and one step closer to giving our business folks a great return on their BPM investment... and that ought to make everyone happy.

From Lombardi Teamworks to IBM Business Process Manager

The journey from start-up company's show-piece to industry leader's center-piece has reached a new milestone.

My beloved Lombardi Teamworks, which has guided my career since 2006, is now the core of  IBM Business Process Manager.

This is a huge personal win for me and the alumni of Lombardi Software... Personal thanks to Phil Gilbert and Scott Francis who you'll see on my blogroll... and a big Woo Hoo to all my many Lombardi friends.

For the rest of you who are kind enough to read my ramblings... If you need a great BPM suite your options just got a whole lot better... and if you're building a competing BPM suite of your own... I respectfully submit that the bar for BPM suites just got a whole lot higher.

Update:  IBM Business Process Manager is a mouthful... What do you think we should call it?

BPM Implementation Dream Team

The last few months have been really fun for me.  I've had a couple of really successful BPM implementation engagements and seem to be on a roll.  I would love to take credit for the success of these clients, but the reality is that the makeup of their implementation teams is what really made the difference...

What makes a great BPM Implementation Team?  Of course it's the character of the people on the team - but it's also the "perspectives" of those people that really makes the difference.

In the bad old days of software development, one group would write requirements and another group would implement those requirements.  Let's call the first group "Business" and the second group "IT".
There never really was a 'Business/IT Team" that was tasked with building the solution... it was a Customer/Supplier relationship.

Rapid Iteration BPM implementation projects, like the ones that I work on, depend on "Business" to take on building responsibilities and "IT" to take on requirement writing responsibilities.  We don't structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:

• All Business requirements have Technical implications
• All Technical implementations have Business implications

When the business folks hit the technical hurdles, and the technical folks hit the business challenges, there's great incentive to find "another way" that gets the team to the solution sooner.  Shared misery builds strong bonds.

The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.

In some ways the relationship between these two folks resembles Agile's Pair Programming.  That's the practice of sitting two developers down side-by-side at a single workstation.  While one developer types in code, the other developer reviews the code to catch errors and insure compliance with the requirements... take that concept up to the level of Business Relevancy and you have one person who is concentrating on getting the technical aspects of the solution built and another who is concentrating on getting the business aspects of the solution built.

While we're touching on the topic of Agile programming, I want to hasten to say that many of the concepts of Agile are applicable to a BPM project, but there are some very key differences in the priorities that you assign to the implementation of features and functions.

In BPM, the Process is the Story.  The User Stories for individual process activities, although interesting, are just chapters in the book.  You must give priority to implementing all of the chapters to some minimal level of functionality before working on any other aspects of the solution.  The process-wide dependencies (activities, flow, payload) must be the focus of your initial Sprints, or you are quite likely running in the wrong direction.

But I digress... back to the core of our dream team...

The Business Lead is responsible for getting all of the required business functionality of the process implemented.  It should also be noted that the Business Lead owns the interpretation of the business requirements.  Any ambiguity in the business requirements must be clarified by the Business Lead.  Any changes to the business requirements must go through the Business Lead.  The Business Lead is the fountainhead of all things business (as far as the team is concerned).

The Business Lead is the primary interface between the implementation team and a host of business folks.  The business cast includes the following:

• Process Owners - usually the Operations folks who are responsible for keeping the business running smoothly
• Business Subject Matter Experts - the folks who really know the details about specific aspects of the business
• Process Participants - the folks who are going to use the solution that you're building

The Technical Lead is responsible for getting all of the required technical functionality of the process implemented.  As with the Business Lead, the Technical Lead owns these aspects of the process, but very likely there are many specialists involved to do the actual implementation.  What you are looking for is someone who has very good rapport with the Business Lead and the technical background to spot all of the technical implications of the process that must be addressed.  As I have blogged before, BPM solutions don't usually require a lot of Software Engineering, so the breadth of the Technical Lead's knowledge is usually much more important than the depth of the Technical Lead's knowledge... You need someone who knows which experts are necessary and when to engage them.

The Technical Lead will be supported by a host of developers, and often these folks are specialists.  You'll often find the following cast:

• Process Flow and Data Developer - someone who really groks how to implement the process and data requirements with your BPM suite.
• Human Interface Developer - someone who is a wizard at building all the Human Interfaces to your process.
• Integration Expert - someone very skilled in utilizing external systems... Mostly SQL and Web Service skills
• External System Expert - you'll need one per system that you need to interface with

So here's a diagram of your extended dream team:

Note that the involvement of the team members varies in intensity over the life of the implementation project.  The Business and Technical Leads are always "on call", but the lion's share of the Business Lead's efforts are early in the project, and the lion's share of the Technical Lead's efforts are in "the middle" of the project.  When you get to User Acceptance Testing the efforts of the Leads seem to be evenly split.  All of the other team members can come and go as needed... continuity is provided by the Leads, so the supporting cast members can be utilized effectively on multiple projects if need be.

If you organize your team around a Business Lead and a Technical Lead as I've described, then I'm willing to bet that your project will run smoother and you'll reach your goal sooner - and I'm also willing to bet that you'll enjoy getting there.

Project Plans and Process Definitions

I love my job... I really do.  Every month or so I start a new assignment to help a "new to BPM" client get a quick return on their investment and to help them become self-sufficient so they won't need me to help them "next time" - In essence my job is to  "work myself out of a job".

By working with such a variety of "new to BPM" clients I am constantly challenged by new "process problems" to solve.  Many of my client's problems are hauntingly familiar (so I already "kind of know" the answer), but I still often find that the types of "process problems" that  I already know how to solve aren't the type of "process problem" that a new client wants me to solve.

Just a few days ago I was talking to some folks and realized that what they thought BPM could do for their business wasn't at all what I usually think that BPM can do for a business.  They aren't crazy, far from it, they just have a different type of problem then that which I am used to solving.

The process that I usually help clients manage goes something like this:

"Every week we get a new X, and we have to do a lot of steps to produce a Y."

The problems that I usually deal with go something like this:

"We never know who is doing what, and sometimes things get dropped in the cracks.  We also feel that the process could be made more efficient, but we're not sure how."

Of course X and Y are never the same, and the steps for getting from X to Y are never the same, but it's always a process that is clearly defined and the client does it over, and over, and over again.  You might call these business "operational" processes.

BPM suites (as I usually apply them) are perfectly suited for this type of operational process, because I can create a process definition that my Automated Process Manager can "run" over and over again, and I can instrument the process to tell me (over time) how smoothly the process is (or isn't) running.  Once I have metrics from the completed processes, I can make suggestions on how to improve it.

My new client has something else in mind... It "seems" very closely related, but the devil's in the details and it's really something sort of familiar yet different.

My client does in fact have a process that they need to define... but they will only ever run this process once.  They will certainly run slight variants of this process many times in the future... but every time the process definition will (most likely) be edited.

In fact, what my new clients want is to be able to define a process that will manage a project plan, and have an Automated Project Manager to govern that plan.

It's actually pretty easy to look at a project plan and transform it into a process definition (the converse is more problematic).  Look at a typical project plan Gantt Chart and you can pull out the activities that need to be performed, who does them, and the general flow from activity to activity (image below is from Wikipedia).

With my favorite BPM suite, I can easily review the project plan's Gantt Chart and define a process (using BPMN) that corresponds to their project plan (diagram from WebSphere Lombardi Edition).

Once I have the process definition, my Automated Process Manager can in fact do everything, and I mean everything, that my client wants their Automated Project Manager to do.
I am only highlighting distinctions to point out how a one time Project differs from a many instance Process.

There is a nagging disconnect (from the project manager's perspective) between what you can represent on a Gantt Chart and what you can represent on a BPMN diagram.  Project managers are very fond of Gantt Charts because they are a very good representation of a project's timeline and dependencies.  BPMN diagrams do have a general sense of time (left to right or top to bottom), but they don't represent durations at all.  All activities are the same size.  There's no visual indication of the (predicted) time that it will take to complete a task... so information that is of primary importance from the perspective of the project manager is missing.

The more important distinction between the "operational" processes that I usually deal with and a "project" process has to do with adapting the plan as the process progresses...

With an operational process, you may over time change the process definition to make the process more efficient.  All new "instances" of the process will use the new and improved definition, and the instances that are "in flight" may or may not be migrated to the new and improved definition.

With a "project" process there's a real likelihood that the plan itself - the process definition - will be changed "on the fly" to respond to current events.  When activities don't get completed "on time", a good project manager will adapt the plan to try to make up for lost time.  These changes may be minor, or they may be extensive, but they are always immediately applied to a single running project.  The project manager is tweaking a specific running project to make it run better now, not changing the steps so that some future project may run smoother.

It's not a big leap of intuition to envision how the "project needs tweaking" scenario could be handled by a BPM suite... but to "make this easy" I think you'd want to tailor a Human Interface for the "process designer" tool to make it very obvious, and very easy, for the project manager to define and apply changes for a single running process/project.

The morals of the story (if there are any) are that BPMN isn't the be all and end all for all your process definition needs and that a set of tools that are very good for dealing with "operational processes" may not be the set of tools that you need for "project processes".  Sometimes a BPMN oriented tool is what you need, sometimes you need a Gantt Chart oriented tool, and sometimes you just need a Checklist.

Update: An IBM colleague of mine pointed out the similarity between what I have described and Advanced Case Management, and pointed me to a very interesting David Yockelson blog posting that contrasts the goals of BPM versus Advanced Case Management.  Quoting David:

"Business process management focuses on optimization of a process with a key goal to increase the volume of throughput or work completed for an individual process. 

Case management has a different “design goal” and focuses on optimization of outcomes for individual cases by providing an integrated set of information and services for the case worker. "