About Barrie Gray

Barrie Gray offers an unusual blend of information systems expertise combined with a very comprehensive technical knowledge and excellent report-writing skills. He has in-depth experience in information systems consulting, project management, systems and programming management on mainframes (15 years) as well as over 30 years technical experience with mini- and micro- computers (PC LANs and Windows 95/98/NT/XP/2K/2003/XP/7 being particular foci). Mr. Gray is currently president of his own company specializing in information systems consulting and the application of Microsoft and Internet/Intranet technology to federal and commercial business. Recent work includes a comprehensive Case Tracking / Investigation Management solution design, development and implementation using SharePoint Portal Server, plus Visual Studio .Net, VB.NET, C#.Net, ASP.NET. Other projects include client-server, web-based and RAD (Rapid Application Development) technology on LAN and WAN (Windows, SQL Server, Oracle) platforms. Mr. Gray has had numerous technical articles published on OOP (Object-Oriented Programming), development tools (Visual Basic.Net, C#, Access and C++) and Windows NT/2000 in Computing Canada. Midland Microcomputers Limited also offers a comprehensive, business planning and performance management product (BMS) which is in successful operation in two Government departments, a browser-based, scheduling information database (EasiDB), plus technology for bilingualising Visual Basic and MS Access applications.





This is the final post in the 12-post, Interaction Profiling series.  It summarizes the previous 11 posts in a recap and presents a set of conclusions for consideration.


The first introductory post in the Interaction Profiling series outlined the concept and promised the benefits that are cited in the summarized conclusions below.  Hopefully, if you have browsed through all prior 11 posts, you will concur with these conclusions.  The designs for the Interaction Profile metadata and the persistence of the validation and BPM data in the database was the focus of posts 2 through 4. The designs are relatively simple, but the table-driven designs make maintenance a simple and User-managable task with little or no involvement from IT.


Security and Auditing were detailed in posts 5 and 6, integrating the Interaction Profiling framework with User and Role administration and incorporating the ubiquitous requirement for an audit trail within the framework.  These designs are also simple, yet they provide so much capability to an Interaction-Proiling-enabled application.  They extend the business process task management with capabilities that include workload balancing across the Organization, automated transaction routing, and much more as described below.  The business managers are also enabled with User-maintainable profile-level programs and reporting that can be simple and quickly implemented, again with no IT involvement.


Post 7 took a very brief look at the additional work for the BA during the investigation and design project phases, that is implied by the Interaction Profiling paradigm.  Although there is an enforced need for greater detail in BPM investigations and the validation rule determination, this is a good thing.  The quality of the User Requirements will be enhanced by this more rigorous approach and the risk of failure will be mitigated as well.  There is more work required in this area to formalize and merge the Interaction Profiling metadata with the functional and data specifications for a new system.


Posts 8, 9 and 10 took a closer look at the first Interaction-Profiling-enabled application, the hypothetical Sales Order Processing System, SOPS.  The actual, relevant application screens were depicted with explanations that demonstrated the simplicity of the metadata maintenance and substantiated the claim that the User community would be quite capable of undertaking this job.  The tenth post also presented the actual BPM screens. Although not obviously enhanced by Interaction Profiling, the actual required task sequencing and allocations for every transaction are all automated (with User override as necessary).  The reporting in the prototype is also illustrated showing the use of report filtering using a profile dropdown as one of the criteria, both on the general report filter screen and in all of the pivot chart style reports.  The capability for simple, easy-for-the-Users ad hoc reporting is also introduced, as the profile attribute definition criteria provides this capability out-of-the-box.


The previous post, 11, documented the prototype application metrics and indicated the considerable scope of the interaction Profiling framework, which is at least as good as, if not better than, existing BPM software in terms of actual benefit to the Organization. The post also analyzes the application development objects and highlights the impressive (at least in my somewhat-biased opinion) statistic that almost three-quarters of SOPS is included in the fully re-usable Interaction Profiling framework.  The prototype database design is also presented, again indicating the significant portion of SOPS that is a re-usable Interaction Profiling framework.


Based upon the preceding material and analyses, the following conclusions are proposed for consideration.

  1. Interaction Profiling provides a quantum leap forward, simplifying the approach to BPM within an Organization.  The re-usable framework provides considerable functionality to subsequent applications once the initial framework is constructed or acquired.
  2. The encapsulation of the validation rules and BPM logic in a table-driven manner empowers the Users to take control of their business processes in a much more comprehensive and comprehensible manner.
  3. Interaction Profiling effectively provides business-relevant control at user-definable profile levels.
  4. Much code and data redundancy is eliminated as information can be recorded at the profile level.
  5. Operations such as transaction routing, workload balancing and monitoring, task sequencing, bring forward reminders are fully automated, eliminating manual delays, errors and omissions.
  6. Service to Clients can be improved with improved efficiency and accurate completion estimates.
  7. Managerial control is greatly enhanced, with workload monitoring, bottleneck detection, productivity reports, trends, gap analyses and annual reports, graphs and pivot tables, plus marketing, communications and new programs that are easy to implement at user-definable profile levels.
  8. Reporting is facilitated by intelligent filtering, including profile-based breakdowns.
  9. A truly simple ad hoc reporting capability is inherent in the Interaction Profiling concept.
  10. Future application development effort will be reduced significantly, possibly as much as 50% or more.
  11. On-going maintenance costs will also be considerably reduced because of the flexibility and User-maintainability inherent in the Interaction Profiling concept. This is conservatively estimated at 33% on-going, after the production of the first framework.
  12. The concept is implementation neutral. Desktop, browser and portable device applications can all benefit. It is also transparent to the design paradigm whether a system is cloud-based or not.


Interaction Profiling is a brand new concept. It is in its infancy, yet the first prototype clearly demonstrates that the potential benefits are significant, not just to BPM but also to other, common application system features. Questions, comments, criticisms, suggestions and any other feedback is welcome.


All Previous Posts:

Better BPM – 1  Success Through Simplicity

Better BPM – 2  Interaction Profiling Definitions and Design

Better BPM – 3  Table-Driven Validation Designs

Better BPM – 4  Table-Driven BPM Designs

Better BPM – 5  Interaction Profiling Security Designs

Better BPM – 6  Interaction Profiling Auditing Provisions

Better BPM – 7  Determining interaction Profiles for an Application

Better BPM – 8  Sales Order Processing Prototype

Better BPM – 9  Profile Metadata Maintenance

Better BPM – 10 Prototype Sample Screens and Reports

Better BPM – 11 Prototype Design Framwork Scope and Metrics



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.


