>
>But can you justify the extra time spent going the n-tier route? For a large project you could look at doubling dev-time, if the project is a 3 year project, and going n-tier moves it to 6 years, are you ever going to get that dev-time back via the future rewards of choosing such an architecture?
>
>I haven't read 1 success story based on this system of development yet.
>


I have seen cases where an n-tier system is implemented where it wasn't really necessary. In those cases, I agree with the bulk of your argument.

But remember, sometimes system requirements really scream for an n-tier solution. In that case, even if the system takes 3 times as long as it would if it didn't *need* to be n-tier, and therefore could be done 1-tier or c/s, the n-tier approach is a success because it met the specs.

I worked recently on an app that required access to the data for various medical folks. Sometimes these docs and nurses and assistants worked with the org's patients at the worksite. Sometimes they saw patients for the organization at their own offices. Sometimes they worked out of mobile vans. Sometimes they saw them at community fairs, etc. In this case, an n-tier system absolutely made the most sense. Yes, it took a lot more time and effort than a client-server or single-tier system that would have been accessed in-house, or over a vpn. But that wouldn't have met the needs.

The real danger is the cool-new-thing for cool-new-thing's-sake approach. (Here's a similar example: last week, someone asked me if I could spec out the writing of his pretty-complex HR data entry app for PDAs. When I asked why his company needed this, he responded "I just feel like PDAs are going to be the next big thing." He may be right. But, he didn't really answer my question. If he's about to undertake a clunkier design and spend money on the porting of the app, I advised him, he'd better be sure the current c/s system really wasn't meeting his needs.)