New JBoss BPM middleware aims to increase role of microservices.
At the Red Hat Summit, financial industry experts discussed how banks and other financial institutions are rethinking BPM in concert with microservices. This approach leverages improvements in Red Hat JBoss BPM middleware to simplify app development. Enterprise architects can use this approach to separate smaller business process management components from rules components to make it easier for line-of-business people to bring financial products to market faster.
"Microservices make it easy to think about keeping the components of the BPM system easier to update," said Andrew Bonham, enterprise architect at Capital One, based in McLean, Va. "In traditional SOA, there is an orchestrator telling other services what to do. Microservices leverage a more reactive architecture in which each service is preprogrammed."
According to Bonham, enterprise architects should think about breaking processes into smaller pieces, integrating business process management (BPM) engines into applications and simulating rules. These practices make it easier for banks to test out new financial products more quickly. Banks are also developing tools for metadata management for tracking which rule versions were used to process transactions. This makes it easier to separate the management of rules from BPM infrastructure, while adhering to governance, risk and compliance (GRC) requirements.
Keep things small
Bonham said as enterprises began adding functionality to the BPM engine, it is easy to wind up with one monolithic app. He claimed a good practice is to keep things small and avoid creating dependencies, which requires making the interactions atomic. He also said monolithic applications lead to a large number of dependencies that make it hard to change.
JBoss supports different approaches for integrating BPM into enterprise applications as standalone and embedded engines. In a standalone approach, the BPM engine is implemented in its own server, which interacts with other processes using REST interfaces. Bonham said this approach helps to decouple the workflow from the APIs, and this is beneficial for doing proof of concepts and also makes it possible to keep the APIs stateful.
"This is also good if you want to reuse the BPM deployment across divisions or processes," he added.
The session also revealed it is important to consider where the engine and application are being deployed in the data center, which can become an issue if one engine is leveraged by multiple applications. Capital One had one project where these were in different data centers, which created latency problems.
Bonham said the embedded approach involves integrating the engine into an application process. This can achieve better performance, since there is no overhead from network calls. In addition, it provides some additional capabilities that might not exist in an API integration approach.
"A good practice is to use this in stateless transactions and places where the rules are executed, but the state does not have to be saved," Bonham said.
Focus on configuring, rather than coding
Another part of the session focused on Infosys Ltd., which has been updating its core banking application to work on top of private cloud infrastructure.
The company's Finacle banking platform is used to process 16.5% of all banking transactions. Peter Loop, associate vice president and principal technical architect at Infosys, said they wanted to get to the point where they could talk about configuring the applications, rather than coding services. The goal, he said, is to enable line of business to quickly create new banking products by configuring these outside of the system's code.
Automated calls into the system are fairly easy to implement, Loop said. Manual workflows are more difficult to integrate into the system. Infosys has created a manual adapter for doing assignments, so both automated and manual workflows can be managed in one place.
This works well, Loop said, but the challenging part lies in managing the metadata about the transaction. To address this gap, Infosys has created application-specific metadata regarding the rule sets applied to workflows. This approach provides the ability to configure banking products, like a particular loan type, from a spreadsheet interface. Banking managers can assemble these rules into new banking products more quickly than requiring a developer to code them into the application.
Another good practice is to create a simulation environment to test out new rules, said Emanuele Montrasi, lead developer at SIA, based in Milan, Italy. According to Montrasi, this allows a business analyst to run a simulation to check if a new rule works correctly. After the simulation, the new rule can be passed on to an approver before being committed into the live environment.
Separate governance from rules and infrastructure
According to Loop, microservices make it possible to implement the back-end infrastructure in a way that is separate from the rules management. This approach allows their bank to update the underlying infrastructure without impacting the rules. Line-of-business people can revise rules without requiring IT to change out the infrastructure.
Loop also it is important to version control the rule sets. Infosys has implemented source control that can be applied to the spreadsheets used by business managers. He added that this is important for GRC, since banks need to have a way of associating a transaction with metadata about which rules were applied to each transaction.
Source: www.bing.com
Images credited to www.bing.com and 1.bp.blogspot.com
