Business-Suitable Programming Tools

I'm a Technical Guy. I'd been an R&D programmer for most of my working life, but for some reason for the last few years I've become more passionate about Business-Suitable Programming than about Techno-Guru Programming.  Back in the day I was once enamored with the nuances of graphics rendering techniques, communications protocols, object-oriented programming languages and object-relational persistence mechanisms... but nowadays I find myself passionately wanting to help "average" people learn to write the programs that make their jobs (and their lives) a little bit easier, and I really couldn't care less about whether or not "Java implements closures".

Can Business Guys Program?

Programming is the act of transforming requirements into something that a computer can execute... so if the software's requirements are highly technical it stands to reason that a highly technical person will be the best programmer for the job.

But what if the software's requirements are primarily Business requirements?

Many will argue that Business Guys will never be able to create non-trivial software without the help of Technical Guys... and there is a lot of truth in those arguments... but there's also a lot of falseness in those arguments (many software development tasks aren't technical at all).

Business Guys ( aka Subject Matter Experts) generally understand the requirements of their Businesses a whole lot better than Technical Guys.
When Technical Guys implement Business Requirements, they generally have to spend a lot of time gathering up what the Business Guys know and translating that information into something that they can work with.  Sometimes (way too often actually) a lot gets lost in that translation and the software is a flop.

It stands to reason that Business Guys should be better Business Programmers than Technical Guys - they can more accurately transform Business requirements into code than Technical Guys can - but that's just theory unless they have the right tools to accomplish the job - and those tools are sadly lacking.

There's the million dollar question: What are the right programming tools for Business Guys?  What programming tools are Business Suitable?

To answer these questions we need to think about what makes a Business Guy's programming different from a Technical Guy's programming.

Business Guys are Occasional Programmers

The typical Technical Guy's IDE (Integrated Development Environment) and the typical Technical Guys programming language of choice (Java, C#, etc.) really aren't Business Suitable programming tools... because these tools were developed by folks whose primary jobs are to develop software... and Business Guys are occasional programmers (at most).

Business Guys don't develop software for a living... They may go for months or years without even thinking about creating or modifying software - but when they need to "program" they will generally need to get the program written and deployed very quickly.