Prototype Scope


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.


Prototype Metrics


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

Next Post:        Better BPM – 12 Series Conclusions and Wrap-Up

Better BPM – 10





This tenth post in the Interaction Profiling series focuses on the SOPS Interaction-Profiling-enabled prototype system functional forms for BPM Task and Activity maintenance and illustrates some of the output reporting capabilities of SOPS that are enhanced by Interaction Profiling features.


Sales Order Inbox


This form (click on the graphic to view a clearer image) is used by Supervisors and Order Processing personnel alike. This view is that of a Supervisor who can see the work for anyone in their span of control. The SOPS prototype application does not actually have this functionality built in, but the Interaction Profiling paradigm enables this capability with the existing metadata.  A production implementation would have this ability included and it would not be hard to implement – just an additional field on the User table for a “Manager” foreign key field and a bit of additional logic in the stored procedure that populates the data grid. The legend explains the colour coding the users requested – Urgent orders at the top in red, followed by yellow overdue orders, then orange for Out of Stock, back-ordered Sales Orders. The remaining orders are then listed in ascending target date sequence, so the more critical appear first.  A form like this could be displayed automatically on signing in to SOPS, so Users can see their priority workload at a glance.


This form can be used to allocate / reallocate tasks to any of the orders. Just as for allocation of orders to Users on the Sales Order form, the Supervisor is able to specify a specific Task (and optionally a User), or simply allow SOPS to decide the next Task automatically for them (which is the normal case). If a specific Task is specified, SOPS checks that it is valid for the profile set that currently applies to the interaction instance. The User can update the order status in this form and can launch either the Sales Order form (previously illustrated), or the Tasks log which is shown below, for the selected Order in the grid, depending upon what changes they want to make to the order information.  The form offers the User various filtering capabilities using the dropdown boxes and check boxes at the top of the form.  The most important matching profile is displayed in the grid and of course a profile dropdown is included as one of the possible filtering criteria.


Sales Order Task Log


This is the form used to manage the specific business processing tasks for the Sales Orders. Please click on the graphic to see the details clearly. Tasks can be allocated / reallocated and SOPS will automatically determine the proper task, unless the User decides to override the default allocation at either the User or the Task level.  The Task Log form is a “split form” where the user can select a row in the bottom grid and see all the fields in the upper part of the form, some of which can be edited.


Note that the Task database table and the ProfileTask table both contain a “UseSameUser” boolean field. If set to True for a specific Task (which is the default), SOPS will allocate tasks in sequence to the same user already working on the preceding task for the Order, as long, of course, as that User is authorized to perform the new task. This gives Users the option (by setting the UseSameUser flag to False) to force SOPS to pick the least loaded User from all of those Users authorized to perform the new task. Typically, this would be used in those cases where the next task is performed by a different organizational unit from the one processing the current Order task. Optionally, SOPS Users can decompose Tasks into constituent Activities, although this may not be required in practice ( if it is considered too granular and complicates operational management, depending upon the characteristics of a specific business). In the prototype, the last Order Processing form in SOPS is the Activity Log, which can only be reached from the Task Log form described earlier and is shown below.


Sales Order Activity Log Form



This form, figure 14, is the Activity Log used to manage Task Activities in detail.  The activities for the specific Order Task selected in the Task Log, from which this form is launched, are shown and can be edited and inserted here. The Activity dropdown in the grid only shows those activities specific to the Task indicated at the top right of the form. These Activities are determined by the content of the TaskActivity database table for the specific Task concerned. Of course, the Interaction Profiling concept defines the set of Tasks for each Order as part of the functionality of the Task Log form.  A User can select a Task Activity from the dropdown in the grid, Start date will default to today’s date. The User can select “Completed” from the Status dropdown and SOPS will enter the completion date, so it is simple and quick for a User to update the individual activity status as the work is performed.


Report Filtering Capabilities


When running any of the built-in SOPS reports, if the User chooses a report from the Reports menu that requires parameters, the report filtering parameter form is displayed:



Ten of the fifteen reports currently available in the SOPS prototype use the above form to filter the report content. The filtering capabilities of course depend entirely upon the Users’ reporting requirements and it is up to the individual designer to adapt this approach in any application implementation. Nevertheless, the options available in this basic filtering form are quite powerful and when combined with the “slice-and-dice”, “drill-down” pivot chart reporting features that come free with Microsoft Access when used as a GUI for a SQL database, offer a truly impressive management tool. This is purely my opinion of course, but to some extent you can judge for yourself after reviewing the material in this Post.


On the filter form, the User can specify  a date range and various other criteria which will then apply to the execution of the subsequent report.  This form is one of the forms in the framework (if included, which it should be) that will need some customization between applications, as the application field filters will clearly change from application to application. With regard to Interaction Profiling specifically, the Profile dropdown criterion allows the User to restrict the report content to a specific profile. This is important, because the Users can define profiles that are specifically only used for reporting. This gives the User almost an Ad Hoc reporting capability, given the power of the attribute specification that is available in SOPS for profile definitions. As an example, I created a Reporting profile for Retail Clients with Orders in excess of $500 total order value. I used two attributes – TradeCategory set to retail and OrderValue set to $500+. Another Reporting Profile allows reports to be restricted to Walmart orders only that have been over 60 days in the system. The Client and AgeInSystem Attributes were all that was required for this ad hoc request. These filtering capabilities are not that extensive, but the IT support requests for new or modified canned reports will be greatly reduced nevertheless by the functionality provided and that is our goal as designers and developers – to give the Users what they need.


There is one minor wrinkle in using Profiles for ad hoc reporting. The reports do NOT re-evaluate all Orders to determine the very latest profile state every time someone requests a report, because it would be too onerous on the system. The latest static data in the actual SalesOrder and SalesOrderProfile tables is used for reporting based on profile criteria. This means that if a new reporting Profile is created, the static data has to be updated prior to producing the report or it will not reflect the new profile. SOPS includes two functions for this that can be invoked from the Lookup maintenance menu – Re-evaluate ALL Current year Order Profiles and Re-evaluate Current Year Orders REPORTING Profiles. These options only take a few seconds to run actually on my laptop (which is also running the SQL database server etc.) In production, I would probably create a small batch job to perform this updating periodically throughout the work day. Now let us see what kind of reports are available in SOPS that avail themselves of the filtering capabilities.


Pivot Chart Reports


