Vivek Thakur

I have a very definite opinion on this one, and its pretty simple:

Even though I live somewhere where cost of living is -extremely low-, I get paid several thousands of dollars per month. N-tier architecture, for average to large size systems save programmer and maintenance time. RAM and CPU cycles are cheap (you can get a new computer for like 500$ with dual core now), and Windows Server web edition is about that much. Meaning for every week of my time (and thats if I'm alone. If you have more programmers, its even more pronounced), we can buy an -entire- new server and stick it in a web farm.

In other word, performance is meaningless, it is all about maintenance. 95%++ of choices you need to make should be about maintenance, unless you are making a module that requires very, very high performance (let say, you are making a game in Direct X with Pixel Shaders 3 etc etc etc...). For things like ERP systems, maintenance benifits will almost ALWAYS outweight performance benifits (That is why people are moving to SOA, even though serializing 100000 records to XML and back is an insane performance hit...the benifits outweight the problems: just add a new server)

Francois,

I am of the opinion that if the system is really so big that maintenance matters (like ERP), then it's architecture is bound to warrant a tiered approach. So I agree with you here.

But I have seen people using tiers for small to medium sized systems where there is no chance of scaling the app up. They assume that what they are doing confirms to best practices without realizing that tiers were meant to solve other issues and are somewhat like a Design Pattern, not to be used everywhere.

Even SOA cannot be a norm for every project!

Anyways, like always, I really like your feedback and insight !!

-Vivek