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. 

(You): Hi - we’ve got a website and have been selling products online for a few years - our web guy moved to Switzerland though and we need somebody to make some changes…
(New tecchie): Sure, I’ll look at it.

** three weeks later **

(New tecchie): Man, this site is so screwed up. Whoever wrote this had no idea what he was doing. In order to make any changes I’m going to have to rewrite 30 different pages. It’ll take two months and twenty-six thousand dollars.
(You): What are my alternatives?
(New tecchie): Rewrite the whole site. It’ll take two and half months and cost twenty-eight thousand dollars.
(You): All I need is one product added!
(New tecchie): Dude, you should have bought a Dell…
(You): What does that have to do with my website??!!

Buying a Dell actually has nothing to do with your website. (OK, it could…don’t get all technical on me…) But scalability has everything to do with your website.

There’s actually a very simple reason why the above conversation is quite common: the site that you started a few years ago has slowly grown and gotten more complicated. It is now miraculously held together by layers and layers of rules and code, and attempting to change one thing now is like trying to upgrade the middle section of the leaning tower of Pisa. The tower won’t fall down on its own, but don’t start making structural changes!

In order to avoid scenarios like this, I’ve been using a “three-tiered architecture” approach for years. With this approach, the overall structure of your website looks like this:

With this setup, the data (e.g., product and pricing information), is the foundation of everything. A great deal of flexibility can come in, if the business layer is constructed to properly feed the data to the user interface. Here’s what can result:

1. You decide to change your shipping calculations. Those changes are done in one (and only one!) section of code. The formula is changed in the business layer, and the database and the user interface remain untouched.
2. You decide to add a product. Records are added to the database, and the business rules that read from the database automatically pick up on the new changes and carry the data to the user interface. (Result: “Hey, there’s a new product. BUY! BUY! BUY!”)
3. You decide to change the look and feel of your site to reflect your company’s new branding. Brown becomes orange, graphics and logos change, and navigation gets an overhaul. Your search and shopping cart functionality stays exactly the same though, because your business rules have not changed.

Technologies and programming languages change every day (*sigh*), but principles like this need to be applied everywhere. Over the next several days, I’ll demonstrate how we employ these kinds of techniques to provide scalability and stability to our applications.