Microsoft Access, when used as a front-end GUI provides an impressive reporting capability. There is a very decent report writer available for the typical textual reports, plus a very powerful Pivot Chart / Pivot Table / Datasheet form capability that provides three different formats for inspecting the report data. The three formats are in the form of a “Drill Down” capability, starting with the graphical, Pivot Chart view that is identical to that provided in Microsoft Excel Charts. The Pivot Table view shows the summary data behind the chart in Pivot Table format and the detailed Datasheet view presents the underlying data in its raw form in a data grid.


What is impressive about these Pivot Charts is the highly interactive nature of the forms themselves. It takes a bit of practice (just as in Excel), but an amazing analytical capability is available simply by dragging and dropping field elements of the underlying data to different areas of the chart. Combining this with Report Filtering, Profiling and the Ad Hoc Reporting Profiles empowers Users to a degree that you rarely see in a production application. The slice and dice and drill down capabilities make it easy to display the data in several different formats and styles and anomalous data can be investigated by drilling down into the more detailed views to investigate the individual data rows themselves. Here are a few example screen shots of the Pivot Charts in SOPS. The underlying data are test data only for illustration purposes.



Please click on the graphic to view a clearer image. Let us take this pivot chart piece by piece. The Field list shown on the left is not normally displayed unless you want to change the data content in some way, but I show it in the example so you can see the specific fields available for analysis. The fields shown in bold in the list are already in use in the chart and the others are available for addition, or replacement of existing fields. This field list is simply the fields in the apHKAWPI_SalesOrdersRpt stored procedure that is the data source for the report form. The content of the field list is completely up to the developer of the report. Generally, the more fields the greater the functionality of the pivot form.


The value axis is the Total Order Value (total sales). There is a “# Products” field that could be used instead as the value if the User wishes. So this one form can display an analysis of either total sales or total number of products. The X-axis is actually Trade Category broken down by Customer Type (two fields – one nested inside the other). The Y-Axis is simply the Sales Representative – three persons in my limited test data. It is important to realize that these fields for the X and Y axes can simply be dragged and dropped either from the Field list directly if it is visible, or from the Field Set area at the top of the chart. The Field Set is initially populated in the same way by dragging and dropping fields from the field list to the field set area.


The Field set area fields enable “slicing and dicing” by clicking the small dropdown arrowhead to the right of a field set name and selecting from the dropdown list one or more specific values which are displayed. All distinct values that are in the data are listed, so this becomes a very useful feature for analysis purposes. Dates can be combined by Month, Quarter and Year at the Users choice. Any combination of checked entries in any field set can be combined with any other checked entries in any other field sets. This makes this one chart capable of answering many questions a user may have about the underlying data. In my experience, power users and any users familiar with Excel charting capabilities will love these pivot chart tools for analyzing their data. It certainly further reduces significantly the number of requests the IT support group will get for new and or modified, canned reports – the more so when combined with the filtering capabilities already provided in the Report Filter form. This same chart can be displayed in pivot table and in datasheet formats (top left View dropdown), as shown in the next two graphics.

Pivot Table:





As you can see, the interactivity, power and flexibility of these Pivot Chart report forms is incredibly useful to experienced Users, or those given a bit of special training in their use. Note that one of the Field Set fields is the Profile, which is completely User-definable (Reporting Profiles), so the analytical capability is quite mind-blowing. The imagination of the User is literally the limit.


The Pivot Chart is merely the first in the SOPS ten reports that are Profile and Report filter enabled. So let us quickly illustrate a few of the other prototype examples. The Sales Orders Products Pivot is similar to the preceding pivot chart, but displays total sales (or total products) by Sales Representative and Type of Product:SalesProductsPivot1_MISQ


Here are excerpts of a few of the simpler, canned text reports that show the kind of information you can get out of a system that uses the Interaction Profiling design model.

This simple bottlenecks report extract shows the Users’ workload from heaviest-loaded to lightest-loaded. This is possible because SOPS “knows” who is working on what tasks and how long each task should take. This is just one example. The same information could be used to derive many other statistics relating to productivity and workload, some of which are exemplified below.


The Overdue Orders report (below) uses the task duration information to derive a list of Orders for each User that have passed beyond their target duration in the system (i.e. are overdue). The Urgent and High Priority orders are highlighted in Red and Yellow respectively.



The next example below illustrates the “Bring Forward” capabilities of Interaction Profiling in terms of notifying Users of what is targeted to be completed in the next week.ImpendingTargets_MISQ


Obviously, this kind of information could be made User-specific automatically or by the Users selecting their name in the Report Filter form. The Impending Targets report could be displayed at login or in summary form in a dashboard, that is often a good design for Users when they first invoke a system. I like dashboards if they are well-designed, not too resource intensive and contain summary information that is directly useful to the User. Impending Targets meets these criteria, as does productivity information in summary form, notification of serious problems etc. depending upon the User’s role and business characteristics.
Figure 23_MISQFinally, let us look at a couple of other examples of Pivot Chart displays using the Interaction Profiling approach. The above pivot chart shows the completed orders sales in terms of number of orders and Total Value (in thousands of dollars in this example). Strictly speaking, this example, as shown, only uses Interaction Profiling in terms of filtering interactively using the Profile dropdown at the top, or dragging and dropping it to one of the axes to display an analysis by Profile. This is of course significant because the Profile classification is completely User-managed and almost entirely User-maintained. This example also shows the little tooltip that can be displayed by hovering your mouse over one of the columns in the chart. The information indicates the actual values relevant to the specific column selected. Here is a final example of the kind of graph that is often useful in quarterly or annual reporting documents.

This report breaks down the Total Sales for the period specified (quarter or Year) by Trade Category and Product Type. Of course these axis metrics can be switched in seconds to any of the FieldSet variables displayed at the top of the pivot chart. Again, the tooltip message is shown (displayed by hovering the mouse over the largest column in this example). I hope you can see how the use of Interaction Profiling as an approach, when combined with powerful technology such as these pivot chart forms, can provide amazing analytical capabilities for the Users and surprisingly little special training is required for Users to benefit from these techniques. Pivot charts just like in Microsoft Access are also available in Excel (where they originated) and in SQL Server Reporting Services (SSRS), which is now ready for prime time and provides similar capabilities for browser-based applications, as opposed to using Microsoft Office products on the client workstation. The next post presents the application metrics for the SOPS prototype and quantifies the percentage of SOPS that represents a generically re-usable Interaction Profiling framework..


Previous post:  Better BPM – 9    Profile Metadata Maintenance

Next Post:         Better BPM – 11  Prototype Design Framwork Scope and Metrics


Better BPM – 9




