INTERACTION PROFILING SECURITY MODEL
Every application needs appropriate security to ensure Users are only allowed to perform those business process tasks for which they are duly authorized and also functions in the application. An Interaction Profiling framework should include this functionality as it is endemic in every application. This means that we need to include User administration for the application within the framework. Role-based security is generally accepted as a very appropriate mechanism for authorizing groups of Users to perform various functions and business processes. So the framework should subsume both User administration and role-based authorization within the design. The following diagram in figure 4 presents the prototype designs in this respect. Click the graphic to view a clearer image.
The above design presents a master Task table and the many-to-many link table that identifies which Tasks are required for each profile, as was presented in the previous, Better BPM – 4 blog post. The User-definable roles are included and associated with the Profile Tasks via the ProfileTaskRole link table and also both to individual Users and optionally to organizational sections as required. Thus, via the role metadata, this design imbues an Interaction Profiling framework with the capability to identify exacty which Users are authorized to perform all of the various Tasks or processes that are included in each transaction’s matching profile metadata. Now we have the ability to perform automatic routing and workload balancing, as the framework “understands” the precise, unique sequence of tasks required to process a specific transaction instance based upon the matching profiles. It can identify the roles required for each BPM task and as the Users are assigned authorized roles, the set of Users who can perform each task. Authorization can be performed at User or Section granularity, or both, as required operationally,
The framework can apply the Task duration to calculate workloads and target completion times and this provides the information infrastructure to advise the respective Users and Section managers of their quantified workloads, impending targets, overdue transactions and bottlenecks, all of which is crucial productivity management information. Note that all of this information can be derived automatically based upon the Profile, Task, Role and User metadata in the framework. No on-going manual effort by any Users is required, as the information is derived directly from the framework metadata. How many case tracking systems or general business transaction processing applications provide this degree of managerial information automatically? Of course there will be some well-designed applications that can do this, but is their design fully re-usable?
Given that a picture is worth a thousand words, as they say, you can see the dramatic simplification that Interaction Profiling brings to a BPM application by clicking on the graphic at the beginning of any of the Interaction Profiling blog posts, including this one. The diagram depicts Microsoft’s Biztalk Orchestration Designer (the BizTalk workflow designer) with a partial schematic of a sequential timesheet approval process workflow, taken from MSDN on line. To the right is the Interaction Profiling, equivalent, BPMN 2.0, complete workflow model. The comparison clearly conveys the level of simplicity introduced by encapsulating all of the testing criteria within the object-orientated Profile definition metadata. The logic on the right really is all that is required in a custom Interaction Profiling application to run through all of the tasks for every type of transaction in an application. The completely generic profile matching logic, all in one piece of code (aso generic), applies all of the varying criteria as defined in the individual, user-managed profile metadata; no redundancy, no duplicated criteria testing, just simply identify the profiles that match a transaction.
I admit that this is somewhat oversimplified, as it is comparing apples and oranges. To clarify the intent of the graphic, the Use Case is timesheet approval requiring both project and resource manager approvals. The Biztalk, task-centric approach requires all the logical possibilities diagrammed as indicated. To switch the approval rule from AND (both Project Manager and Resource manager approvals required), to OR (either one is sufficient), Biztalk requires the process flow diagram to be modified by a specialist, recompiled, tested and staged into production. Interaction Profiling can achieve the same switch using an “Approved Timesheet” profile for the workflow implementation. The input row data could contain an “Approval Status” enumeration (application or calculated field) with values of 0 – Pending, 1 – Rejected, 2 – Approved By Project Manager, 3 – Approved by Resource Manager and 4 – Approved by Both. This field would be used as a Profile Attribute for this profile and a User simply changing the profile attribute definition metadata from 4 to the from/to values, 2 – 3, would achieve the same result.
With Interaction Profiling, it would also be as easy for the Users to create a profile for overdue timesheet approvals and select that profile for reporting on overdue approvals without ever involving IT. This is just one approach of several, equally simple, User-maintainable solutions using Interaction Profiling. The key thing to understand here is that the Interaction Profile metadata controls the processes that are required, their sequence and which profiles can perform what processes. There is no need for complex process logic diagrams for operational processing. The BPM diagrams are still required during the initial investigations of course, to derive the Interaction Profile metadata in the first place. Biztalk can still be used for all of the other benefits it provides, but the process diagram(s) would be much simpler as all decisions are based on the profile metadata.
The workload balancing functionality requires that the Interaction Profiling framework be able to identify existing workloads, so it is necessary to include this in the design. As one of the main purposes for any business processing transaction application is to monitor and control the processing of the transactions throughout their lifetimes, it is always an essential requirement to record which transaction instances are assigned to which Users, what their status is and to maintain an audit trail of what was done to each instance and by whom. The audit trail designs presented in the next blog post address these requirements.
Previous Post: Better BPM – 4 Table-Driven BPM Designs