Better BPM – 8




Throughout this series, reference has been made to the first, real-world implementation of generic Interaction Profiling in the form of a fully-functional, prototype Sales Order Processing System, SOPS. In the interests of brevity, this post will present some of the more pertinent aspects of the prototype, focusing on the functionality and benefits implicit in the Interaction Profiling approach. A Microsoft Access Data Project (ADP) was used as the graphical user interface (GUI) mapped directly onto a Microsoft SQL Server 2008 database server. This combination of technology is very powerful, fast from a development perspective and provides plenty of intrinsic functionality, particularly for the GUI. This shortens the development timeframe considerably (the main reason for its selection). Although very scalable (unusual for Microsoft Access), it is not suggested as suitable for large scale operational deployment, as it is being deprecated by Microsoft after Office 2013, but it is an excellent, iterative prototyping tool set. Figure 6 following presents the simplified SOPS Sales Order initial data entry screen.  Click on the graphic for a clearer image.



First, a few comments on the form itself. The prototype SOPS allows the Users, to select from three data content options – Incomplete Orders only (the default), Completed Orders and All Orders. The current selection is available in the window title, Incomplete Orders Only in the screen shot. The remaining screen data is fairly self-explanatory and is basic, given the prototypical nature of the application. The highlighted “Profiles” list box warrants serious consideration, however. It reflects the contents of the SalesOrderProfile table, which is actually updated by this form when data is changed and the list box refreshed. The list of Profiles completely classifies this interaction instance (transaction) in every characteristic relevant to the validation rules and the BPM task requirements. No User action was required during data entry. SOPS performs the Profile matching behind the scenes and this list of definitive characteristics is the immediate result.


SOPS uses a business rule that any transaction more than 10 days within the system (calculated as today’s date minus the date received on the Order, in days) meets the single criterion / profile attribute (in this instance) for the Overdue Orders profile and accordingly that profile is included in the list. Similarly this Order only contains one product, which is categorized as a Feline product and also food, so the appropriate profiles also appear because of the profile definition metadata. The specified client has a Customer Type of “Veterinarian” and a Trade Type of “Wholesale”, so those profiles show up also. As you can see, a lot of classification work is performed automatically by SOPS every time an Order is entered into the system. So once initial data entry is completed, SOPS already knows exactly how to validate and process every individual transaction.


Of even more significance, though, is the effective encapsulation, within the profile metadata, of all the complex criteria testing, which typically is performed numerous places throughout flow diagrams or declarative specification or application code or some combination of the three. The profile attribute criteria is specified in one place and that controls the validation rules and the BPM logic throughout the complete application. Thus, all redundancy in logic specification is eliminated. SOPS currently only applies Interaction Profiling to the validation and BPM logic. However, the concept could easily be extended to cover anything that could be considered profile-related as opposed to Customer or Product specific. For example, SOPS allows a discount percentage to be applied at the Customer level. A profile-related discount structure could easily be implemented by adding a Discount percentage to the Profile table and applying both if they are present. SOPS does not have this functionality, but anything that makes sense to be Profile-related could be included, depending upon the business requirements. Again, another big advantage of the Interaction Profiling approach is that there is NO redundancy in the data. If all Retail, Large Box Store clients are to receive a rebate or promotional discount or whatever, the specification would be performed once only at the profile level and not, as would be necessary otherwise, by hard coding the logic wherever necessary, or updating every single Customer record with the limited duration promotional data, which would require considerably more manual effort. This is dynamic classification and re-classification, as required, by the Users themselves of their Client or Product base for any purpose whatsoever – a very powerful concept!


From the flexibility perspective, Interaction Profiling provides a huge simplification for any kind of new program implementation. Just create a single new profile with the Attributes and defining criteria, run an administrative, global update of all profile metadata (SOPS includes this capability on the Administration menu) and immediately you see a new classification specifically for the new program on every relevant transaction within the system, with no IT involvement. Removal is just as easy. Obsolete the single profile metadata (changing one field on one record), run the global update and all trace is gone (except for the audit trail of activity that occurred while the profile was active). This flexibility to tailor Interaction Profile(s) to any combination of defining criteria is enormously powerful and eliminates a huge amount of maintenance that would be required with less flexible design patterns.


All of the profile metadata resides in the database. Maintenance of the metadata is performed through relatively easy to use data entry forms (exemplified in the next blog post). This gives the Users full control at their fingertips, with minimal involvement from IT. Combine this with the advantages cited previously and remembering that all of the actual Interaction Profile matching logic is generic and completely re-usable and the benefits clearly outweigh the one-off overhead of implementing the first, business-specific, Interaction Profiling framework. There is a slight, runtime performance impact introduced by the profile matching algorithm which has to be run whenever the transaction data changes. However, the performance impact of the prototype is negligible, even when running on a 6-year-old laptop. The development and maintenance cost savings (which are tentatively estimated to be as much as 50% or more reduction in all future development effort and 33% less annual maintenance going forward) might well be considered pessimistic and certainly outweigh the initial overhead.  The next post will demonstrate that it is truly quite feasible and relatively simple for the Users to maintain the profile metadata themselves with little or no assistance from IT.


Previous Post:  Better BPM – 7  Determining Interaction Profiles for an Application

Next Post:         Better BPM – 9  Profile Metadata Maintenance


Leave a Reply

Your email address will not be published. Required fields are marked *