In the case of a restaurant, a workflow can for example be defined from getting an order to handing the prepared meal over to a courier. In the case of a bank one example of a workflow can be loan underwriting from receiving customer's application to paying out money. The complexity of a workflow differs from industry to industry but is generally defined by the number of tasks and participants as well as the average duration. Every solution thriving to enable business success must be able to support workflows. Modularbank seeks not only to support the banking and financial services industry processes but also to automate them to the maximum extent, allowing to boost revenues through better user experience while saving on costs.

Banking is extremely process-heavy by its nature and rightfully so, as managing finances and risk is one of the most regulated and governed endeavours one can take upon. Some of the most common processes in retail and business banking are onboarding together with Know-Your-Customer, account opening, card application, loan and deposit origination, asset and collateral registration, investment account opening, and of course the end of day processing. Some of these processes, like onboarding and origination, include a lot of different actors and some, like the end of day processing, include a lot of computations that must follow a certain order. A common denominator for all of the above mentioned is the need for managing activity chains, combining together different services and people, holding the state of specific processes in a consistent manner, and handling exceptional cases. In addition, there is a continuous necessity for monitoring and fine-tuning the workflows as smoother workflows equal better customer experience.

How to manage the workflows? 

From a software perspective workflows can be managed in 3 main ways: 

  • asynchronous communication by commands and events; 
  • point-to-point communication from applications;
  • work distribution by the workflow engine

Asynchronous communication means all workflows are managed by messaging between different services, allowing to remove the coupling from services and to tolerate tremendous workloads. At the same time this approach sacrifices monitorability. Point-to-point communication means that services initiate synchronous API calls from each other allowing to quickly develop services while coupling services together. Work distribution by workflow engine, as the phrase suggests, means that the workflow engine distributes work over different services. This allows easy setup and monitoring, while also making the workflow engine a central piece of the entire workflow management. All options have their own pros and cons. Making a choice between them depends on organizational capabilities, software landscape and architecture, and of course availability of resources.

Modularbank's approach to workflow management

At Modularbank, we have chosen a mixed approach using both workflow engine and asynchronous communication on the platform. The rationale behind the mixed approach is based on the fact that in addition to managing internal workflows, Modularbank must also enable customization of certain workflows like origination flows to accommodate customer requirements. To accomplish this, we have a separate service which manages workflows. As a result, we do not have to change code in several places during customer implementations, and we avoid including the same dependency into several components. We chose to run the platform on an open-source Camunda workflow engine. In addition to being a technically superior product, Camunda workflow engine allows to draw diagrams with Camunda Modeller which run in production environments. This guarantees that documentation and code are synchronized, avoiding the usual situation where diagrams say one thing and code does something completely different. As some workflows are very straightforward and do not change throughout different implementations, we have implemented them using asynchronous communication between services without a workflow engine since a service in between will unfortunately always add additional latency and communication overhead. From an API consumer perspective, it is not developer-friendly to integrate with several services simultaneously. Therefore, we have chosen an approach to hide the workflow from the external world so that API consumers can only call relevant business services, which provide them feedback about the state of the workflow. 

From a bank's perspective, loan origination workflow can be considered as one of the most complex ones. With a minimal number of tasks it can be described as follows: capture applications, assess customers creditworthiness, generate individualized offers, allow customers to accept or decline offers as well as negotiate, create necessary documentation, allow customers to accept and sign contracts and finally disburse funds. Of course, this flow has a lot of exceptional cases and a good banking platform must support them. In Modularbank this lengthy workflow is initiated from the loan module by an asynchronous command to workflow service. The workflow itself does the heavy lifting by communicating with different internal and external services and guiding the loan application through different steps. The API consumers can only communicate with the loan module and see the domain objects status from there without having any knowledge about the internal workings. In practice, this approach of keeping workflow separate from business modules has enabled Modularbank’s engineering team to configure and customize processes according to customer needs while keeping maintainability. In addition to that, the separation also allows customers to leverage their own workflow engines if they, for example, have gone through the painful process of implementing one.

There's no silver bullet

All optimizations must start with defining the workflows. As a reminder, if we talk about several tasks in sequential order, with several participants and a long duration we are talking about workflow behaviour. Silver bullets do not exist when it comes to developing solutions that support workflows. There are different options with their respective pros and cons and the final solution depends on the technical experience of the team and the availability of resources. A general recommendation is to aim for monitorability and maintainability as one needs to be able to react quickly to misalignments in workflows and to adjust accordingly. Before taking the long-lasting endeavour of developing a workflow engine from scratch, one should at least take some time to consider available tools in the market. Investing in workflow management will always pay off as it improves customer experience and, in the long run, helps to reduce internal costs.