| Document properties | |
|---|---|
| Author | Gerard Toonstra |
| Document ID | 00-00-00 |
| Date | 12 Feb 2002 |
| Version | 0.1 Draft |
|
Owner |
Gerard Toonstra |
|
Document title |
Mother of all documents |
The purpose of the workflow server is to simplify, increase the quality, maintain and monitor business processes.
The workflow server can be classified as a workflow management application, but also has a very strong middleware architecture and support. There is no doubt that with the huge amount of application interfaces in today's world it is never possible to design a package that will meet to every need and that has a solution to every problem. For this reason, the workflow server attempts to motivate users to think about standardisation of interfaces and applications by showing how implementations can differ. From the perspective of large corporations, standardisation means the adoption of their standards. From the perspective of users and 'other' corporations, standardisation means interoperability, interchangeability and replaceability.
This project has been created free of charge, as a hobby of many developers and as a counter-weight to the endless line of commercial proprietary software. Software that is generally adversely affected by:
This project is open-source and very wide in scope, therefore it can only succeed if the proper standards are used. These standards should be:
To minimise risk, other opensource software packages are used for supporting purposes. The choice of supporting opensource software projects will based on the same requirements as above.
The commercial purpose of a workflow server is to provide companies with the means to map their business processes as directly as possible to a system that can automate these tasks using opensource software. Therefore it is required to analyse:
In this document and future documents we refer to business flows as processes. Individual steps in a process flow are referred to as activities.
An activity is essentially the same as the abstract wording of that activity. An example is: "perform inventory check". The condition placed on the result of the activity is a conditional for the execution of another activity. An example would be that if the inventory check failed, activity B is executed. If the inventory check succeeded (there is still inventory left), activity C is executed.
In the workflow server there is specifically a choice for the unstrict binding of resources to the system. This means that resources are not tightly linked into the workflow server, but have a very loose coupling. Using this method we hope it is much easier to add new resources and this will provide the extendability required.
In essence, the workflow server is nothing more than a regulator of abstract processes and abstract activities. For the abstract activities to execute in the real world, they have to use 'resources', which are essentially the resources of the enterprise. Examples of these resources are the mobile network, design documents, people in the CRM department, the billing system, the inventory database, the CRM system itself and so on.
The technical purpose of the workflow server is to aggregate available interfaces in the enterprise and combine the use of these interfaces together within a flow of execution.
The "ideal" purpose of the workflow server is to motivate other developers in adopting the open standards mentioned above and as another resulting purpose it will clarify to non-technical people that enterprise software does not have to imply excess expenditure on migration projects when certain systems are replaced (especially systems at the heart of a corporation are very liable to these projects).
The workflow server also serves a personal goal in my personal development and a challenge in the voluntary collaboration of developers having a common goal in mind.
The procedural purpose has already been touched on slightly in the business purpose, but there are more things to add. When I talk of procedural purpose I am talking about maintenance of the business flow itself, maintaining an eye on the business flow and especially maintaining an eye on failure conditions where these occur.
I see the procedural purpose and gathering of statistics of high importance for a company. The knowledge of statistics of a system performance and weighing that against a system's importance gives a company the ability ( or rather the financial department ) to make decisions on improvements and budgets to do so. What this effectively means is that by using the workflow server and analysing the statistics that it generates it will become possible to analyse the performance of individual systems within the corporation. Next to these positive possibilities, it is also possible to analyse and review the processes themselves and subsequently the ability to improve these business processes.
Another feature of the workflow server is the fallback methods that are possible (or fallback processes). The workflow server can resolve to other paths of execution if a resource is scheduled to go down. If no paths are found, depending on the priority and the required timing of the process, the downtime is automatically escalated to an appropriate level. This may mean for instance paging, SMS, email, signals in the adminstration tool or possibly SNMP alert support.
The workflow server itself is a very technical system, but the use of this system can easily be simplified through the use of Graphical User Interfaces. This means that users can logon to the system, identify themselves and communicate two-way. This means for example that the user can request processes to be started, but also the server can advise the user that certain activities are waiting in a queue to be completed.