How different is providing Performance Strategy for BPM applications?
In the domain of Financial Services and Banking, Business Process Modeling (BPM) systems are often at the heart of the enterprise applications as these provide flexibility, lesser time-to-market and better regulatory compliance with local laws to name a few. BPM technology is typically used to implement a 'workflow based application' where different 'tasks' are to be performed by different 'user groups' or 'actors' based on the 'state' of the data. It can have actors as humans or the business processes that can integrate with other systems through Enterprise Service Bus (ESB) for a complete business process or business activity.
A typical BPM system, at a very abstract level, comprises a Process Engine, Process Modeler and a Content Management System (CMS) / Database. Process modeler is used to create business processes, process engine provides the runtime to execute the processes and CMS or DB will be used to store information specific to the Process Engine artifacts.
Now the question arises that how should one look at BPM systems for Application Performance Management (APM)? Is it any different from web-based or batch type applications? How different it is to provide performance strategy for BPM applications? What are the additional factors to be considered while capturing Non Functional Requirements (NFRs) and providing load simulation approaches? Well, here are my thoughts.
·While capturing NFRs, be focused to understand 'business process', 'sub-process', 'tasks' and 'actors' in the system - this basically sets the stage to have clear understanding of the business flows, atomic operations and end-users which makes the performance strategy easy to define.
While defining performance test execution strategy, following should be kept in mind for BPM applications.
·If Actor 'a' works with some set of screens or UI steps, all such screens/steps should be considered as a single business flow for Actor 'a' - similarly all different users/actors working on a set of screens should be considered as one business flow which should be mapped to one 'Test Script' created using any Load Simulation software.
·Secondly, if a single business process comprises two sub-processes, first sub-process acted upon by user 'a' followed by second sub-process by user 'b', the strategy to load simulation can take either of the two following approaches:
ü Approach 1 à Create a single script with sub-process for user 'a' who will modify the state and submit to user 'b' - and user 'b' will act thereafter à This represents real world scenario where user 'b' does not have any pending items in his inbox and hence cannot act upon unless user 'a' submits something. Here these 2 actions will be sequential in nature.
ü Approach 2 à Create separate LR scripts for activities done by user 'a' and 'b' and execute them concurrently à This also represents real world scenario where multiple items are pending with user 'b' and hence he does not necessarily act upon the recently submitted items by user 'a' - hence they act on respective actions independently.
In Approach 1, test data flow between the two sub-processes (from user 'a' to user 'b') is apparent, intuitive and easy to handle in load simulation scripts.
In Approach 2, data should be pre-created and kept ready so that steps for user 'a' and user 'b' can concurrently execute, as actions/tasks submitted by 'a' will not be available to user 'b' instantaneously, which is comparatively tedious and time consuming.
In either approaches, one should ensure that the concurrent load created on the underlying BPM system per unit of time should be the 'Peak Load' which can be controlled by adjusting the number of Vusers, iterations, pacing and think time in Load Simulation software.
·One should have clear understanding about the 'data flow' between the 'actors' so that data preparation activities are clearly highlighted in the proposals and right estimates are provided upfront.
·Also, BPM systems in specific, besides having database instances for application data persistence, have separate DB instance to persist configuration details of the Process Engine (specific to processes, sub-processes, tasks, user groups and any administrative details) - hence, ensure to highlight the strategy to monitor process engine DB instance as well.
·Like for online/batch systems, the 'concurrency' for BPM applications is nothing but a set of actions/tasks being generated by different 'user groups' or 'actors' performing respective tasks concurrently - the basis for concurrency should be 'transaction load' but not just 'user load'.
So laying down the performance testing strategy for BPM systems necessitates focusing on few additional aspects without which performance assessment for BPM systems will be ineffective.