Processes, rules and things in between

Publish date:

I was commuting the other, catching up on my reading, when I came across the following from David McGoveran: We talk about business processes, business transactions, business events, business activities, business metrics and key performance indicators, and even business services. The language IT uses is now a bit more familiar to business users, and they’re […]

I was commuting the other, catching up on my reading, when I came across the following from David McGoveran:

We talk about business processes, business transactions, business events, business activities, business metrics and key performance indicators, and even business services. The language IT uses is now a bit more familiar to business users, and they’re beginning to expect great advances. It’s really too bad they’re going to be disappointed. Unfortunately, though the words may sound like they refer to business, the software industry uses them to denote technology. We’ve merely plastered over the gap between business and IT by mimicking the words used by business, all but ignoring the details of how they are used.

This is something that resonates with me. For a while I’ve been thinking that there’s a hole in our current technology stack. We claim that BPEL, WCL, rules etc provide all the tools required to capture and automate business logic; however this creates an articifial divide between decisions (rules) and tasks (processes). We seem to focus on the macro processes and the micro rules and forget about the interface between the two, the area in business logic where a great deal of a company’s differentation can reside.

There are a number of examples of business logic living in this middle ground, and which we typically support with custom Java inside a fat service. Rating (computing the price of a purchase) in sectors like finance and logistics, where products can be very complex beasts, is typical. The business may have exacting requirements as they see their ability to support highly tailored customer agreements as a key part of their differentiation, making the problem too complex for BPEL and too procedural for a rules engine.
I think the problem is that we’ve been looking at the technical bits (rules and processes) required to capture business logic without investigating how they both are used across the business. This is successful at the extremes when we business logic is dominated by either rules or process, but breaks down in the middle ground. If we want to claim that we have a complete solution for capturing business logic then we need to find a business friendly approach to capturing this logic from the middle ground.
A more fruitful approach might be to come at the problem from the opposite direction. Let’s go top down, investigate how people understand and process business logic, and then create tools and techniques which mimic our approach.
There’s already a long history of technology designed to solve this problem, starting with Planner from the early 70s through PRS in the 80s. Perhaps the technology’s time has finally come. The interesting question is how we should integrate these ideas into our current technology stacks.

Related Posts

Financial Services

Who needs high-code developers? Citizen development is here for Financial Services

Date icon July 22, 2021

Why does IT let business wait for months to deliver low-hanging fruit process improvements if...

Insights and Data

Seven key lessons from data-sharing masters

Zhiwei Jiang
Date icon July 20, 2021

Three in five organizations only participate in low-collaboration data exchanges. But,...

Artificial Intelligence

Decoding trust and Ethics in AI for business outcomes

Anne-Laure Thieullent
Date icon July 19, 2021

From our AI and the Ethical Conundrum report, we know that 70% of customers expect...