Software for Business People (like my dad)

(Cross posted at my java.net blog)

My father ran a small-town employee credit union in the 1960s and early 70s when most small organizations still used paper to store their records. Information for each account at the credit union was kept on large sheets of card stock. When a deposit or a withdrawal or a loan payment was made, or when interest was accrued, my father would retrieve these paper records, insert them into a Burroughs “posting” machine, and type in the current balance and the new information. The “posting” machine would then mechanically compute the new account balances, and print the relevant information onto the paper record. Very primitive by today’s standards, but all of the relevant information about the account was there on a card for all to see (Don’t ask how my father to dealt with errors… the thought still makes me shudder).

My father’s credit union worked because he had a system, or more precisely a process, for updating accounts. When folks would deposit or withdraw their money, forms would be filled out and placed into what was essentially an inbox. The money would change hands immediately, but the “official” paper record would not be updated until a time that was set aside for “posting” the updates. During most of the year my father and one helper (my mom) were the only staff available; so given the complexity of “posting” changes, you could not do this immediately. Once each year (at tax time) my father had to update all of the accounts and prepare letters that were sent to all of the shareholders. During these “crunch periods” my dad would hire extra staff, some of whom (me and my brother) were very unskilled. The "process" during these times was modified… instead of one person cycling through all of the steps, the more skilled workers would focus on key steps of the process for each account, and their results would be placed into bins. The temporary workers would take their work from these bins, each worker going at their own speed (I was notoriously slow).

From a "40,000 foot view" of the business perspective, very little has changed in the world of credit unions. Computers have enabled process automation, and that has made it much easier for folks like my dad to process transactions. Computing interest accruals is no longer a scary proposition. Everything happens much faster, and fewer staff members are needed, but the basics of the business are still about the same.

Every business involves a collection of processes that result in services or products that are delivered to customers and business partners. As conditions change, the processes need to change or the business suffers (or fails). Computers and software have enabled the automation of these processes… but they generally have not significantly altered these processes (unless automation by itself enabled a better process).

Processes are composed of events, tasks and decision points. Execution of one or more tasks leads to a decision point, the outcome of which leads to the execution of more tasks (or the completion of the process). As with my father’s process, we’d like to be able to “hire more workers” to perform these tasks if our business grows (and we’d like to be able to “lay off workers” if the business slows). Said another way, we want processes that scale well… as the business grows we should be able to add hardware to keep pace without having to change our software.

We also want processes that can be easily changed. If a new task is required, or an existing task is no longer needed, or the criteria for making a flow decision changes, we want to be able to easily implement the changes.

Java and the JVM clearly play a huge role in crafting the infrastructure underlying "Business Process Environments". With the combination of Java-based application servers, messaging systems, user interface components, database support, rules engines, identity and security solutions, enterprise service busses, etc. the Java ecosystem is by far the best choice as the basis for solutions.

To capitalize on Java's strengths, we need to step back into the shoes of those pre-computer business folks (like my dad) and consider what we need to provide to make all of this "stuff" really work for them.

Back before computers, you could sit in an office and observe the business processes. The process flow and process steps could be easily monitored and analyzed. The need to modify the flow, or to improve the efficiency of a specific task was something the business owner could easily discern.

From this perspective, you can probably understand why I am interested in languages like BPEL, and in the SOA design paradigm. The tasks and decision points that make up processes can be mapped very closely onto Services and BPEL orchestration logic.

BPEL is far from perfect, and the use of Services (particularly those with XML/HTTP interfaces) adds overhead, but the paradigm is the right one for many businesses. I’m comfortable to predict that better “process oriented” languages will be written, the performance overhead associated with using Services will be lessened, and the ESBs will become a whole lot more capable.

The NetBeans 5.5 Orchestration Designer is very cool, but it is only the tip of the iceberg. We should soon see tools that let someone who really understands a business (like my dad) make (appropriate) process changes without having to involve a programmer (To use a car analogy: “real” programmers will build and maintain cars, but business people will be able to tune the engines.)

If my dad were still with us, he'd probably still be hesitant to give up his paper records... but in the near future I'll bet that we could win him over ;-)