This ninth post in the Interaction Profiling series demonstrates the simplicity of the user maintenance aspects of the SOPS prototype application.  All of the SOPS Interaction Profile metadata is stored in the database following the designs presented in the earlier posts in this series.  The screens used for maintenance of this data are presented, commencing with the profile definition data, then illustrating the BPM Task and Role data and finishing wth the field validation form.


As an example of the profile metadata maintenance, figure 7 following, depicts a profile definition screen for one of the SOPS profiles. SOPS contains 23 profile definitions, plus 2 profile definitions used for ad hoc reporting, as Interaction Profiling, serendipitously, happens to provide an easy to use vehicle that gives end Users a really simple method of implementing ad hoc reporting in an application. All of the SOPS profile definitions are equally simple and contain minimal data. In fact all 23 non-reporting profiles are implemented with just one Profile Attribute and only the 2 demonstration ad hoc reporting profiles have more than one profile attribute (both profiles requiring two attributes). There is no doubt that this minimal degree of complexity is easily manageable by User supervisory personnel.  Click on the figure below to view a clearer image.



The above example shows the Profile Type drop down combo box, illustrating the four different Profile Types implemented in the SOPS prototype. Any Profile may be restricted to validation processing, or BPM logic or both, or be used for Reporting purposes only (ad hoc reporting essentially). SOPS provides filtered reporting capabilities and an Interaction Profile drop down is included on the filter criteria form that allows the specification of a profile for report filtering, together with other relevant application fields. All profile types can be used to filter reports. The profile type is used to optimize the profile matching logic, as only the appropriate types will be selected for matching, depending upon whether the purpose is for validation, or BPM, or reporting. If additional, profile-related functionality is designed into a framework, this profile type enumeration would have to be adjusted accordingly. The profile depicted in the example (Charity), is defined with the one criterion, Trade Category (one of the 15 profile attributes required in SOPS) having a value of “Charity”. This minimal level of complexity is clearly easy for Users to manage, although a non-production (User acceptance testing) environment would be required for initial testing. Note that the transaction value for Trade Category will default to Retail based on the example screen if the actual transaction value is missing (the Null default).


The profile attribute specification is equally simple, as most attributes map directly to an application field including the Trade Category. Here, in figure 8, is an example of the definition of the Trade Category profile attribute.



Only one prototype Profile Attribute could be considered tricky in any way and that is the Age In System, calculated Attribute. This is not really an issue as Profile Attributes are almost always defined during the development phase and the metadata will of necessity be created initially by IT developers for testing purposes. Figure 9 shows the details for this attribute definition.



Note that this attribute does not map to an Application Field, but is defined as a calculated formula. “Date() – CDate(‘%DateReceived%’). A few things require clarification here. The specification field, SQL Query, is somewhat misnamed, as SOPS allows either a Transact SQL Statement or an actual Visual Basic for Applications (VBA) code snippet / expression that returns a value. VBA is the language embedded in all Microsoft Office products and has been around for a couple of decades now. Although not considered an object orientated language per se, it is nevertheless extremely powerful and, given the use of Microsoft Access for the GUI, was an obvious choice for SOPS. VBA includes an Eval function that takes a string argument and executes it as VBA code. This is similar to .Net’s dynamic reflection capability, but somewhat simpler to implement.


The second point of clarification is the use of a tokenized string, “%DateReceived%”. SOPS implements this capability by parsing any tokens in any of the evaluation strings and replacing them with the contents of the current transaction’s field of the same name. Thus the %DateReceived% token is replaced at runtime by the current transaction’s field value that is named the same. The CDate intrinsic VBA function converts the string argument to a DateTime value. Thus the statement shown above is evaluated as today’s date (the date() intrinsic function) less the DateReceived field on the current transaction converted to a Date value. VBA returns this difference in days, which is exactly what we want for our Age In System attribute. As you can see, the field names are significant if a convention of this kind is used, so it would be a good idea to use easy-to-understand names for the transaction fields, given a few of the supervisory Users will be exposed to this conventional approach.  Now let us take a peek at the Tasks and Roles maintenance.


Figure 10 above depicts the SOPS maintenance screen for the Profile Task and Role data. Click on the graphic to see a clearer image. The top half of the form is a grid of the Profile Tasks for the profile selected in the top combo box.  The bottom half of the screen is a grid of the Roles that can perform the Task as selected in the top grid.  As you can see this is also simple stuff for a User to maintain.


The validation rule specification is a tad more complex, but is the only portion of SOPS where some limited involvement from IT might be required. The same tokenized SQL or VBA code evaluation can be performed and the use of regular expressions for character and format validation, plus search and replace functionality may require some small amount of assistance from IT support. Figure 11 below illustrates the SOPS field validation specification form.



If you click on the above image to enlarge it, It can be seen that the Discount Percent field (an entry on a product line item row) is validated to be 10% (0.1 value) for this Charity profile. Any other entry results in the User receiving an error message, “All Charity Orders should automatically receive a discount of 10%”. This is quite powerful if you think about it. Only characters 0 to 9, a period (.) and a % are allowed and the minimum and maximum values are 0% and 100% (1) respectively. All of this is quite manageable by a supervisory User and this is pretty much as complicated as it gets in the SOPS prototype.


The basic simplicity of all of these metadata maintenance forms clearly supports the claim that Interaction Profiling enables User maintenance of the metadata for profile definitions, validation rules and BPM processes, with very little need for support from IT.  The next post illustrates the utility of Interaction Profiling for operational BPM requirements, output reporting and ad hoc reporting in particular.


Previous post:  Better BPM – 8    Sales Order Processing Prototype

Next Post:         Better BPM – 10 Prototype Sample Screens and Reports

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


Better BPM – 7




Before we present more specific details of the first Interaction Profiling prototype system, it is worth making a few comments on the impact of this new approach on the work of the Business Analyst (BA) during the investigation and analysis phase of a project. In today’s agile, iterative-prototyping application development world, there is a reduction in the emphasis on initial investigations and analysis when compared with the older more traditional, “waterfall” approaches. The agile approaches are generally recognized as definitely an improvement over the older methods. However, it remains important to the overall success of a project to ensure that the real business needs are understood and addressed. Whole forests have been destroyed documenting the myriads of methodologies that have been used to perform User Requirements, Feasibility, Conceptual Designs and Functional Specifications. This section presents below suggested, additional, methodology-neutral investigations that become necessary for an Interaction-Profiling-empowered development project.


