I'm not saying you're always wrong or that I am always right :-)

Here's a concrete, real-world example to chew on:

Insurance facilitation firm, about 10 employees. Their job is to manage risk participation for health care insurance. The paperwork is starting to overwhelm them; they are accidently storing multiple copies of the same contract and there is no standard of tracking where contracts have been sent, when they are due back, and what process is followed for a particular type of contract.

For security reasons, they don't want documents stored as DOC files or otherwise editable externally. Each clause in a contract should come from a standard boilerplate also not stored as a distinct file.

The contracts are confidential documents and always sent by receipt mail or courier. They do not want the ability to see these contracts over the net; in fact, they are very concerned about someone hacking into their net connection and grabbing documents.

So I ask you, where's the physical n-tier in this? I feel compelled to distinguish between physical and logical.



>yuck... i disagree. It's pure hell to reformulated a monster app to be n-tier after-the-fact. It's much much easy (not too mention cheaper) to design a new app n-tier, and then the subsequent evolution into maturity is so much easier to manage when it's starts out n-tier. If you already have a monolithic app, you've already cooked your goose in my opinion... and I say this because even before n-tier, big apps should of been broken into independent modules atleast, not too mention layered classlibs. And since your goose is cooked, you got twice as much work to re-bake that same goose as n-tier as opposed to taking a fresh goose and doing it right from the start.
>
>Rewrites are always more work, more hassles, and more money than fresh writes... even when the architecture is the same. Even if there's no enhancements to the existing app... it takes more time to sort out the mess in monolithic app than it does for a sharp cookie analyst to draw up accurate requirements on a fresh slate.
>
>And when the rewrite includes an architecture switch, well you just made the work/hassles/money double. In my opinion and experience, rewriting an app to be n-tier will cost the client more money than what they've already invested into a monolithic app that gave no consideration whatsoever to any type of layered/modular/scaleable approach. And that's why I'm not surprised at all by the stat of more single tier vs. n-tier. Of course there's more single tier! And that's because it takes a lot more resources an expertise to do n-tier right as opposed to single tier (it's easy to make bad single tier work than it is to make bad n-tier work). But the pay off is in the long run with n-tier ROI, it just takes a lot more effort to get there for well evolved business processes that need re-architected as opposed to a brand new process.