To TPM or not to TPM

To TPM or not to TPM

Expert articles on a wide range of topics​

To TPM or not to TPM

By Greg Eves

Introduced around Version 8, TPM (Trade Process Management) is a module available on the Openlink Endur/Findur platform to facilitate the automation, execution, and oversight of business workflows. Over the years TPM functionality has increased to provide a way to automate an increasing amount of system functionality. In more recent versions, the JBPM-based foundation that supports TPM has been replaced with a Camunda-based backend to provide a more robust platform.

Whilst TPM offers the ability to automate a wide range of system activity using the out-of-the-box building blocks (step types) it provides, and with the addition of some complimentary custom plugins anything is theoretically possible, using TPM is not necessarily the right choice for every process. This article aims to highlight some of the strengths of TPM and some of its weaknesses to allow the reader to make a more informed choice when it comes to deciding whether to implement a process that leverages TPM or to use alternative system functionality to reach the same goal.

As part of its offering, TPM provides several step types that can be used to trigger human-user interaction or notification. Combined with step types that allow logic-based decision making, forking, and joining means complex processes involving multiple user groups can be implemented, executed, and overseen. For example, setting up a new counterparty would typically require steps to be completed by different teams – a definition can be configured to spawn parallel assignment tasks when a counterparty is created, one might be assigned to a credit team to notify them to set up limits, another might be assigned to the back office to notify them to configure settlement data and so on. TPM can coordinate the assignments and wait for each group to confirm completion before running additional steps within the forked processes to validate the user actions before joining the forked processes and continuing with whatever other steps might be necessary. To replicate this same functionality along with the visualisations TPM provides would be a considerable undertaking requiring significant amounts of complex code. This makes TPM the obvious choice for most event (operation service) driven business processes that require manual user interaction or intervention, including activities such as trade booking, static data maintenance, confirmation processing, and settlements where multiple groups are typically responsible for different parts of the process. As well as being event-driven through operation service configuration, TPM definitions can also be triggered to run on a schedule, much like the schedule available in the Services Manager.

Theoretically, TPM can leverage this ability to coordinate a batch process such as the End of Day (EoD) to execute the same steps in a particular order on a regular basis and this approach will work providing no problems are encountered during the process that requires a finer degree of control to resolve efficiently. Taking the EoD as an example, one step might include the execution of simulations that are saved to the database. If the simulations fail for a single portfolio and the simulations are triggered by a single TPM step that generates for all portfolios there is no way to re-run the failing portfolio in isolation. On a smaller instance, re-running the simulations may not cause a significant delay, but the EoD TPM definition may have one or more preceding steps and the outcome of rerunning those steps is unknown. Modifying a controlled TPM definition to deal with a failure whilst in the middle of an EoD is not something to be undertaken on a regular basis, if at all for obvious reasons. Of course, the definition could be implemented in such a way as to make it rerunnable from a failure at any point, and it could even be designed to deal with the specific case of a failing portfolio efficiently, but there are many often unforeseen ways that things can fail and to implement a TPM definition that can handle all of them is impractical and would quickly lead to something that becomes confusing and unmaintainable. Contrast this with the functionality offered by Services Manager workflows combined with some well written plugins and the above failure scenario becomes a lot easier to resolve because workflows can be restarted from any point, there is no need to consider the prior steps as there is no need to re-run them.

The need for up front well considered definition design is not isolated to definitions that are more likely to fail. Once implemented, changing processes to introduce new steps, particularly when the workflow is already complex is not simple. The visual flow diagram-based functionality does help to make modifications easier but when the connections between steps are numerous and overlapping it can become difficult to use and reverting to the table-table based designer is the only option. A benefit of TPM is that it’s said to be codeless and to not need developers to implement. For relatively simple processes this is true, but to implement something more complex requires knowledge of how to efficiently use flow control operators, a trait not possessed by all. If this knowledge is lacking, it is very easy to make something that works but does so inefficiently or is difficult to maintain and change at a future date. On a similar note, it is also worth mentioning that many step types require parameters to be set to values requiring different, very specific syntaxes some of which look a lot like code. Again, without this knowledge it is easy to develop something that works but it may not be as efficient as it could be.

TPM is supposed to provide a transparent easily understandable view of the underlying process in the form of flow diagrams and the more detailed steps editor GUI. This is certainly true at a high level; it is usually possible to work out the overall intention of a definition and understand which steps have been triggered during execution by looking at the step types and the parameters. However, when it comes to drilling into the detail to gain an in depth understanding of a definition it can become opaque. As already mentioned, there are settings available on each step with various special meanings and it is very difficult to gain a detailed understanding of a complex definition quickly and it is very easy to miss something – this is especially true when you pair it with the fact that you have to do all of this from the Endur GUI – you have to keep a lot of the process in your head while you go through the steps to understand it, for definitions with high cyclomatic complexity this is very difficult. If you contrast this with how a developer can navigate and understand well written code in a modern IDE such as Eclipse, TPM scores poorly.

The ability to debug TPM definitions is very limited, particularly in a production setting, which makes consistent, well understood exception handling and logging very important. Without this you are reliant on the output of the (often sparse) standard logs to work out what has gone wrong, and even with this and the so-called visual TPM output, things are not always obvious. The same can also be said for logging and exception handling within plugin code, therefore the logging and exception handling strategy for all development should be well understood by all.

In summary, the limitations make TPM an unlikely choice as a platform to underpin an entire Endur/Findur implementation. But the strengths it offers for managing user interventions make it an obvious choice for managing auditable event-driven business processes. If TPM is used, the upfront strategy decisions around things like exception handling, logging and the design of definitions is key to using it successfully. Before blindly deciding to use TPM for a process, those implementing should consider what alternatives are available and weigh up the pros and cons, being sure to include the aspects of maintainability and flexibility as part of the decision-making process.

Have your say:

error: Content is protected.

Download PDF version

This field is for validation purposes and should be left unchanged.