Essentially, Interaction Profiling introduces a need to expand the detailed derivation of the validation rules and business processes to include the following four goals when performing the critically important work of establishing high quality user requirements and producing a conceptually accurate, appropriate and efficient application data model:

  1. Specifically enumerate all of the validation rules, plus the business process tasks and their sequencing (generally documented in an Activity or Data Flow diagram depending upon which methodology and or tool is used). This is a normal part of the investigation phase of a development project. Interaction Profiling merely enforces more rigor and formal collation of information, which is a positive assistance to the investigation and improves the quality of the investigation results.
  2. Identify the factors (data fields ultimately) that cause variations in the validation and also the manual transaction processing tasks (as these are the candidate Profile Attributes); The goal here is to identify the taxonomy of the types of transactions, from the perspective of influencing the validation rule set and / or the business processes.
  3. Derive, refine and formalize the consequential set of Interaction Profiles required and the Profile Attributes that are associated with each of the enumerated Profiles.
  4. Derive the Roles we need to ensure we can implement our Task security to ensure only authorized users can be scheduled to perform each of the Tasks required. It is strongly recommended to make every effort to keep the list of roles as small as possible.


It is beyond the scope of this paper to elucidate exactly how this should be done, given the diversity of approaches used in the custom application design and development arena. As the application data model is usually evolving in parallel with the investigations and analysis, the Interaction Profile metadata will also evolve along with everything else that is being iteratively prototyped. However, with the intent of triggering some thought and hopefully discussion as to how this could all fit together, one high-level, logical approach to the initial investigation and analysis phase (user requirements and conceptual design) might be:

  1. Investigate user problems and information requirements – interviews, Joint Application Development (JAD) sessions, research, collation of problems and requirements by subject / issue.
  2. Gather and label samples of all documents and files used in the existing system(s) – during task 1 typically.
  3. Document business processes, paying attention to the existence of any divergence in the task sequencing for business processes related to the Interaction(s).
  4. Identify the exact conditions that determine each divergence in the sequencing of tasks for the interaction instances.
  5. Analyze the information gathered and perform a top-down, iterative design to conceptualize a solution to the problems that also addresses as many of the information requirements as possible.
  6. Derive the data model for the conceptual designs.
  7. Iteratively refine this data and functional model, preferably with a prototype and plenty of user involvement, to finalize the new system design (data and functionality).
  8. Now re-visit the analyzed material and derive / finalize the production set of Interaction Profiles needed for the system.
  9. Determine and agree with the Users the detailed Profile Attribute values (criteria) required for the Profile set.
  10. Also formally document and agree the security Roles required, keeping these to as small a number as possible.
  11. Define and agree / finalize the detailed, field-by-field Validation Rules for all the interaction types and their Profiles.
  12. Last but not least, (probably in parallel with 10 and 11), determine and agree the master list of distinct BPM Tasks (and optionally subordinate Activities) and the individual lists for the interaction(s) and each of the Profiles associated with the interaction(s).


Yes, this is a lot of work, but there is really no shortcut to the work required to derive high quality user requirements and a good conceptual design. Anything less will dangerously increase the risk of pathological damage to the application design right from the very beginning. Placing a more formal and definitive emphasis on the up-front investigations, analysis and design will mitigate the risk of failure, which occurs throughout the industry all too frequently. Essentially, Interaction Profiling will provide more structure and detailed definition on the outcomes from the initial project phases, reducing the somewhat amorphous nature of typical, existing user requirements’ specifications. A proven, re-usable Interaction Profiling framework will also add solid, tested functional components to any future projects in which it is used (at minimal cost after the first implementation).


The next post commences a more detailed examination of the first Interaction-Profiling-empowered, prototype Sales Order Processing System.  The ease of profile metadata management by the Users, the quantum leap forward in functional capability and output reporting improvements are illustrated in posts 8, 9 and 10. Post 11 will present the analysis of the prototype metrics, highlighting the significant percentage of re-usable framework represented in the prototype.  The final post (12) will provide a summary recap of posts 1 through 11, a set of conclusions for consideration and a final wrap-up of the complete Interaction Profiling series.


Previous Post:  Better BPM – 6  Interaction Profiling Auditing Provisions

Next Post:         Better BPM – 8  Sales Order Processing Prototype


Better BPM – 6




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 TaskActivity 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 TaskActivity 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

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

Better BPM – 5





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

Next Post:         Better BPM – 6 Interaction Profiling Audit Trail Provisions

Better BPM – 4




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

Next Post:         Better BPM – 5 Interaction Profiling Security Model


Better BPM – 3




This third post in the Better BPM series on Interaction Profiling presents a generic design for the persistence of the validation rules required in a business application in the application database.  This post introduces the simple designs that enable Users to maintain their own validation rules directly almost all of the time, with no support from IT, yet still provide an extremely powerful validation capability which will be included in an Interaction Profiling framework that can be re-used any number of times in custom application development.


Clearly, to perform detailed field validation, a system must contain the validation rules for each application field. Also, we need to be able to provide Profile-based overrides where necessary at the individual Interaction Profile – Application Field level. The actual validation capability can be simple or sophisticated, but the more sophisticated the implementation, the more involvement from IT support is likely to be required to maintain the validation metadata. This is a tricky judgement call and often will depend upon the level of sophistication of the supervisory Users who will be tasked with maintaining the validation metadata. Some, limited IT involvement is quite acceptable in most organizations but the simpler the validation, the greater the savings on maintenance costs.


The prototype system used to exemplify the designs in this paper includes a fairly sophisticated validation capability, even using regular expressions, which would typically be beyond most power users outside of IT. However, the need for complex regular expressions in validation will be relatively rare and it is possible to train some Users at least to maintain the more simple expressions by providing training and reference materials for any fields (such as telephone numbers, email addresses etc.) that may occur in a production implementation.


Figure 2 presents the table-driven validation design embodied in the prototype system. This partial diagram is extracted directly from the SQL Server 2008 database.  Click the diagram to see a clearer image.




We see the previous Profile definition tables (4) plus two validation metadata tables, the ApplicationField table and the ProfileFieldRule validation overrides for individual Profiles where required.  The ApplicationField table contains the definition of any field that either requires validation, or is included as a Profile Attribute.  This is not as onerous in real life as you may think, as was discussed in the first post in the Interaction Profiling series.  Large applications (in data model terms) with appropriate validation will require most fields to be defined in this table.  This could result in as many as a few hundred field rows, which is still relatively small in size.  The ProfileFieldRule table contains rows only where a different validation rule set is necessary for a specific application field, when it occurs on a transaction that matches the corresponding Profile. Multiple profiles may match a specific transaction and the Profile table Precedence field is used to resolve any possible conflicts automatically.  This situation is rare, especially if the set of interaction Profiles is well constructed, when typically there are no conflicts of this nature.


