There are a lot of interesting case studies being presented here in New York this week, and I’ll be checking back for the videos of ones that I missed when they’re published next week.
I attended the Barclay’s session on their post-trade processes, presented by Shakir Ahmed, Head of International securities Settlements Technology, and Larisa Kvetnoy, Managing Director of Markets Post Trade Technology. Although trading processes are not handled with a BPMN engine like Camunda, the post-trade processes are an important part of ensuring that trades settle correctly. Given the move to T+1 settlements, it’s critical that all of the exception handling and due diligence is completed in time to execute the settlement on time. There are a lot of complex activities that must be performed, often in a specific order, and many of these have relied on aging legacy systems and manual processes in the past.
Now, they use Camunda to orchestrate services, and have created separate services for each function that must be performed in the post-trade processes. They also created a centralized exception handling service — which relies heavily on human work — to bring together all of the exceptions regardless of the system or step where they occur.
They are definitely seeing improvements in agility and time to market, but also in operational oversight: making sure that transactions don’t “fall through the cracks” and fail to settle on time. This reduces their financial risk as well as their overall costs.
Next was QuickSign, a European digital onboarding provider, presented by founder Thibaut Ravise and CMO Charlotte Stril. They provide services to large financial institutions such as BNP Paribas, allowing these FIs to outsource the onboarding of customers almost instantly. This is essential for being able to provide credit solutions in the course of a retail transaction, where the customer is offered the option to use a credit option during online checkout when they are buying (for example) the latest iPhone. This is also used for fast bank account opening, immediate expense payments for insurance claims, and other situations where an onboarding experience needs to be much faster than could be offered by the FIs directly with their legacy processes. Since they’re based in France, they provide services that adhere to the strict EU standards and regulations, and are expanding into the US with some of their products.
Part of their solution is an orchestration layer that is based on Camunda, which brings together the digital identification, KYC (know your client) and signing services. This in turn helps their FI clients to win new retail clients such as Apple and Amazon, where near-instant credit account opening and onboarding is a necessary part of online purchasing. When Camunda 8 was released in 2020, they made the move from their own internal workflow to the Camunda BPMN engine on premise. The use of BPMN has allowed them to rework and release customer workflows quickly, and Camunda Optimize allows them to gather information and optimize processes. For them, scalability and resiliency of the platform is critical: workloads can increase by several times on heavy shopping days such as Black Friday.
The last customer case study session that I attended today was with Dutch energy infrastructure company Alliander on their migration from Camunda 7 to 8, presented by Floris van der Meulen, Business Analyst System Operations, and Eric Hendriks, Senior Software Engineer. They were one of the first companies to migrate a production process from 7 to 8, and likely have the scars to prove it.
From a business standpoint, they operate large energy distribution grids throughout the Netherlands, with one component of that being their autonomous grid manager that includes Camunda. They were originally using open source Camunda 7 to respond to Kafka messages and manage security and load changes required to the grid as load and supply conditions fluctuate.
Factors driving their decision to move off the open source Camunda 7 included lack of operational insights, transactional locking, no commercial support, and scalability, all ofwhich had them decide to move to Camunda 8. They were in production with Camunda 7 but hadn’t scaled up so did not consider the processes mission critical; in order to move to the next stage, they felt it necessary to shift platforms before investing more in the older platform. They did an evaluation of what would change as a result of the migration: at the time, some BPMN features were not (yet) in Camunda 8, such as execution listeners, but they would have the benefit of scalability as well as being able to use Optimize for operational insights.
They used a gradual “new world” approach to migration, and even created a BPMN diagram to illustrate their migration process. They ended up having to do a manual conversion of their BPMN models because of the execution listeners: this required them to rethink and completely redesign their processes.
Once they redesigned the BPMN processes and reconnected them to their UI, they needed to overhaul their testing procedures. They started with “black box” tests on their old processes, and ran them against the new processes to ensure that the same inputs resulted in the same outputs. Following the confirmation that the new processes behaved the same as the old processes, they could migrate in the new V8 processes and decommission the V7 processes. Their process instances are all short-running, so there was no requirement to migrate work in progress, which made the migration more straightforward. Also, they only had about a dozen process models to migrate.
They were pretty open about some of the problems that they had with the migration: it’s not automated by any stretch of the the imagination, and it’s a non-trivial project that will almost certainly include process redesign and retooling. However, they now have cleaner models and code, and a much more robust and scalable environment.
As as aside, I’m attuned to the challenges of migrating customers between product versions when it’s a complete replatforming exercise, and interested to see how well Camunda handles this over the next few years as they sunset Camunda 7 support. A lot of companies don’t do this very well — see the history of TIBCO with migrating Staffware customers to ActiveMatrix BPM, for example, or the IBM BPM “three engines under the covers” fiasco — and it’s no longer enough to just tell customers to build their new processes on the new platform while sticking their heads in the sand over the existing processes. Given that Camunda has really focused on being the orchestration engine in the past, the shift from 7 to 8 should be a bit less painful than replatforming with some other vendor products: no UI to redevelop, and some ability to export/import BPMN processes directly as long as all of the BPMN elements are supported. Maybe they can use AI for this? 😉