|
|
|
|
|
|
|
|
|
|
|
|
|
Best Practices in adding an eProcess workflow tier
Why create the workflow tier infrastructure: Migrating from a 1-tier architecture to n-tier
Some older legacy systems were built with a 1-tier architecture. This means that within the same application all parts of the application were intermixed within the code. The application would have user interface components side-by-side with database and business rules
As technology changed, the problems with 1-tier applications has become clear. Users were unable to easily change the database and user interface tiers without significantly re-writing the business logic. It has become apparent for large companies that migrating to a 3+ tier architecture is essential for the long term survival of a custom solution. The bigger the application the greater the need for more clearly defined layers in the architecture.
By creating a workflow tier a company has essentially avoided hardcoding workflows into one of the other tiers. By creating a workflow layer, we will gain the added flexibility easily customizability that a tier provides. We will gain improve manageability of the workflow tier by extracting the layer. For example, when the end user requests changes to the workflow, by creating a specific workflow tier and thus isolating the responsibility of workflow the resulting code changes will be minimized to just the workflow tier. The impact on other tiers will be minimized.
How would the workflow tier look in relationship to other tiers
There are many ways that a computer application may be divided into tiers or logical layers. Keeping good Object Oriented design in mind with using a reusable, component based approach, we propose the following structure be created:
*Presentation layer: displays the user interface components.
*Application or Business Logic layer: contains the business rules for the application.
*Routing or Workflow layer: defines, creates and manages the execution the flow of work. This includes interpreting routing instructions and interacting with the other tiers.
*Data layer: holds all logic for connectivity to any databases.
Each layer should be hidden from the other layers as much as possible. Each layer will have an interface component that acts as the Glue that links each layer to the others. The workflow group proposes creating a standard interface that will allow anyone in other groups to interact with the workflow engine. There may be the need for other additional layers depending on the need of the company.
|
|
|
|
|
|
|
|
|
|
|
|
|
