A few weeks ago I began a series on three-tiered architecture.  We’ve got a fascinating client that recently was able to take advantage of this structure in a remarkable way.

This project involved an excruciatingly large and complex number of calculations containing financial information.  A series of eleven reports is gradually built from four collections of base data.  Each section of reports begins with the “lowest-level” view (almost raw data) (which is overwhelming), and gradually comes up to higher levels that make more sense.  They then start to phase in the roll-up information from the other collections of base data, until the final reports which neatly tie up everything into a tangible “is this person doing what it is supposed to do” report.  OK, excellent. 

These calculations contain all kinds of industry-defined and proprietary calculations and methods, so that’s the business layer.

The “business layer” was excruciatingly difficult to write.  (Did I mention that?)
Do I want to change or rewrite any of these calculations?  No.  Do I want to forget how they work?  Yes.  Am I allowed to though?  No.  OK, that doesn’t matter, and it’s not the point.

The point is that after all these calculations are made, they need to be stored somewhere so we don’t have to wait 10 minutes to run through all the sets of calculations all over again whenever we want to view the reports.  So we store them in a database.  Hopefully that’s not a real shocker…

The database did have to be constructed with thought.  I’m going to save comments on database design for another time, and suffice to say for now that after it had been constructed (with the business layer in mind), it really doesn’t need to change very much.

So what’s left?  Ah, it would be great if we could SEE these reports.  We’ve got a slew of calculations, and we’re storing all the data and results, now let’s look at them (remember comments on practicality?).

The presentation layer contains a set of web pages that eventually get turned into PDFs.  Cool.  Really cool.  This layer sits neatly on top of our calculations, and HTML does its work, and the PDF generator does its work too.  The reports look pretty darn nice.

Well, we’ve just gotten a very useful update for our PDF generator package.  It has the ability to take the reports from looking “pretty darn nice” to “that’s simply smashing”!  At first I think, “Oh, MAN! I wish I could have had this beautiful update before I started writing this program!  Now I have to do THE WHOLE THING ALL OVER AGAIN!!”

NOT.  (Have you seen that great preview for Borak??)

I’m trying to forget all those dreadful calculations, remember?  (No, I’m not.  Yes, I am.)
And what part about the NUMBERS is going to change when I flip the switch from “big red font” to “small blue font”?  NOT MUCH.

I built a set of plugins to the business layer that my presentation layer calls all the time.  The presentation layer just interprets the results of these calls into — whatever it wants to do.  It used to use version 6 of our PDF generator package.  Well, let’s use version 7 now.  And let’s change the layout slightly to take advantage of some really cool things.  And let’s not take 6 weeks to do it.

Exactly nothing needed to be touched in the business and database layers in order to give our set of reports a complete overhaul.  In less than a day, I sent our client a new set of reports, and do you know what he said?

He said, “Cool.  That looks great.”

That’s the way it’s supposed to be. 

Not, “I didn’t authorize all this work!  I can’t afford a complete overhaul on these reports!”, but “Cool.  You made this whole thing flexible enough to change the look of the reports without breaking a sweat.  I’m really glad you did that.”

Yeah.  That’s the way it’s supposed to be.