Blog‎ > ‎

The Case For Declarative Transaction Logic

 We've made most business calculations easy with spreadsheets. Why can't we do the same with transaction logic? 

The spreadsheet

Indulge an aging geek, and allow me to reminisce back to 1979. That's the year Visicalc was introduced. It was the first spreadsheet program ever available for personal computers. It was an absolute bombshell. Anyone who dealt with numbers -- analysts, accountants, financial planners -- suddenly could manipulate these numbers in a way that was simply unimaginable before.

Sure, dedicated people could write programs (in Basic, perhaps) to manipulate their numbers. But it was simply too hard. Programs take a lot of work to write, and they're difficult to write correctly.

What was truly novel in Visicalc is that it allowed you to specify what the numbers were supposed to do, rather than specify how the numbers ought to be computed. You never had to think, for instance, about the order in which cells had to be recomputed. The spreadsheet did that for you. If you changed one cell, it recomputed whatever other cells needed to be recomputed, in the correct order. It was wonderful.

The aha moment

Visicalc was a quantum leap because it changed the whole ballgame. Rather than getting a better programming language, we now had a whole new way of looking at the problem.

What changed was that we could now specify what we wanted, without having to specify how to get it. It seems so obvious now, but believe me, it was not obvious back then.

I'd like to suggest that it's high time we apply this approach to business logic. In fact, I can't believe we're still coding this stuff by hand in the 21st century.

Let the machine do what the machine does best

Think about doing your taxes in a spreadsheet: each cell is simple. It's the combination of all the cells that's complex. The whole is much more than the sum of the parts.

It's the same thing in a business system. Each bit of logic is usually fairly simple:
  • A customer's balance is the sum of the unpaid orders. 
  • Shipping is free for orders over $100, but only in the 48 contiguous states.
  • Customers without a credit line must pay cash.
There's hundreds, thousands of these. They typically get written down in the specifications, and then translated into code.

And that's when trouble begins, because as soon as they're translated into code, three things happen:
  • they become atomized -- mixed up with all the other code, and therefore difficult (if not impossible) to identify
  • they become difficult (if not impossible) to trace back to their original intent
  • they start interacting with each other in unforeseen ways. They become interdependent. They step on each other's toes.

Anyone who's worked on a real software system knows this. The bigger the system, the worse it gets. And it's not linear. Growing a system ten-fold does not make it ten times more complicated, it makes it a hundred times more complicated, because the total number of possible interactions and dependencies grows exponentially.

Instead of having to orchestrate all these interactions and dependencies, what if you could just specify all the bits of logic and toss them into the pot? What if you could have the system take care of running them when needed, in the right order? 

That would be a game changer, wouldn't it?

Introducing declarative transaction logic

It turns out that a large portion of most business software (and many other kinds of software) can be mocked up in a spreadsheet. That's why analysts and pointy-haired bosses often underestimate the effort required to implement these systems: if they can mock it up in Excel in just a few hours, why is it going to take us weeks or months to do the same thing in a transactional system?

Declarative transaction logic takes the basic principles of a spreadsheet, and applies them to transactional systems.

You specify the logic for your data without specifying how that logic should be executed. The how will be figured out by the system, based on an analysis of the dependencies between all those bits of logic -- just like a spreadsheet figures out how to recompute the proper cells whenever something changes.

This is not a replacement for your programming language, obviously. Instead, it's a way to express common business logic, such as sums, counts, formulas, derivations, constraints, etc... in a way that's easy and readable.

The benefits

Almost all business applications can benefit from this approach. All the bread-and-butter systems like accounting, inventory, time tracking, finance, banking, insurance, mortgage management, taxes, customer accounts...

In fact almost any transactional system that can be prototyped with a spreadsheet can be vastly simplified with declarative transaction logic.

When I say simplified, I am not kidding. Declarative transaction logic usually eliminates over half of the business logic code, and replaces it with simple declarative statements. In a typical enterprise application, you might be able to replace 100,000 lines of code with a few pages of rules. It's pretty dramatic. Imagine having to do your taxes with nothing but a Java compiler. Now imagine someone giving you a copy of Excel. That's the feeling.

In part 2 of this article, we'll get down to business and see how declarative transaction logic actually works. Here's a preview: it's not voodoo -- it's just like in a spreadsheet.

Max Tardiveau is a co-founder of Automated Business Logic.

You can contact him at max (at) automatedbusinesslogic (dot) com.