The Point of N-Tier Architectures

For the longest time whenever the question of software architectures in web applications came up, the N-Tier architecture was the front runner. And why not? It is flexible ,scalable,very easy to model and more importantly – easy to communicate. In fact it is so common that there are code generation tools, and frameworks galore for it. I like N-Tier architectures – for the reasons I mentioned before – however, I have seen many occasions where this particular approach is used as a panacea for all ills. Every application – regardless of its size or the business problem is given the N-Tier treatment :-)
In most cases this is overkill – especially in departmental intranets that service a finite number of people. Sure, the solution would be scalable and flexible but that comes at a cost – performance – N-Tier architectures – in my experience, are actually slower when compared to single tier architectures – more scalable but slower…
This means that if your web application has an audience that is fairly stable and specific business requirements you would be better off designing a simpler application that meets the need. By lowering the number of objects that need to be instantiated and simplifying the logic needed, a significant improvement in performance, as well as a marked reduction in the complexity of the code could be achieved.
The biggest argument against this approach is of course that of ever changing requirements and scope creep and the need to obviate that by introducing flexibility in the code. The argument is a valid one and compelling one. However, this risk can be mitigated by insisting on making clear the goal(s) of the application. Once that is clear, it is easier to distinguish between requirements that support the goal(s) and ones that change them completely :-) In my experience, there have been very few occasions where major changes in the goal(s) did not require a major re-design of the application – regardless of how modular and layered you make the application. In fact, in these cases it is far easier to refactor or even throw away and start again, if the application was not very complex to begin with.
All this being said – I must point out that N-Tier applications have their place – all I am saying is that using them on every software problem is like using a bulldozer to drive in a nail – you could do it far more easily and a lot cheaper and easier with a hammer …

Advertisements

4 comments on “The Point of N-Tier Architectures

  1. N-tier also means more software licenses for vendors and hardware sales for hardware manufactures. If you read any n-tier articles from vendors they doesn’t seem too interested in the logical n-tier design per say but but rather tout how you can separate all your code out using logical tiers to separate machines using various middleware solutions – eg more licenses to sell. Remember Microsoft DNA? MTS? (aka COM+ Services) CORBA? EJB? DCOM? RMI? RDS? Do you remember a few years ago how hard vendors were pushing middle ware to “glue” your system together via a SOA architecture? And they still are trying to push SOA heavy for all kinds of solutions. Why? Is it because they want you to be a master software developer or is it because they sell messaging middleware like MSMQ, MQ-Series, SonicMQ? Who is using these architectures today for new application development? What is interesting is how many new designs refer to objects as POJO’s (plain old java objects) and “pure managed code.” N-tier may be a good design depending on the requirements and what you are trying to accomplish – something that seems lost in today’s world of software development. But at the end of the day your are trying to build something that not only does the job but you can maintain and communicate the inner workings to other developers. Not make more money for the vendors by killing a bug with a sledgehammer.

    http://www.networkcomputing.com/gallery/2006/1109/1109f1poll1.jhtml

  2. Its a common problem for almost any tasks people undertake. You should always take the time to figure out the correct process for the task before you. The task will always dictate the best procedure and tools.

  3. This falls under the “I have this tool and I’ll use it for everything” category. Also, I think there is a valid argument for the architect/engineer that decides to use a simple architecture knowing that at a certain point it will need to be altered. This way you can develop to the speed and budget that is appropriate for the time. The difficult part is knowing the trigger points for when you should have the scalable solution ready.

Comments are closed.