Showing posts with label WorkFlow. Show all posts
Showing posts with label WorkFlow. Show all posts

2007-07-07

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.

2007-07-05

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.