For God's sake people, keep your business logic in one place! - Part II

So what's the big deal about keeping your business logic in one place?

Well, for starters, you're going to save your company a lot of money down the road and save probably yourself or another programmer tons of headache every time a little thing goes wrong.

So what can go wrong? Well, if you've been in the reporting business, or written many programs that actually got used, or built out any infrastructures for businesses to hold and move and display their data (like I've been doing the last 15 years) then you know that there's plenty that can go wrong.

The simplest and possibly the most frustrating is simply the customer saying to himself,

"Hmmm... these numbers don't look right. I was expecting something a little different. I bet something's wrong with the data."

So they write up a trouble ticket or send you an email or IM you with this deep logical distrust of your data.

What do you do?

Well, you can do like most IT people do. Say,

"Nope, the data looks good here. Must be something on your end"

If that don't work, option #2 is,

"That would be something caused by so-and-so process at my source. Sorry I can't do anything. But here's the name of the guy that might be able to help you."

(Options #1 and #2 basically are just "he-did-its" pointing North and South, upstream or downstream, to somebody else in line... an ancient IT tactic going back to the pyramid-building Jewish slaves in Egypt.)

But ultimately, if the customer is hard-headed, and other distracting "emergencies" don't pop up instead, it'll come back around to you and you'll have to investigate whether or not the data is getting screwed up somewhere. And where do you go? Well, you have to go top to bottom, beginning to end or where the data starts to where the data ends. And why? Because business logic is everywhere.

Now, if you are just a reporting geek, then that's not so hard because IT hasn't given you any real access to see all the magic they do. (Remember how the Wizard of Oz preferred to hide behind the curtain?) In that case you use option #2 and give them the company salute--that's where you shrug your shoulders and mumble "mmi-donno."

If you're IT, or a reporting geek with privileges, then you have to chase down the problem. And since you or someone else was stupid or lazy enough to toss the business logic all over like an angry baboon slinging feces on the walls, then you get to hunt and dig and use your genius analytical skills and your vast amount of extra hours to try and figure this thing out.

And if there is no problem, THEN, you get to try and hold the hand of the customer and explain over and over again all the different places the data changes at and prove to him that 2 + 2 is supposed to equal  5 and if you're lucky another crisis will crop up and this customer will go away.

NOW.....

If you had obeyed my simple rule of For God's sake people, keep your business logic in one place! you could pleasantly schedule a half hour meeting with the customer, share your desktop, and go,

"Well let's look and see if we can find your data problem Mr. CussToMe",

pull up the whole data flow and go,

“Well, here 2+2=4, ... and next right here 2+2=4, and downstream further yes, 2 plus 2 still equals 4... now we get to the BUSINESS LOGIC layer... hmmmmm ... ah yes... well what's this? Ole' Bobby here must have changed my code! Because it says here that 2+2-5. Heck, I’m pretty sure that’s not right. I'll fix it right away Mr. CussToMe. Thank you for bringing this to our attention. Wow, if only we had someone with your brains working for our team!"

And your job would be done.

Now isn't that a lot nicer?

For God's sake people, keep your business logic in one place!


For God's sake people, keep your business logic in one place. Don't be spreading it all over the board. Some in stored procedures, some in the views, some in the extraction-transformation-load layers (ETL), and some in the presentation layer, yet again some in an Excel by end consumers.


You guys understand fully what "Business Logic" is right? Are you sure? Well, think about it.


Anytime data itself is CHANGED (added, subtracted, recalculated, interpreted, ignored, or even RENAMED--yes, even renamed--because when you 'alias' a data field you've just given it YOUR understanding of what that field means in your mind--giving it 'business logic.')


Here’s an easy example of the last one. Certain data has three fields: Svc_BUID, Cust_BUID, and Order_BUID. You (the data-mover/code-writer middle man) figure, "Hey, this is all Services data, so obviously these people want to see the service business unit ID, so I'll alias that field--",SVC_BUID as 'BUID'." You just added Business Logic. Bam!


The exception (or better understanding) of that rule that:

Business Logic = anytime data itself is CHANGED,


is when you are dealing with the META-data. THAT is ok to mess with and you can spread that all over the board without scattering the golden rule of integrity in good data design ( keep your business logic in one place, in case you forgot already).


You do fully understand what "Meta Data" is right? Are you sure? Well, think about it.


"Meta" is ancient Greek for "above" or "over." Meta data is that abstracted concept of any information that isn't the information itself, but is ABOUT the information. (You have to squint one eye and tilt your head a bit to fully get this.) Meta-data is all that wonderful stuff that a database surrounds the actual data with. So yes, meta-data is the data type itself (int? varchar? nvarchar?), whether it's in XML, or a RDBMS, or on-the-fly bits, all the history of when, who, and where data came from, and again it is also the field name itself--which is the border of the data itself-- and actually belongs in BOTH categories--"data" AND "meta-data."


So, all meta-data CAN be altered, changed, adjusted, transformed, and slung about however you want.


That, in fact, IS the job of the pure IT person. To make one storage point of data properly talk to another storage point of data without actually changing the data itself. These "storage points" of data are things like the Oracle, the SQL Server, the Informatica process, the DTS package, the spreadsheet, even the PowerPoint or the ".txt", ".doc", ".xml", ".html", or ".dat" file type. (Even whether it's Unicode, ASCII, ANSI, UTF-16 etc. character type.) That is all meta-data.


So, let’s recap.


The main lecture point here was going to be:  For God's sake people, keep your business logic in one place.


But, we really had to back up and clearly define what business logic is. And to do that we had to clearly understand the difference between data and meta-data.


So if you’ve changed the data, you’ve added Business Logic. If you’ve changed the meta-data, good for you, hopefully it works, do it anywhere and everywhere you feel like. It doesn’t matter. For God's sake people, keep your business logic in one place!


Business logic: Anytime data itself is changed.