Two other tables appear on the diagram requiring clarification. The prototype design is multi-interaction. Although the system (a hypothetical Sales Order Processing System) only contains one interaction (Sales Order) that is tracked by the application, the design was created as multi-interaction so it could be expanded if necessary to include other business interactions, such as Invoices or Payments. Typically most transaction processing applications are focused on a single interaction, but a flexible, extensible design is always a good idea as long as it does not introduce too much unnecessary processing overhead or complexity.


The last table shown, SalesOrderProfile, is the repository for the current set of matching profiles for each transaction (in the prototype, Sales Orders). This is a performance assist, as we only need to update this information when interaction data changes occur and there are many occasions when the Interaction Profiling metadata is processed when data is not changed and this avoids the overhead (which is small anyway) of having to perform the profile matching logic unnecessarily. The profile matching logic in the prototype is embodied in a single function with related data retrieval in a single stored procedure. This generic code never changes once fully tested and implemented. All of the validation logic and the BPM task logic is stored in the database and maintained by the Users directly with minimal support from IT. There is NO application code anywhere in the prototype system that hard codes any logic for deriving the rules at runtime for all of the many different types of business transactions. The Interaction Profiling database metadata controls everything in this regard. Compare this to most of the applications you may be familiar with, where such detailed logic is scattered all over the place in code or in lengthy, complicated process flow diagrams.


The prototype validation capabilities exposed by the data content on the ApplicationField and ProfileFieldRule tables are quite extensive and would handle almost all requirements in the vast majority of applications. Given there is an intrinsic facility to call an IT-provided function or a SQL statement (or VBA code, as explained in a later post), there is really no limit to the validation capabilities of the Interaction Profiling framework embodied in the prototype application. Specifically, the validation incorporates checking for the data type, boundary values (max and min), existence (optional or mandatory), special case requirements (upper / lower), SQL lookup validation / statement execution, calling a validation function, plus regular expressions for any amount of sophisticated character checking and even search and replace functionality. Although the primary purpose of the prototype system is to substantiate and confirm the framework designs and check the feasibility of the Interaction Profiling concepts, the validation functionality would handle almost any real world validation requirements that could be envisaged.


Previous Post: Better BPM – 2  Interaction Profiling Definitions and Design

Next Post:        Better BPM – 4  Table-Driven BPM Designs

Better BPM – 2




This second post in the Better BPM series on Interaction Profiling presents a simple, generic design for the Interaction Profile metadata that defines the individual profiles required in a business application.   A later post will investigate possible approaches to establishing the profile metadata requirements from a business analysis perspective. This short post introduces the simple designs that form the premise for an Interaction Profiling framework that can be re-used any number of times in custom application development.


The formal definition of an Interaction Profile is:

The set of attributes of an interaction that define a distinct validation and business processing workflow rule set that is required to process that interaction.

We will investigate how to derive the profiles required for a custom application development project in a subsequent post.  Suffice to say, for now, that an application will probably require between 10 and a couple of hundred profiles, depending upon the size and complexity.  The prototype system uses 23 profiles, plus 2 for reporting, as it so happens that Interaction Profiling provides (as a side benefit) an easy-to-use way of doing Ad Hoc Reporting in an application, that can be used by the Users directly.

The formal definition of a Profile Attribute is:

 An application Field (calculated or physical), one or more values of which are required to define a specific Interaction Profile.

The concept will become clearer as we continue to develop our Interaction Profiling framework.  Typical profile attributes are items such as Customer Type, Product Type, Priority, Age in System (how long we have had a transaction in our system) and any other type of lookup field (often drop-down box enumerations in an application).  The prototype has 15 Profile Attributes, only one of which is a calculated field (Age in System). As many as 50 to 200 might be required in a much larged application.  These numbers are insignificant in enterprise database terms.




A specific (as opposed to generic) design for Interaction Profiling could be used for a one-off implementation by identifying the various Profile Attributes required and creating a Profile table that contains one field for each Attribute. While simple (one table only), this is inflexible and not re-usable and so should not be considered. The basic design for a generic implementation of Interaction Profiling abstracts the Profile Attributes into their own table and only four tables are required for the Profile definition metadata. Figure 1 depicts the simple design for a generic implementation of Interaction Profiling.  Click on the graphic for a clearer image.



We see the many-to-many relationship between the Profile (Interaction Profile) table and the Attribute table implemented via the ProfileAttribute table. This design allows for one profile to have many attributes and conversely, one attribute to be used in any number of profiles. This is the most flexible design and is recommended for production use. The child ProfileDefinition table contains the actual definitions of the actual profiles in terms of the Profile Attribute values for the individual profiles. A one-to-many relationship is all that is required for the definition value data. This allows for any number of values (or ranges of values) for each attribute to be specified in the definition of a specific profile. Note that the UniqueIdentifier value range may not be necessary. The prototype from which this design is drawn uses SQL Server, uniqueidentifier, globally unique identifier (GUID) primary keys (the NewSequentialId function that returns Sequential GUID values), which is only really a good idea if the application requires (or may require) data replication for use in disconnected scenarios. The String value range can be used for other primary key values (any numeric, alphanumeric or alpha value range), as the Attribute table specifies the actual SQL data type for the Profile Attribute and input data would be validated as such on data entry. The String, Date and Boolean value fields cover all scenarios that may be encountered in an actual development situation.


Note that the “xxxNullDefault” fields shown on the diagram are used in the profile matching logic to provide a default action in the situation where the actual input data field on a transaction does not have a value (is Null in database term). This enables the User specification of a default depending upon business requirements. An example will clarify this feature. Assuming the system contains an input field called Priority which may assume values Urgent, High, Normal, Low, then a business rule that states, “if the input priority is missing, a Normal priority is to be assumed” can be implemented by entering a Null default value of Normal in the appropriate Profile definition data row. The profile matching logic will apply the specified default when matching the profile definitions against any transaction where the input Priority field is missing (null). This default will only be required on profile definitions that use the Priority field as a Profile Attribute. Note that the “EtcEtc” field is purely a placeholder to denote the possibility that additional information may be required in specific applications. This convention is used throughout this paper.


