Document Centric Design?

The Idea is that documents represent a single common data format for all processes. All processes produce or consume documents. A process that consumes no documents is called an originating process. A process that only consumes documents is called a terminating process.

Key Concepts:

1. Business Processes shall produce documents
   • documents can never be changed
   • documents record answers & decisions
   • not necessarily real documents (like *.xml, *.pdf, *.doc) but perhaps table structure
2. Business Processes consume documents
   • documents from other processes may feed this process
   • processes may develop natural dependencies based on the documents they need
   • processes may raise alerts based on the documents they need
   • some processes may not require any documents, these are originating processes
3. Originating Processes begin a new workflow
   • they originate a new workflow
   • they have no prerequisite documents
4. Business Processes are versioned and concurrent
   • clients default to starting the newest defined process under a given name
   • documents in process will finish in the version they started in (this is not to say you couldn't terminate processes to force people to use a new version )
5. Interviews are Processes concerned with asking questions
   • Interviewees are the people taking an interview
   • An Interviewer is a person filling in an interview form for a person
   • A Self-Directed Interview is an online interview with no human interviewer (the computer is conducting the interview)
   • answers are unique to an interviewee
   • answers relate to facts that we can assert about an interviewee.

In addition consider that all updates should themselves be a new process and document.

Why A WorkFlow Engine?

Different problems lend themselves to expression in different languages. There are points at which a new tool is beneficial. Too many tools means that there are too many things to learn and that complicate work unnecessarily.

Consider the simplicity of chopsticks versus the complexity and elegance of formal cutlery as demanded by a formal table setting. Different utensils for salad, soup, main-course, dessert, and to stir your coffee or tea versus one pair of utensils for absolutely everything. Which is better?

Don't fall into the "hammer" problem, that's where you see every thing as a nail needing to be hammered. Yet, keep away from the Victorian table setting if at all possible. We have chosen to simplify Business Process Design at the expense of adding a new tool to learn. The tools are simple enough but will take time to learn how to use well.

And, if you missed it: Java is the chopsticks and jBPM is one utensil in a very big cutlery set.

What is a workflow engine?

Workflow engines are a new way for representing knowledge in a computer. They are simmilar to RDBMS systems (DataBase Engines) in that they allow for the storage and organisation of facts in a specialized way. Workflows differ from Databases in that they represent different types of information and in radically different ways.

Traditional computer programs represent data in scalars which are single atomic bits of data. Scalars can be organized in arrays which are grids of data that may have 1, 2, 3, or more dimensions. You could think of a scalar as a single variable like "x" or "y" and an array as a spreadsheet.

Relational databases allow us to organize data in something simmilar to a spreadsheet with named columns called a table. However, databases do not stop there. There are rules called The Rules Of Data Normalization that help us master these additional aspects of the Relationships between data elements.

Workflow engines are not concerned with data specifically as are Databases, they are concerned with the concept of a Process Definition. These are often drawn by computer scientists as bubbles with arrows between them. In the past these were pain-stakingly coded by programmers using if-then-else statements and session management systems to distinguish different actors (people or programs) as they progress through a process.

When developing a Workflow driven program, programmer's focus is on how something happens, and a Process Designer's focus is on what happens next. A Process Designer may be a Programmer, a Business Analyst, or other semi-technical role. Just as Database systems require specialists eventually Workflow engine specialists will emerge. Workflows should not be confused with Rules Engines. Workflows are not completely non-technical and still require programming expertise.

As with any computer related discipline the development of a workflow system requires a linguistic and mathematic aptitude. The developer of a workflow must be able to follow the abstract rules of a formal logic system and also be capable of articulating complex logical proceedures to both humans and computers. These are a unique combination of skills that are not commonly found together in equal measure.

The concepts behind workflow engines are nearly as old as the ones behind the RDBMS but Workflows are still early in their "hype cycle." This may be in part because only companies such as SAP have been producing these engines pricing them out of reach for many companies. Many lessons are yet to be learned by the bulk of IT departments. The trick is to be enlightened about what the technology can actually do for us and not to get caught up in hype about the technology.

JAX-RPC is killin' me.

No collections?!? WTF! It seems that the JBossWS product put out by JBoss does not allow for collections over the wire as SOAP... yet my XJC tool will turn an DTO into POJOs using java.util collections. What gives!

We live in the 21st century, application developers should have dynamic data structures like double ended queues, vectors, and hash-maps to work with. If you can't do a container then your serialization program just isn't ready for prime time.

Damn it. Now I'm going to have to pour through all that autogen code and rewrite it to use plain arrays. I wonder how Hibernate will feel about this.

jBPM, EJB3 Persistence, Hibernate....

I think I'm going to go nuts. jBPM, EJB3 Persistence, and Hibernate... all playing nice-nice together? Is it possible? Apparently not.