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


Leave a Reply

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