You are writing all your applications with a Client-Server architecture, right?

Oh, wait, this isn’t the late 90’s.

You are writing all your applications as 3-Tier assemblies, right?

Oh, wait, this isn’t the early 2000’s.

You are writing all your applications… Oh, to heck with it.

What’s the architecture du jour these days, anyway, n-tier? x-tier? SOA? XYZ-PDQ?

So what’s all the hubbub?

I propose something radical. Logically tier your code based on functionality, not locality. If you do that properly, monolithic, Client-Server, 3-tier, n-tier, x-tier, tears for fears, it won’t matter.

Why not?

Because if the code is properly organized and logically tiered, you’ll be able to easily move it wherever it needs to go to create (and remove) whatever tiers become necessary.

For example, I once worked for a company building a sizable billing package based on SQL Server. We wanted it 3 tier (Presentation, Business Logic, and Data Access), but we also needed it to be:

1. easy to debug and maintain, and I mean easy, not the “learn how to jump through hoops faster” easy, but really easy. The dev team was small. This was a requirement.
2. easy to deploy in a demonstration mode. If a prospect couldn’t fire up a CD install and in 5 minutes or less be playing with it, it wasn’t going to fly.
3. capable of scale-out deployment to accommodate multiple report generation servers, data analysis servers, etc.

In the end, we designed a server app as the BLL (it actually ran as a service), a database chock full of highly optimized stored procs as the DAL, and a fat client that contained not only the user-facing interface but also the entire server app internally. And the key to all this was that the code for the server was exactly the same code as was in the client. The code was literally shared between projects in our VCS.

When connected to an actual server component, it got all the benefits thereof. But for debugging, it was unbelievably efficient to have both the client and server right there running at one time not only in the same IDE, but actually as part of the same executable. And deployment was a snap because the demo install didn’t have to bother with a server installation, it just created the DB and dropped the client on the machine.

If we’d needed to split functionality out farther, it would have been a very straightforward process because internally, everything was already split out.

The bottom line is:

Get the logical tiers right and encapsulate with a vengence.

Note to self: Vengeful Encapsulation. Sweet band name!