TABLE-DRIVEN BPM DESIGNS
The fourth post in the Interaction Profiling series is where we examine the basic framework designs for making the management and maintenance of the BPM workflow metadata simpler, more user-manageable and yet more powerful at the same time. It makes considerable sense to use Interaction Profiles to manage BPM Tasks / Activities. The core differentiator that dictates alternative processing paths for business transactions IS the specific type of transaction, which is exactly what Interaction Profiling is designed to identify. Let us recall the formal definition for an Interaction Profile:
The set of attributes of an interaction (business transaction) that defines a distinct validation and business processing workflow rule set that is required to process that interaction.
Any implementation of Interaction Profiling will of necessity, by definition, produce a set of profiles that exactly match the user-defined taxonomy for their workload domain. This is why it is much easier for Users to manage their BPM workload using Interaction Profiling, as opposed to the much more complex task of maintaining voluminous, linear, graphical flowcharts, where the decision nodes delve into the detailed complexity of the application data model, or even worse, the maintenance has to be performed entirely by IT because the logic is mostly or all embedded within the application code. Figure 3, following, depicts the prototype’s design for tagging profiles with their associated BPM Tasks (and optionally the subsidiary Activities if a really granular implementation is necessary). Click on the diagram to see a clearer version.
This is a fairly basic design, providing many-to-many relationships between Profiles and Tasks and between Profile Tasks and Roles and between Tasks and Activities. This is how the initial prototype is implemented, but of course this can be modified to suit the real business requirements. Also, the granularity of the BPM Task management and auditing should be determined. Depending upon the business size and complexity, a single level (Task or Process in my terminology) may be all that is necessary. Alternatively, decomposition into Activities (sub-processes), as in the existing prototype above, might be optional or essential. The auditing requirements are dealt with in an upcoming post, but a decision is also required as to whether auditing is required at the Task or Activity level. The prototype designs in these posts provide both Task and Activity tracking but the process management is performed at the Task level and the Activity level is purely for auditing (who did what to which transaction and when).
The TaskType in the prototype identifies automatic tasks (implemented via the AutomaticFunction or AutomaticSQL fields), as opposed to the Manual business processes. This allows for automated functions or SQL or a code snippet to be called as Tasks in the transaction lifecycle for such things as emailing a notification or whatever is required. Similarly, the WorkflowType identifies whether, 1 – the process is optional, 2- at least one such task at this sequence number (as there could be parallel tasks) is mandatory (i.e. will block subsequent tasks), or 3 – all tasks at this sequence number are mandatory and all must be completed before the next task in sequence is performed. This logic could be adapted as required. For example, other enumerations could allow for User Override of these constraints or not depending upon the specific Task. Note that these enumerations can be overriden at the profile / task level if necessary.
To clarify the way workflow is implemented with Interaction Profiling, any task(s) that are dependent upon (only required for) a specific profile are tagged against the profile(s) in the metadata. Therefore they will only appear in a workflow if there is a profile match with the current transaction. The sequence number controls the order in which the tasks are allocated (or executed for automated tasks). The Task Workflow Type is used to differentiate between optional (non-blocking) tasks where the User will be given the option to include the Task for the current transaction, those that block the workflow until completed and parallel processes (same sequence number) that are either all mandatory, or at least one must be completed before the workflow can proceed, as explained above. This enumeration can be extended as necessary for other BPM workflow possibilities. The object-oriented approach in Interaction Profiling means that a Task can contain the exact properties that result in the workflow behaviour that task should have. This all has to be considered in the initial framework design.
The inclusion of the Role-related entities empower the application to categorize every task against the User-maintained Role taxonomy, enabling restriction, as necessary, as to what roles are required to perform each specific Task. The Security designs in the next post associate the Users, individually or in organizational Sections, with the roles for which they are authorized. This provides the framework infrastructure that determines precisely which Users are authorized to perform each Task dynamically at runtime. This control is applied at the Profile / Task level automatically. This allows automatic transaction routing and, given the ability of the framework to determine workload based on current Task assignments and Task durations (see below), even workload balancing across the Organization to optimize throughput and minimize overtime.
The field content is fairly self-explanatory. The Task duration is included which facilitates a significant extension in functionality and managerial capability. A later post on auditing requirements delves into this aspect in more detail. On a practical note, the prototype includes a “UseSameUser” boolean flag (on the Task table) to provide the option to override the standard workload balancing algorithm and force task allocation to the existing responsible User, provided of course, that the User is authorized to perform the task (described in the next post on security designs). This type of optional functionality would probably be included or excluded, based on some kind of application-wide configuration setting in a fully re-usable framework.
Unlike the validation rule set designs, this BPM design does not provide a default set of Tasks on the assumption that the Task table contains all possible Tasks and there is no likelihood of requiring all possible Tasks in any of the production Interaction Profiles. Accordingly, the implication is that all transactions must match at least one Profile for this BPM design to function correctly. This implies that a default Profile might be required should this situation arise in the real world. The prototype uses this approach, containing a “Default Profile” which has a single criterion that always produces a “true” result, thereby matching every transaction. The Default profile is also a logical choice for the association of any workflow tasks that are always required, either optional or mandatory, if any such exist.
It may appear to be a tad redundant to associate every profile with the validation rules and business processes as many will repeat information similar to other profiles. However, the ProfileTask link table is tiny and the number of profiles will always be a relatively small, finite number, certainly at most low order hundreds. It is a more object-oriented design, however, as the validation rules and processes can be viewed as properties and methods (accessors and modifiers) of each profile object instance. Both the field rule overrides and BPM processes only appear against the profiles where they are required. The validation and BPM rules are effectively encapsulated by the profiles as far as the application logic and code is concerned. This eliminates all redundancy in logic specification for validation and for BPM processing, which is otherwise often littered all over process diagrams and code in other design approaches and implementations. Interaction Profiling determines the exact validation and BPM requirements automatically, simply by matching each transaction against the profile metadata stored in the database.
The validation rules are only present if they override the default validation rule set for a specific application field as stored on the ApplicationField table (see previous post on Table-Driven Validation Designs). The prototype application includes, as you might expect, buttons to clone both the validation and BPM rules from an existing profile when entering a new profile metadata. The prototype performs extremely well despite the slight overhead of matching transactions against the profile definitions whenever transaction information is entered or modified. Storing the validation rules and business processes in the database makes modifications to both data a simple, user-manageable, data entry operation, which is orders of magnitude better than changing complex workflow diagrams or even worse, application code. The next post will look at the BPM security aspects and extend the above base designs to include User administration and security requirements.
Previous Post: Better BPM – 3 Table-Driven Validation Designs