The diagram shows that a Profile Attribute may be defined as an Application Field (input field) value, or as a SQL query or statement (that returns a scalar result) or as an actual function call. The ApplicationFieldId is actually a foreign key to the ApplicationField table (not shown in figure 1), that is described in detail in a subsequent post. This table contains the metadata for those application fields that have to be validated by the application that is consuming the Interaction Profiling designs, or that serve as a profile attribute. The vast majority of Profile Attributes will be application field values, but the SQL and function options provide ultimate flexibility in the Interaction Profiling capabilities. The prototype contains one function, but it was not actually required and merely included to test out the function calling capabilities of the prototype Interaction Profiling implementation. Note that the Attribute table contains the default application field / SQL query / function call, but this default may be overridden for any specific Profile Attribute definition by entering the overriding information in the ProfileAttribute table. The SQLQuery field is actually a bit of a misnomer, as the prototype allows for this field to contain either a SQL statement that returns a scalar value, or a code snippet or expression that returns a value also. This is very useful and extremely flexible but does require a mechanism, such as Microsoft’s .Net dynamic reflection, that can evaluate and execute source code at runtime. The prototype actually uses Visual Basic for Applications (VBA), which is the language common to all Microsoft Office products and has been around for a couple of decades. VBA includes an “Eval” statement that does exactly what is required and is somewhat simpler to implement than dynamic reflection.


Finally, we clarify the “Precedence” field on the Profile table. The profile matching logic is called whenever the transaction data is changed in some way, as this may well trigger a change in the corresponding profile set for the transaction and the system is about to perform some validation or BPM – related functionality. Given that there may well be (and usually are) multiple matching profiles for any transaction, the design needs to cope with this eventuality when only a single profile has to be identified for processing purposes. This only occurs at the point of validating a single field, when it does not make any sense to have more than one set of validation rules for validating a single field on a specific transaction. The Precedence number is only used if the matching logic produces more than one profile for validating a single field. This occurs in the real world much less often than you might think. From the BPM perspective, multiple matching profiles is perfectly fine and the system needs to identify all of the tasks that are represented by the various matching profiles. This is typically implemented simply and efficiently by a “Select Distinct” SQL statement at the appropriate point.


This is all that is required for the Profile metadata, yet it provides a fully generic and completely flexible basis for the powerful Interaction Profiling framework that we will continue to develop in subsequent posts. The next post, Better BPM – 3, Table-Driven Validation Designs, will present the designs for persisting the actual validation rules in the database in a relatively simple manner that will allow the User community to maintain their own validation rules. This alone will reduce the impact on IT dramatically with regard to application maintenance.


Previous post:   Better BPM – 1, Success through Simplicity

Next post:          Better BPM – 3, Table-Driven Validation Designs


Better BPM – 1




In this series of 12 blog posts I will introduce a brand new approach to Business Process Management (BPM). The innovative concepts in these posts have evolved from the numerous business transaction processing and case management systems I have encountered throughout my career. This first post is a high-level overview of a new perspective that offers a radical improvement to BPM automation in terms of simplification, development and maintenance cost-savings and re-usability.


I am calling the new design paradigm, “Interaction Profiling“. Actually, the title should be “Transaction Profiling” because that is what it really is. However that term has already been designated for network infrastructure capacity planning by monitoring the resource impact profile of business transactions on network infrastructure and extrapolating resource requirements commensurate with anticipated business growth or shrinkage. Interaction Profiling is a new application system design approach that determines the characteristics (attributes) of business transactions as they relate to the distinct data validation and business processing requirements specifically.  If you click on the graphic below you will see a high-level, conceptual overview of the main pillars of Interaction Profiling.


The set of Interaction Profiles for a given application will encapsulate exactly how any transaction should be validated and handled in BPM terms simply by identifying the subset of profiles that match the transaction. This may not sound that impressive as a concept. However, the significance is enormous, once the full implementation is applied in a real world scenario. I have tested out the new design approach in a hypothetical Sales Order processing application prototype and I will support the designs and estimates as I go along with empirical evidence from the first, fully-working, Interaction-Profiling-empowered prototype system. In the hope of arousing interest in the ensuing blog posts, here is an introductory abstract of Interaction Profiling.


Interaction Profiling is a new paradigm that provides a fresh, object-oriented approach to Business Process Management (BPM). The concept focuses on the core types (profiles) of business interactions (transactions) in an enterprise business processing application system and derives the corresponding, table-driven validation rules and BPM tasks (and more) for each profile. Unlike existing approaches, which tend to be process / task – centric, there is no hard-coding of any validation or business processing logic. Based on the first prototype that embodies Interaction Profiling, it is estimated that the new paradigm will halve development times and costs for all future systems, once the first implementation has been constructed. On-going maintenance is estimated to be reduced at least one-third and possibly more, because changes to the validation and BPM tasks and rules really can be managed and controlled by the users themselves, with much less involvement from the IT support group, based on empirical evidence to date . This represents massive savings in development and maintenance costs and provides truly functional, fully-reusable components for any future application system.


In addition, organizations benefit greatly because the Users and managers are empowered with the tools to control their own business growth and changing business requirements to a degree never before envisaged. The profile level adds a new, User-definable dimension of marketing and commercial program possibilities to the existing Client and Product levels. This is a truly powerful, business-enabling feature. The re-usable framework in the first prototype application is a highly significant three quarters, approximately, of the full implementation of the hypothetical order processing system. This confirms the order of magnitude of the estimates and substantiates the significance of the savings. This blog is not pure research, but introduces a new design paradigm of considerable significance to all enterprise information systems.




Existing business transaction processing application systems, which is most of them out there, typically include complex criteria for validating the individual transactions. A significant number of these systems (including all case tracking systems) also include a varying number of associated manual business processes that are required, in conjunction with the automated system, to complete the transaction life cycle. The validation logic and also the workflow aspects of these systems are almost always hard-coded, either directly in an executable program, or using designer-assisted specification facilities that require compilation, possibly XML declarative persistence or equivalent and staging through the ubiquitous develop – test – user acceptance – production staging.


The business process management (BPM) of the workflow operations is often provided by relatively complex, runtime, server-based, proprietary software that is usually expensive and requires considerable expertise to implement and manage. Some collaboration software products (Such as Microsoft’s SharePoint) offer designer-based workflow, but they are not truly capable of hosting a custom enterprise BPM application system that performs well and is inexpensive in hardware, software and support resources.


Interaction Profiling simplifies the specification, management and control of the validation and BPM logic by identifying the transaction profiles – those types of transactions that require unique data content in some way and / or a unique sequence of BPM Tasks – and associating with each profile the corresponding validation rules and BPM tasks and activities. The user comprehensibility of this approach is considerably increased because the individual profiles exactly model the differentiation that the users themselves apply in their daily operations. If they require, for example, specific and unique data for all retail, large box store Clients, then an interaction profile is required for transactions from such Clients.


