Business Processes in the Applications

Why Business Processes and Software are Like Peanut Butter and Jelly

Why Business Processes and Software are Like Peanut Butter and Jelly

In my journey through the tech landscape, I've noticed something fascinating: almost every system involves more than just a solitary action. It's about a series of steps, a dance of sorts, that we choreograph through software. We're not just coding for fun, right? We're here to make businesses zip along faster and smoother.

The First Rule of Software Club: Separate, then Conquer

Here's the kicker: if your software is going to roll with the punches – adapting, evolving, growing – you've got to start with a golden rule. Separate your application logic from your business process. Imagine this: your application logic is like your toolbox, filled with all sorts of handy tools. The business process? That's the blueprint you're following. And yes, these blueprints can chat with each other, setting off a chain reaction of events.

A Little History Lesson

This isn't a new concept. Through the annals of tech history, many projects have tried to encapsulate this dance of processes into neat, separate libraries. The dream? To manage change and growth more efficiently and with fewer facepalms. But then, occasionally, a maverick developer, struck by the Not Invented Here syndrome (see here for a deep dive: NIH Syndrome), decides to reinvent the wheel and build their own business process engine. Noble? Absolutely. Easy? Not by a long shot.

Creating a process engine that juggles a multitude of tasks isn't a walk in the park. It's not just about crafting a state machine running loops. You've got to juggle multitenancy, tackle failure conditions, shuffle context around, and maybe even throw in a user interface for good measure.

The Pitfall of Homegrown Solutions

Here's a bit of truth: Custom-built components don't just evolve on their own. Unlike off-the-shelf software that gets regular updates, making it more efficient over time, a custom solution can stagnate. I've seen it firsthand in a massive project where a custom-built engine hummed in the background. It did its job, sure, but it was rigid – changes had to go through a developer, and there hadn't been a significant update in nearly a decade.

Drumroll, Please: The Solution

You're probably guessing what I'm about to suggest. Let's not keep the cat in the bag any longer. Go for a built-for-you process engine. My experiences with Camunda and Zeebe have been nothing short of impressive. What's cool about these platforms is how you can use BPML (Business Process Modeling Language) to design your business process model. The application provides the muscle, doing the heavy lifting.

Real-World Magic: An Example

Picture this: A message from a Notice service kicks off the process. The first step pokes the Proceeding service to create a new entry. The person in charge gets 15 minutes to approve or decline. No response? The proceeding gets axed. But wait, there's more – notifications are sent out regardless of the outcome.

When Business Wants More

Say the business wants an additional notification when a Proceeding is auto-cancelled. No sweat. With a process engine like Camunda, you can just add a new step. It's like adding a new scene to your favorite play, without having to rewrite the whole script.

No Silver Bullets, But Plenty of Silver Linings

Now, I won't sugarcoat it. Implementing an external process engine isn't all rainbows and unicorns.