Business Guys can be taught to use sophisticated programming tools (I've done it)... but they probably won't stay proficient with those tools.  They will forget things.  Their "programming skills" will get rusty over time... so Business Suitable programming tools need to take this into account.

Business Suitable programming tools are designed for people who don't program all the time.

Use the Business Guys' Terms

It's a no-brainer, but Business Suitable programming should use Business Suitable terms.

For example, Business Guys tend to spend more time working with "Money" than working with "Decimals", so why make worry about conversion from one to another?  Why not just have "Money" as a key concept of the programming language?

Money is a simple (but pervasive) example of what to look for, but in general the closer the programming language is to the Business Domain, the easier it will be for the Business Guy to program.

Put the "Code" where the Business Guys will look for it

Business Suitable tools need to rely on the Business Guy's knowledge of the problem to lead them to the "code" that solves the problem.  Rather than relying on "class hierarchies"  or "package names", organize the programming artifacts in a manner that makes sense to the Business Guys (like BPM suites that let you to navigate to Screens and underlying Code from the Process Diagrams).

The Business Guy's "coding skills" are bound to get rusty, but their Business Knowledge won't - Leverage knowledge of the business problem to help Business Guys navigate the "code base", and they'll get back up to speed very quickly when they need to.

Where Did We Go Wrong?

I've always wondered what happened after COBOL... Obviously we've always understood the need for a Business Suitable programming language, but after COBOL it seems like Business became a dirty word.  Pascal, C, C++, Java, JavaScript... Where's Business in that "mainstream" legacy?  If there's a Business focussed language out there that 80% of programmers have heard of (other than COBOL), I'd be very surprised.

Business Guys Outnumber Us

I saw a very interesting slide a few weeks ago at our Lombardi (an IBM Company) yearly kickoff conference depicting the ratio of Business Guys (Knowledge Workers) to Technical Guys (Java Developers) in a typical enterprise... I'm pretty sure the numbers were pulled out of the air, but they seem right - about 1000 Business Guys per Technical Guy.

If this ratio of Business Guys to Technical Guys is anywhere near close to accurate, then what do you think is a better approach to "Saving the World"?

1. Create better tools for the Technical Guys so they can service 1000 Business Guys
2. Create more Business Suitable tools so the Technical Guys can focus where they need to.

I'm voting for option 2.

What BPM can learn from a Checklist

It's only fitting that I pay homage to the title of Keith Swenson's "What BPM can learn from a Spreadsheet" posting... for it is Keith's "Is the Checklist mightier than the Model?" that led me to today's musings.

The world is a mess.  We're barraged with too much information and too many things to do.  Lots and lots of stuff falls through cracks every day, and it's only getting worse.  We need help.

Help can come in many forms, and one of those forms is technology... specifically Process Management technology.  We can build Automated Process Managers (APMs) that can keep track of things for us.  Tell the APMs what it is that needs to be done, and they can remind us to do those things, remind others if we don't do what we were supposed to do, etc.

Automated Process Managers can "Save the World".

The fly in the ointment is that the APMs can't help us do anything unless we tell the APMs what it is that we need to be doing... and that's where Checklists come in.

Checklists are really, really easy to create.  Just list all of the things that you need to do.  Piece of cake.

Home Improvement Project Checklist:

• Create Wishlist
• Determine Budget
• Select Architect
• Rough Sketch Plans
• Select Builder
• Initial Cost Estimate
• Revise Plans per Budget
• Construction Plans
• Approve Final Budget
• Start Construction

If you want to get fancy, you can even add a "Must complete by" date to each task on your list, and you might even indicate "Who" should do each task... What could be simpler?

Often times you'll have some tasks on your list that are more important than other items on your list - So you'll want to order them by priority... Work on these first (if you can).

One in awhile you will have tasks on your list that cannot be started until other tasks have been completed... and sometimes you will have tasks that cannot be completed until other tasks have been completed... Just add some arrows to your list as reminders.

Hmmm... Looks like your Checklist ended up as a Process Model:

Who says that BPM has to be hard?

Back to "Saving the World"...  It's time to stop futzing around and to start doing.
Start making those Checklists for every single Process that your Business relies on and hand them over to an APM.  When it makes sense to do so, take the extra time to order and arrange and define dependencies... But don't use that as an excuse to keep you from getting an APM to Manage all of the things that can be Managed now.

The World needs Saving.

Big Bang or something more rational?

Houston Neal is running a survey over on his Software Advice blog...  Take a moment to drop over and skew his results in favor of Iterative Role-outs ;-)

Tips for the Business Process Developer - Activity Data from the Participant's Perspective

This posting is a continuation of the ongoing Process Data Perspectives conversation that I have been having with my Teamworks BPM colleagues...  In a nutshell, we think that you'll create a better process data model if you consider the data from the perspectives of the folks who are actually engaged in the process.  We've identified the following perspectives that are common to most Business Processes:

• Process Owner
• Process Analyst
• Process Participant
• Process Builder

Today I'll be focusing on the Process Participant's perspective, particularly how they see data within a single Activity:

Participants in the process are the folks who are asked to perform specific tasks. For example, in a Loan Application process, the participants would include the Loan Officers who review and make approval decisions about loan applications.

Participants care about now. Their perspective of process data is immediate. What forms do they need to fill out? What fields are on each form? What are the acceptable values for each field on a form? Participants view data from a task level - What information do they need to consult and what information do they need to gather and modify to accomplish their task.

Given this understanding, let's delve a bit deeper to help translate the Participant's perspective into terms that are more familiar to Professional Programmers.

From the Participant's perspective: When performing a specific activity, the data (information) falls into the following categories:

1. Information that I am required to provide
2. Information that I can optionally provide
3. Information that I am required to verify
4. Information that I am required to correct
5. Information that is presented to me to help me with all of the above

There seems to be a lot of nuance in the above list because there is a lot of nuance in the above list.  The deeper you get into process activities, the more likely you are to encounter nuance.

"Information that is presented to me to help me with all of the above":

Let's start our journey at the end of the list: "Information that is presented to me to help me with all of the above".  Tell that to a programmer and they'll cringe.  We need to break it down a bit further into Instructions and Context.

Instructions:

All Activities need instructions. You need to tell the Participant what to do.  Some instructions are "static" - they don't change from instance to instance.  Other instructions are "context sensitive" and only displayed when appropriate.

Here's a static instruction: "Verify that the Postal Code is valid for the City."

Here's a context sensitive instruction: "Because the loan amount is over $200, you must record a co-signer."

