Business Rules

Nowadays there is a lot of pressure on the middle tier of the three tier stack from both the database and the smart client. If technologies such as Yukon allow all the code to run in the databases is the business tier of logic required? Whilst the actual physical implementation of the business tier as a separate element may not be necessary the functionality of the business logic is vital as this business logic provides key data validation and business rules checking. I was given a graphic illustration of the importance of business rules checking when I first started work many moons ago.

I was doing chip design for IBM and wanted a chip carrier to put the chip in for testing when it came back from manufacturing. These were large and complex chips with many pins and so required a fairly specialist chip carrier which cost about $50. The carrier itself was only about 1 inch square so was a pretty small item; we did not have any in the lab and so I ordered a couple. IBM at the time (and may still have for all I know) had 10 digit part numbers for everything so I dutifully looked up the part number, filled in the Purchase Order and sent it off to purchasing.

As was usual nothing happened for about a month and then I got a phone call one day from goods inwards. They said that one of the parts had been delivered but as they had only had one in stock in the factory the other was on back order until they started up the production line again. I said I would be down to pick up the part and the dispatcher said “Ok, but can you get down here soon as it’s blocking the loading bay”. This rang alarm bells as the loading bay at an IBM plant is huge, being able to take up to 10 large trucks simultaneously. It was probably 150 feet long, so it was unlikely a 1 inch chip carrier was going to block the whole bay! I said I would be down immediately and the dispatcher said “You had better bring the heavy gang”. The heavy gang were the group that moved major items of plant and machinery such as big compressors or major cooling systems, again it seemed unlikely that they would be needed for a part that I anticipated being able to put in my pocket.

So say that I ran down to goods inwards with trepidation would be an understatement, there had obviously been a major foul up. Sure enough when I got into the loading bay there was a huge wooden packing case about 30 feet by 10 by 10 blocking a vast area, blotting out the light from outside. I gulped and found the dispatcher who pointed to the case and said “There it is”. Visions of my managers face and my intemperate departure from IBM floated before my face. “What the **** is that” I asked. The dispatcher checked his paperwork and said “it’s an MG set”. Worse and worse, MG sets are the combined electric motor, generator, water pump and distribution control system for a very large water cooled mainframe and cost about $500,000 each. That was going to put a dent in the department budget and how was I going to hide it! I grabbed the paperwork from the dispatcher and ran back to my office with my heart in my mouth and his cries of “You can’t leave that here!” floating over my shoulder.

Back in the office I scrabbled through the old paperwork in my drawer and found the original purchase order with trembling hands. Please oh please let the part number be correct! I am very bad at these sort of details so the chances were that it would not be and that would be the end of my career. Alleluia! My original Purchase Order had the correct part number and the dispatcher’s paperwork had one digit in the ten digit part number wrong, hence ordering a 30x10 foot $500,000 MG set rather than a 1X1 inch $50 chip carrier. Purchasing must have made a mistake when entering the details from the Order.

A very quick phone call to the purchasing department to confirm, sure enough they had the correct details on my paperwork but the wrong number in the ordering system. First thing that they said was “Oh, we had better stop them setting up that manufacturing line in France then” The next thing was to ask me if I could take delivery anyway as it was in goods inwards. Uncontrollable and rather hysterical laughter from me gave them the answer to that one! I could just see me asking my manger to sign off a $500K mistake! Anyway I pointed out that it was their problem and they had better sort it out before I put the phone down pronto. I never heard any more about what happened to the MG set but I made do without the chip carrier, I never had the nerve to reorder it.

Anyway the moral of the story was that if the system had business rules checking such as does the order value exceed the budget of the group or any other criteria then this would not have happened. Nowadays of course all systems do have this sort of checking in place but 30 years ago many didn’t, allowing these sorts of mistakes to occur.

It certainly instilled in me a life long appreciation of the value of business rules checking, hammered home with real terror, the very best teacher!

Comments

• Anonymous
  July 03, 2004
  Great story! Thanks for the laugh.
• Anonymous
  July 04, 2004
  LOL! That is one of the funniest things I've read in long time.
• Anonymous
  July 07, 2004
  Nice one. Some people might argue that all this proves is the need for Business Rules validation and not a business tier and will proceed to hardcode rule checking in the tier or all in a single layer in the database. For example, they may store the rules in the DB and just call them from CLR stored procs.
  
  I think its important for people to understand that layers need to be logically separate to enable easier maintenance and flexibility for change and that the ability to put a ton of stuff in the DB doesnt mean you should.
• Anonymous
  July 09, 2004
  Thanks Michael, that one made my day!
  
  In addition to the business rules, it also shows why anything longer than a few digits should always have a checksum digit... And why one should never, never print numbers like that for people to enter by hand, then print for other people enter by hand, then print...
• Anonymous
  July 14, 2004
  Benjy
  Totally agree with you about putting stuff in the DB. Placement is something that should always be carefully considered
  
  Steven
  Excellent point, all too often we forget the simple solutions and rely on technology