Business logic centralization

Ted Neward has a string of recent entries starting with The 11th Fallacy of Enterprise Computing (related to the location of business logic), More on the 11th Fallacy and Craig responds to the 11th Fallacy with an item about middleware (or the 'middle tier') tossed into the mix. Ted may (or may not) have intended these articles to be a collection, but they do hang together.

One of the big changes we've seen happen in the last twenty years (or so) is the migration of business logic from the central core of the business to the edges and back (server side to client and back to somewhere in the middle). Harry Pierson sees this strictly as a scalability issue in Is the Middle-Tier Endangered? and The Endangered Middle-Tier, Part 2.

The reality (as I see it) is that any system with any kind of longevity will always require some kind of glue around the edges of the database to deal with changing conditions. Systems need to grow and the rules one can create at the database level are still rather rigid and limited, so you need an enforcer until you can ensure that all records have been set up to meet the new conditions (transitional situations which must occur live as a system grows). You'll also need to deal with old and new systems who need to read and write; which requires an adapter layer in the meantime (we've opted for a permanent adapter layer which de-couples changes on both sides). A lot of people are using web services to create these adapters today, which isn't altogether a bad thing.

A big part of the problem people have with client level business logic is the difficulty in updating the client. It's not so much offloading the problems there but simply getting the correct information in place. If you can assume a frictionless model in which clients can get an update on the business logic any time they need to (which is where some people are driving service models), you should be all set, right? The big win of using a meta description of business rules exported to clients is that the rules can change while the client stays the same and that the client can do native error checking and reporting (always good from a user perspective). The problems with this approach are twofold; one often acknowledged, the other largely ignored.

1. The one that (eventually) everyone gets is that you can only change behaviors based on the meta data the clients understand. Over a long period of time, with many client versions that need to be supported and a growing number of behavioral decisions, things can (and usually do) become quite complex.

2. What is less well understood by most who jump into such systems is that client side rules are client side rules. What I mean is that the rules may live server side, in a central database even, but they are only for client consumption.

   Rarely are the rules constructed in such a way that all systems involved read from and react to a standard set of rules (even if that would be good). Unfortunately, because the rule sets end up being client side only, they occasionally get seriously screwed up and no one notices until customers complain, which leads to client side code to verify the verification rules and if they look too deranged, the client drops back to a minimal rule set. At which point someone complains because the clients are working (and ignoring the rules!) It's a vicious circle.

   If you absolutely need to centralize rules, make sure everyone lives by those rules.

It's certainly true that you are better served by keeping all limits and other potentially hard coded data as far away from clients as possible, but you will and you must allow clients to make decisions and that's the place where hard decisions that have a long term affect on your business will be made. Clients have a bad habit of living way beyond even the most pessimistic predictions.

There doesn't seem to be a perfect place to create business rules in my experience.

Addendum:

I wrote this last weekend while thinking mostly about back end and client issues. I stuck it on the shelf because I wanted to give it some more thought.

Out it goes now because of other events of this week, including some meetings during which we considered cloning significant chunks of decision making capability from one system to another. Without synchronization of some kind, the end result might not be pretty.