Instructions aren't generally thought of as part of a software application's data model (by programmers) since they're generally "hard coded" on screens.  We programmers usually don't worry about where or how they are stored - they're just "part of the code".   In a Process Application we really ought to worry a bit more - The instructions need to come from the Business folks, and those folks really ought to be able to change the instructions when they need to.  This is particularly true when you have "localization" needs (instructions translated to multiple languages)... but there's a wider opportunity here for us to explore.

Wouldn't it be great if the Participants who perform the Activities could collaboratively improve the Instructions that are presented to them?

Phil Gilbert is always talking about BPM on every desktop - and this is a simple example of what that might look like.  Lousy instructions can make a simple task hard to perform.  Great instructions can simplify a complex task.  Give the users a mechanism to provide feedback, and over time they'll transform lousy instructions into great instructions, and process performance improvements might follow.

Context:

All Activities need context.  The Participant needs to know exactly what it is that they are working on.

Here's an example of context information: "The applicant is John Q. Public."

Context information has to come from somewhere... and that's why it's a crucial part of the data model.  Some context information comes from the Process Payload - that's information that's "passed" from Activity to Activity as the process progresses (think of this as an analog to the stuff inside the envelopes that are routed from worker to worker).  Other context information is retrieved from a System Of Record (SOR) when the Activity needs it (think of this as an analog for retrieving something from a filing cabinet when the worker actually starts the task).

Determining which context information should be part of the Process Payload and which should be retrieved from an SOR is both a science and an art that we'll leave for another discussion - for now just be aware that you'll need to iron out these details.

Determining the proper context information to display is on par with determining the right instructions to display - which means that you really need to validate context information with the users.  Paradoxically, context information is often "context sensitive" - Complex relationships on what to display often occur, based not only on the instance data of the Activity, but on attributes of the Participants themselves (a Manager may see more or less context data than a Worker).

Once again, this would be a great opportunity for BPM on every desktop - Give the Participants the power to define the context information that they need to see to efficiently perform their tasks.

"Information that I provide, modify, verify or correct":

From our original list of information types I've collapsed several entries for the sake of brevity...  Activities (with very few exceptions) require the user to provide, modify, verify or correct information.  Let's lump all of this data under the term "Manipulated Data".  There's often a blurry line, or no distinction at all, between Context data and Manipulated data, so it might be best to just think of this as the mutable (things that can be changed) subset of the Context data.

As with Context data, Manipulated data can either be part of the Process Payload, or it can reside in Systems Of Record... this is where the underlying architecture of your data systems is really going to come into play... If the Activity involves legacy systems, then System Integrations may be in your future.

Data Validation Rules:

From the Participant's perspective, they may or may not be aware of where specific information comes from, but they should be moderately aware of "what the rules are" around that data.  For example, the Participants must know whether or not a field is required or optional.  They must also know whether or not they are supposed to correct information (or ignore mistakes).

Validation of information that users supply or manipulate is a crucial concern that must be addressed - and you should start addressing this concern while defining the process data model.  Each field may have its own validation rules.  Collections of fields may have inter-dependencies.  The rules that are applied to fields may change as the process progresses, and they may change based on "who" is manipulating the field.

Purists may not consider the rules that apply to the data to be part of the data model, but pragmatists don't really care about distinctions.  The data requirements of a process are just as much about the data validation rules as they are about the data fields.

The Payoff:

That's a lot of stuff to consider when defining the Data Model for a single Process Activity, but you have to admit that it's mostly common sense from the perspective of the Participant who will be performing the Activity.  If you don't work with the Participants to define the data requirements to this level of detail "up front", then you're likely to have problems crop up when you least expect them.

Walking a mile in the shoes of the Participant at the beginning of your journey will probably make your journey shorter ;-)

An Error Occurred - Live With It

Have you ever seen a screen like this?

Helpful... Not.  But the color scheme and fonts are really pleasant.

On this particular screen, when you "Click here for more details" you get the following gem:

Much Better... Not.

This, my dear friends, is an example of what happens when you create a Business Process Definition without Participant Feedback.  If you had put mock-ups of these screens in front of any "real" users they'd say three things:

1. Who is my "system administrator"?
2. How do I contact my "system administrator"?
3. What the heck am I supposed to do with the "more details" that you're showing me?

If you can't answer any of those questions, then you might as well just put up a message that says "An Error Occurred - Live With It".