If there are corresponding, specific BPM tasks for such transactions, the same profile can be applied. Essentially, an Interaction Profile is required for every type of interaction (transaction) that requires a distinct validation rule set or a distinct set of BPM tasks (or both). To enable an application system to apply these profiles automatically, the criteria that define each profile needs to be determined and stored in the application database.


There are different ways this can be accomplished, but a logical approach is to identify the characteristics / attributes of each profile that clearly define what that profile represents. As clarification, if we require a “Large Box Store, Retail Transaction” profile and assuming we have identified that we need a Trade Type (Retail / Wholesale / Charity…) and Customer Type (Corner Store / Large Box Store…) in our new, state-of-the-art Order Processing, or whatever, application, then both of these application fields would become Profile Attributes and our Large Box Store, Retail Interaction Profile would be defined using two criteria – Trade Type = Retail and Customer Type = Large Box Store.


Profile Attributes may be dynamic in nature as they may change during the processing of an individual interaction instance (transaction). A good example of this kind of attribute would be “Age in the system”, which often drives exceptional processing of some form to address transactions that are not being processed as fast as is desirable. A common business rule could be, “any transaction that has taken X days or more to process should be flagged for exception processing”. The Age in System Attribute would be used to define an “Overdue Transactions” Profile and the exceptional processing would be identified against this Interaction Profile. Thus the set of profiles that match a specific transaction can and will change throughout the lifetime of the transaction. The set of BPM tasks (and validation if pertinent) will vary accordingly, which is encapsulating within the system the business intelligence needed to ensure all transactions are automatically processed correctly throughout their lifetimes.


The design must accommodate multiple profile attributes for each profile in a many-to-many relationship. In this manner, an application will contain the full set of profiles and their definitions, so that the system can determine the exact validation logic required for every individual transaction and also the specific sequence of business processes that are required to process the transaction to completion. We need to design the capability to persist the validation rules and BPM tasks and activities in the database. In order to validate the data, we will need to include the application field metadata in the system. It is not necessary to include every single field, but any field that needs to be validated and / or used as a Profile Attribute must be included in the metadata.


In practice, this will not be as onerous as it may sound. The existing prototype system is representative of a small to medium-sized system (51 database tables) and contains 23 different Interaction Profile data rows, 15 Profile Attribute rows and 43 Application Field rows. It is likely that a large application system (over 100 tables) could require 50 or more Profiles, between 100 and 250 Application Fields and possibly 30 to 50 Profile Attributes. This is small potatoes in terms of database space and performance overhead.


We also include our Users, Organizational structure, the Roles that are required for security purposes to perform our business processes and which Users belong in which roles. If we tag our BPM data in the database with the roles required to perform our BPM tasks, we have now enabled our Interaction Profiling empowered system with the possibility of automatically routing transactions to those users who can perform the specific tasks. Furthermore, if we use Service Level Agreements with our Clients to promise completion times based on some kind of priority scheme, or if we use a priority scheme internally, it makes sense to include the target duration for each BPM task in the metadata. Now the system can tell exactly how to validate each transaction, the specific BPM Tasks required, their sequence, how long they should take and precisely which set of Users can perform them.


This extends the capabilities to include the possibility of workload balancing to optimize operations and spread workload evenly across the User community. Now we have enabled productivity reports, trends, gap analyses, bottleneck detection, more accurate completion estimation and more, which will seriously improve our operational management awareness and effectiveness. All of this can be achieved just by applying Interaction Profiling and some minor, sensible design additions. The next blog post will take a look at how we could design a reusable application framework that provides the preceding functionality, generalizes the Interaction Profiling concepts and can be re-used for all future business transaction (interaction) processing information system development projects.


Note:  The graphic image that heads each of the Interaction Profiling blog posts (including this introduction) is explained in more detail in Post #5.  Although it is comparing apples and oranges to a certain extent, it does portray the potential simplicity that could be achieved using an Interaction Profiling framework, either in conjunction with, or instead of, existing, diagrammatic, BPM workflow products. BPM software, such as BizTalk (as in the graphic), usually do considerably more than just transaction workflow management. Interaction profiling focuses specifically upon transaction validation rules and business process workflow and management.


Next Post: Better BPM – 2  Generic Interaction Profiling Definitions and Design.


Welcome to Midland Microcomputers

Links to Barrie’s blog on Interaction Profiling:

Better BPM – 1  Success Through Simplicity

Better BPM – 2  Interaction Profiling Definitions and Design

Better BPM – 3  Table-Driven Validation Designs

Better BPM – 4  Table-Driven BPM Designs

Better BPM – 5  Interaction Profiling Security Designs

Better BPM – 6  Interaction Profiling Auditing Provisions

Better BPM – 7  Determining Interation Profiles for an Application

Better BPM – 8  Sales Order Processing Prototype

Better BPM – 9  Profile Metadata Maintenance

Better BPM – 10 Prototype Sample Screens and Reports

Better BPM – 11 Prototype Design Framwork Scope and Metrics

Better BPM – 12 Series Conclusions and Wrap-Up


Midland Microcomputers Limited is an Ottawa-Canada-based Information Systems Consultancy specializing in information systems consulting and the application of Microsoft and Internet/Intranet technology to federal and commercial business. Recent work includes a comprehensive Case Tracking / Investigation Management solution design, development and implementation using SharePoint Portal Server and Windows SharePoint Services, plus Visual Studio .Net, VB.NET, C#.Net, ASP.NET. Other projects include client-server, web-based and RAD (Rapid Application Development) technology on LAN and WAN (Windows, SQL Server, Oracle) platforms.

Our President, Mr. Barrie Gray offers an unusual blend of information systems expertise combined with a very comprehensive technical knowledge and excellent report-writing skills. He has in-depth experience in information systems consulting, project management, systems and programming management on mainframes (15 years) as well as over 30 years technical experience with mini- and micro- computers (PC LANs and Windows 95/98/NT/XP/2K/2003/XP/7 being particular foci). Barrie has had numerous technical articles published on OOP (Object-Oriented Programming), development tools (Visual Basic.Net, C#, Access and C++) and Windows NT/2000 in Computing Canada.

Midland Microcomputers Limited also offers a comprehensive, business planning and performance management product (BMS) which is in successful operation in two Government departments, a browser-based, scheduling information database (EasiDB), plus technology for bilingualising Visual Basic and MS Access applications.