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.