INTERACTION PROFILING AUDIT TRAIL PROVISIONS
Every system that tracks or processes any kind of business interaction / transaction should contain auditing capability that records who did what to which transaction and when and possibly even some kind of outcome if the business requires that level of detail. As most of us developers tend to dislike designing and coding this kind of functionality more than once, it makes a lot of sense to do it in a generic manner initially and just drop it into every new application. We will do this with our interaction Profiling framework, as we need to put this information into the database anyway for a more important reason. We wish to be able to evaluate the workload in progress, allocate processes to the least busy person who is authorized to perform the task, spot bottlenecks before they become a problem, have our staff know what is getting close to the target completion this week, provide the management with live statistics on throughput by User and by organizational section, reward over-achievers and assist under-achievers and provide fancy graphical statistics at the push of a button for inclusion in annual reports and for senior management review.
Figure 5 following presents the prototype approach to the audit trail content required in an Interaction-Profiling-based application framework. Click the graphic for a clearer image.
This design is deliberately rather simplistic in nature, as the prototype purpose was to test the feasibility and performance of an Interaction Profiling framework and not to provide a real-world capable business transaction processing system. However, I find simpicity is an elegant and efficient goal to strive for in every system I design. In the prototype, the basic audit trail requirements for an application are met, as are the needs for the assessment of User workloads and the ability to include workload balancing across the enterprise as desired. The “UserInteraction…” terminology is a generic representation of what would be application-specific in an actual implementation. The Interaction Profiling prototype referenced in this series of posts is actually a hypothetical Sales Order Processing System (SOPS) – no irreverence intended, ahem. The UserInteraction table would most probably be named something like, “UserSalesOrders” in an actual, production Order Processing application. This table records the assignment of Users to interaction instances (Sales Orders in the prototype). This is the record of which User worked on what transaction instance and when.
The UserInteractionProfileTask entity is the record of which BPM Tasks were performed by the User on what transaction as determined by the parent UserInteraction row (one-to-many relationship). This Task-level record provides the data for the existing workload evaluation for the workload balancing operations of the prototype. The precise evaluation of existing workload is somewhat subjective in nature, as there could be a small number of alternative algorithms. In the prototype, the task duration is recorded in days to 2 decimal places and represents the best estimate of the elapsed time for completing the task. This is not precisely the actual work effort, which is another approach that could be considered. In the real world, both aspects should probably be addressed and the algorithms could get more complex in assessing likely task duration based upon the existing workload.
The prototype system takes a fairly basic approach, simply identifying elapsed times. While this can be criticized as introducing some inaccuracy, it can also be argued that the elapsed time estimates are all relative and simply for the purpose of identifying the least busy User in the set of those Users who are authorized to perform a specific task, does provide an acceptably-level playing field for the assessment. The prototype evaluates the existing workload for a user as:
Where n = the number of tasks the user has in his / her “inbasket”. This is about as simple as it can get, yet still provide a reasonable mechanism for workload balancing. The approach could of course be refined as necessary in a production application.
Note that the example designs presented in this section assume that workload tracking and balancing would be performed at the Task level and not at the Activity level. This is another area where alternatives should be considered in a production Interaction Profiling framework. Depending upon the actual business requirements, it may well be unnecessary to provide a Task→Activity hierarchy, as the Task level may be all that is required by the business to manage the transaction processing workload. This is entirely dependent upon the complexity and characteristics of the specific business. Auditing and evaluating workload can be performed at either level, which would impact the actual framework designs in this area. The prototype takes a middle-of-the-road approach and provides the Task→Activity finer granularity, but the Activity tracking is purely for audit purposes. All workload-related evaluations are based upon the Task metadata.
For the purposes of this introductory paper, a basic Interaction profiling framework design is now completed. The actual prototype application database entity relationship diagram (ERD) is included in a subsequent section when the prototype metrics are discussed and analyzed. The next post steps back for a moment and examines the impact of Interaction Profiling on the work of the Business Analyst during the initial phases of a custom application development project, specifically, what should be included in the User Requirements and Conceptual Design stages.
Previous Post: Better BPM – 5 Interaction Profiling Security Model