Prototype Design Framework Scope and Metrics
This post, the eleventh in the interaction Profiling series, presents and analyzes the SOPS Interaction-Profiling-enabled prototype system framework functional scope and application object metrics. An analysis of the re-usable components (that therefore represent the Interaction Profiling framework) is performed and statistics provided showing the high-level of re-usability attained.
The content of an Interaction Profiling design framework should include any best practices that have been identified in an organization, or are generally recognized as optimal approaches to certain aspects of functionality that are commonly required in commercial applications. Despite the prototypical nature of SOPS, the framework includes some standard functionality over and above that purely related to the Interaction Profiling concept. The User administration and Role-based security is a prime example of this, given that it is not a strict requirement for the use of interaction Profiling to encapsulate validation rules and BPM tasks within an application. The application of profiles for simplified ad hoc reporting is another example. Another inclusion, as best practice, is Service Level Agreements (SLA), as these are ubiquitous and almost always involve some kind of priority-based turnaround promises, which ties in with the interaction Profiling approach nicely.
Other common requirements that the SOPS re-usable framework provides are report filtering, audit trail and optimal lookup handling. The last item is an oft-mistreated set of functionality when, with a bit of extra design effort, a re-usable, single-form, table-driven approach can simplify the maintenance of the multitude of drop-down combo box style reference, code-value lookups that appear in every application. The lookups are used in the data entry interface and for validation of accuracy in electronic input containing coded data. The full details of the SOPS Interaction Profiling, re-usable framework is more properly fodder for another article and it is beyond the scope of this post to delve any deeper, other than to summarize the functional scope in bullet form below:
- Input Validation
- Business Process Tasks and Activities
- Automatic Task Allocation and Routing
- Workload Balancing
- Service Level Agreements
- Target Dates and ETAs for Clients
- Bring Forward Reminders for Staff
- Accurate Completion Estimates
- Bottleneck Detection
- Productivity Metrics (Target versus Actual, Gap Analyses)
- User and Role Administration
- Application and Business Process Role-Based Security
- Optimal Lookup Handling
- Report Filtering
- Simplified Ad Hoc Reporting
- Audit Trail / Activity Log
Not many (if any) existing BPM products provide all of the above items (inherent in the prototype Interaction Profiling framework) in a relatively simple, re-usable and truly User-maintainable manner. Where items are provided, they are typically not implemented in an object-oriented manner with the logic encapsulated in one location and referenced where required simply using a generic piece of matching logic, as in Interaction Profiling. It is also considerably easier, I believe, for the Users to maintain the metadata in the database, as was demonstrated in the illustrations in post number 9.
Any future application can be jump-started using this framework and all of the above tested functionality will be provided with absolutely minimal development effort. This is where the development effort savings accrue. The on-going maintenance savings are the result of the object-orientated encapsulation of the validation rules and BPM data in an easy, user-manageable, table-driven format. New programs and promotions etc. can be introduced with no IT involvement. Many commercial applications typically require significant IT maintenance effort in these situations.
Finally, let us look at the prototype metrics and assess just how much of the application design is fully re-usable, allowing for some minor modifications (table and field naming mostly). Figure 25 following quantifies the relevant statistics for the SOPS implementation.
The SOPS hypothetical order processing prototype is a relatively small to medium – sized application system. The order processing designs are rudimentary (only three main application-specific tables), but the overall application contains over 50 tables, which is representative of a small commercial application system. The most highly significant statistic, however, is the determination that a full 74% of the developed objects (client GUI forms, pivot charts, queries, application code, reports, SQL Server tables, views, stored procedures and user-defined functions ) can all be re-used next time around. This implies that a second, similar – sized application would only require approximately one quarter of the development effort that would otherwise be required. It is true that a small number (around 9 estimated) of database tables in the framework would need to be modified very slightly between applications. The “UserInteractionxxx” tables referenced earlier are examples where some of the field names might be changed or additional information included. The conceptual purpose of all of the framework tables, however, would remain the same, so any such modification would be simple to do.
Figure 26 below presents the entity relationship diagram for SOPS. Lookup, code / value, reference tables are not included. The highlighted area denotes the three, application-specific tables. All other tables are the re-usable framework. Click on the graphic for a clearer image.
The next and last post in the Interaction Profiling series Presents summarized conclusions and a final wrap-up of the Interaction Profiling design paradigm as described in these 12 posts.
Previous Post: Better BPM – 10 Prototype Sample Screens and Reports