One of our clients is a well-known financial institution. But for security reasons, I’ll call them Global Bank.

Global Bank has departments to serve individuals, corporate entities, and even governments. And seven years ago, they built an application to evaluate new customers for credit accounts.

Everything went smoothly for awhile. But then, the requirements started to change.

New Requirements

Some departments needed to modify their on-boarding processes, while others wanted to rewrite it entirely. And even Global Bank wanted to add new types of customers — likely with their own on-boarding procedures.

Complex, Rigid Processes

To manage these complex processes, Global Bank used jBPM within their application. But every time they updated their workflow, it grew more complex. Until it looked like this:

“We had to start saying ‘NO’ to requests from the departments”

“..it just takes too much time to change anything”

One Global Bank developer said it best.

“I am afraid to modify this….I know I will break something”

And if Global Bank can’t quickly adapt to new requirements, they won’t be able to take on new customers.

Build Fast. Delight Customers

Global Bank wants to be able to build new functionality at lightning speed. Then they can delight their existing customers, quickly add new ones, and grow their business!

On Monday, our architect unveiled a new design to help Global Bank. And when they saw it, they rejoiced.

“YES! It’s perfect! You guys are the best!”

“We couldn’t have asked for more!”

Ok, ok fine. They actually said..

“Oh! Good — it’s good. I think this will work for us..”

Global Bank saw how much easier it would be to modify this:

It’s simple, yet extremely flexible.

So..how did our architect get to this design?

How to Create a Simple, Flexible Workflow

During the week, we reviewed multiple design approaches. 

Us: “Is this the simplicity you wanted?”

Global Bank: “Yes, but…it’s too hard for us to make changes”

Us: “Aha! Now this is the flexibility you were asking for!”

Global Bank: “Yes, but…it’s too hard for us to understand”

Fortunately, our architect’s design struck a balance between simplicity and flexibility. And he did it using an ad-hoc process.

Here’s how he redesigned their process.

  1. Look for patterns
    • Here’s one way. For each task in your process, follow the path until you find a gateway
    • Draw a circle around that task, gateway, and its outgoing connections.

    • Global Bank’s flow is very human task driven. One of our consultants spotted this pattern: Human Task + Gateway + Other Logic
  2. Break the process into modules
    • Take what you circled and separate their outgoing connections like so

  3. Use signals to connect the modules
    • Add signals to the dangling connectors to connect them to their correct module
    • For gateways with only one outgoing connection, just connect it to the task
    • When you’re done, you’ll have something similar to what our architect designed 

3 Implementation “Gotchas”

If you plan to implement a similar design, you’ll need to:

  1. Set the “Ad-hoc” property to true to create an ad-hoc process. Otherwise, you’ll get nasty bpm compilation errors.
    • In Business Central

    • In Eclipse Modeler

  2. Set signal references and scope. You can signal any node in an ad-hoc process. 
    • SignalRef = your human task name
    • Signal Scope = Process Instance

  3. Keep everything in process variables. Since we can’t pass a payload from our outgoing signals to the human tasks, we must keep all our data in process variables

Recap

Ad-hoc processes allow us to build simple, flexible workflows. After we find patterns in our process, we can break them down. And then they become easy to read and update.

Other BPMS Links

  1. How to Create a Business Process with JBoss BPMS
  2. How to Embed a jBPM Process in a Java Application
  3. Spin Up BPMS Quickly w/ Docker

See you next time,

-T.O.

 

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