Process-driven application

From Wikipedia, the free encyclopedia

The term process-driven application refers to an application which is driven by an underlying process engine where the process can be exposed and reused. In effect all applications are process-driven and the logic of any application can be extrapolated into a flowchart to represent the logical process of execution. Process-driven applications are a growing trend in enterprise solutions involving humans, systems or both.

Recently, Microsoft introduced the Windows Workflow Foundation (“WF”) which provides developers with the ability to separate application flow from application execution. A Microsoft product to use this approach is BizTalk Server, where orchestrations represent the order of execution. Both technologies provide graphical tools to manipulate processes and can form part of a process-driven application. They provide the process engine required to drive the application.

The term process-driven application was popularized by K2 in 2008 when describing applications driven by processes, and originally referred to applications driven by their Business Process Management ("BPM") software known as K2 blackpearl. The term has now gained wider acceptance and refers to any application driven by a process engine.

1 History
2 Process Categories
3 Relevance
4 See also
5 References

[edit] History

The first software applications were considered procedural in that they were composed of multiple procedures that were called in a predefined order. This predefined order could be static, such as in applications not requiring input, or dynamic based on input either from humans or other sources. In effect, the entire execution path could be directly mapped onto a flowchart which would take into account all path changes based on input. In those days, it was the norm for all applications to start out as a flowchart and then move forward from there although this has now changed as organizations move towards Rapid Application Development ("RAD") methodologies.

Even today's applications using today's techniques of object-oriented programming can have their execution logic represented using a flowchart. Now consider that the humble flowchart forms the basis of all processes in use today. Whether it's accounting, business, engineering, etc, the humble flowchart was the first, so to speak. All process models attribute their roots to the flowchart.

Taking the above into account, it was only a matter of time before technologists realized this gap and started to look for tooling to support the ongoing design and maintenance of these processes.

[edit] Process Categories

In the context of process-driven applications, three categories of process exist:

[edit] Human-to-Human Process

Human-to-Human processes, in this context, refer to processes involving humans only. The process is defined and managed by specific software and this software is responsible for task assignment, tracking and auditing for example. The process software is thus responsible for following the predefined process path and assigning tasks to humans for them to review and complete.

[edit] Human-to-System Process

Human-to-System processes, in this context, refer to processes involving both humans and systems. The process is still defined and managed by relevant process-centric software except that in this scenario, underlying systems may be accessed to store data or initiate transactions on behalf of a human or as a result of choice or design.

[edit] System-to-System Process

System-to-System processes, in this context, refer to process involving systems only. The process in this context is usually referred to as an orchestration as it usually comprises data transformation and complex routing scenarios.

[edit] Relevance

Today's businesses are process driven, everything done in a business is a process, from making coffee to hiring an employee to auditing financial transactions. Thus it makes sense to extrapolate these processes to reusable definitions which can be controlled by software to ensure that actions are repeatable, auditable, monitored and predictable.

Separating processes into the above categories allows organizations to better understand their requirements and in turn to select software best suited to those requirements. Once the process engine is selected, applications are built around these processes to provide the organization with a solution which is in fact a process-driven application.