N-Tier Architecture vs 2-Tier Architecture

YeahBaby

Hi folks,

I'm not sure if this is right forum but here goes anyway (if I'm in the wrong spot, maybe ye could point me in the right direction?).

I am trying to build a compelling commercial message for our product and company as regards our product and specifically "how our application is built".

We have developed a N-Tiered .Net software application to run our customers operations and business (transactional operations at the counter, control reporting, management reporting, Regulatory reporting, integration of other services etc.)

Our main competitor's application has been developed using 2-Tiered architecture.

The message our sales team (of which I am a member!) currently relates as regards 'how our system is built' (particularly when up against our main competitor), is as follows:

• N -Tier is More Secure (Database and Application held on different servers, with more security controls)
• More efficient management on N-Tier (Deploying Updates & Fixes is more problematic on 2-Tier where the application is held locally on the users PC, therefore Releases and Fixes have to be rolled out to each client/workstation. On a N-Tiered platform software releases are updated to the Application server and all thin-clients see this immediately)
• Portability of Solution (easier to move IT supplier on N-Tiered Architecture)
• Scalability of N-Tier (adding other services is much easier on a N-Tiered platform)
• N-Tier is Less Expensive Longterm (The Total Cost of Ownership will be lower as N-Tiered Architecture is the most current development environment and methodolgy, 2-Tier was first developed in late 90's, early 'Noughties' and has now been surpassed and is dated)
• Future Proofed Investment (as above)

My questions are as follows:

Are we positioning the differences between N-Tier and 2-Tier correctly?

Is there anything we are overlooking in terms of the differences between both architectures?

What are the business benefits of using N-Tiered Architecture over 2-Tier Architecture?

Why should a customer be happier with a N-Tiered application rather than a 2-Tiered Architecture?

Feel free to ask me questions (being a non-technical guy I'll answer them as best I can). Our customers are SME's and would range from 3 to 33 employees in the finacial services sector (they are regulated by IFSRA) and typically have no internal IT resource.

Any thoughts would be appreciated.

Regards

YeahBaby.

kayos

If I was part of a possible clients technical team I would read the above and laugh while muttering the words “who let the business guys write about tech stuff”

First off N-tier does not have to have multiple physical servers N-tier has nothing got to do with the number of servers involved in the deployment. N-tier refers to splitting out the different functional areas of a system generally into the presentation, business processing and data access tiers. These can all reside on the same physical server, they could be on multiple servers.

• N -Tier is More Secure (Database and Application held on different servers, with more security controls)

Rubbish, an application is only as secure as the code its made up of and the security settings applied to the physical servers. Being N-Tier does not make your code more secure that has to be programmed in. If your application is n-tier does not mean its safe from say a SQL injection attack. Heck if you are say passing passwords from the presentation to the apllication layers over http and its not encrypted then thats another place for those pesky hackers to get at. You need to code defensively, test excessively, and lock down the permissions in order to secure and application.

• More efficient management on N-Tier (Deploying Updates & Fixes is more problematic on 2-Tier where the application is held locally on the users PC, therefore Releases and Fixes have to be rolled out to each client/workstation. On a N-Tiered platform software releases are updated to the Application server and all thin-clients see this immediately)

You are really comparing a thin client to a rich client here. Its nothing got to do with your n-tier architecture. N-tier can involve both thin and rich clients or both. And with respect to rolling out rich client updates there are plenty of tools available to do this automatically for you (basically the rich client checks for an update when started and will download and install it if found) .

• Portability of Solution (easier to move IT supplier on N-Tiered Architecture)

Ya wha?

• N-Tier is Less Expensive Longterm (The Total Cost of Ownership will be lower as N-Tiered Architecture is the most current development environment and methodolgy, 2-Tier was first developed in late 90's, early 'Noughties' and has now been surpassed and is dated)

N-tier is cheaper than client server? How, show me the figures? In both cases I will need some servers, I’ll need to host those servers be it in house or with a 3rd party hosting company. Then there will be the client PC’s and well they are gonna cost the same either way. The only saving might be the deployment costs of the updates to rich clients but see my above comment on that. When you refer to 2-tier you are really talking client server and that’s been around a hell of a lot longer then the late 90’s.

• Scalability of N-Tier (adding other services is much easier on a N-Tiered platform)

Like your comments about security Scalability is something your code and its quality determines. Scalability is about the systems ability to scale with the business i.e. growing from 100 transactions a day with 10 users to 1,000,000 transactions a day with 5,000 users. Believe me just because its n-tier does not mean its scalable. When you say services there are two ways to take this you made a typo and mean servers in which case that’s not always true but should be. If you mean adding functionality then that’s just as easy or hard on either tbh.

• [Future Proofed Investment (as above)

Is it? You can build n-tier in VB6 but I sure as hell would not call that future proofed. What technologies was the system built on? Can you promise that it will work on say windows server 2008 with 0 changes needing to be made? What about the next version of say SQL Server? edit rereading and seeing you said .NET fair enough.

Are we positioning the differences between N-Tier and 2-Tier correctly?

No not at all your making a balls out of it from a technical point of view. Talk to your technical team to get their input.

And bold, bold, bold sales team. Never, ever, ever write technical sales speak without talking to your technical team. You will lose sales if you do.

Also stop bashing one way of doing something and start promoting your way and your software. What are the main features of your system? What does your have in terms of functionality that makes a client go oooo I want that. It might not be available in another suppliers software but dont go bashing that system due to the lack of it.

fergalr

Yeahbaby:
Your first mistake was admitting you're part of the sales team on a programming forum. :P I'm kidding, but bear in mind it might influence some of the responses you get.

Have to say though, I think Kayos is pretty spot on in most of what he has posted.


First off, I mean, 'N' tiered architecture? While you might talk generally about the merits of a 2 tiered architecture versus a many tiered architecture (eg 3 or 4 or whatever), talking about N tiered architecture in the sales literature for a specific product strikes me as strange - Presumably the company for which you work knows how many tiers your architecture has? For me, it would come across much stronger if you were talking about your 3-tiered architecture, or 4-tiered architecture or whatever - it shouldn't be N in your specific product unless the amount of tiers somehow changes dynamically (??).


You do frequently see sales literature talking about the relative merits of client-server vs. [your specific number of tiers] tiered architecture.


As Kayos has said, most of the benefits you describe come from the implementation of the architecture, rather than the number of tiers used.

But some of the technology used to build modern multi tiered architecture is more scalable or secure or transferable or future proof that what was used to build 2 tier architecture in the past. And extra tiers, does, to some extent, allow you to more easily swap out a specific tier if it changes (changes to the presentation layer are easier now, fairly generally)
You could certainly say that you are using specific technologies built to support 3 (or whatever) tier architecture that are quite secure, or scalable, more so than typical client-server technologies of the past were; and built on industry standard scalable and secure components and technology.

You could also say that a less monolithic backend, designed in the well designed way that your speicific multi tiered system is, allows for good separation of presentation from business logic, and business logic from data storage etc.
If you give specific examples of the technology components you use, or a few broad brush strokes about your specific system design, it will come across as much stronger.

I understand it's sales literature, not technical; but if you ground it a little more in reality, it'll be much more plausible, and stick better - from a technical point of view, at the moment, it doesn't really work - the claims made aren't meaningful in the context provided.

kayos

fergalr wrote: »

Yeahbaby:
Your first mistake was admitting you're part of the sales team on a programming forum. :P I'm kidding, but bear in mind it might influence some of the responses you get.

Ah its part of the love hate relationship between techies and business people . That and a day of trying to reverse engineer a horrible spreadsheet lead to a more direct approach.

fergalr wrote: »

But some of the technology used to build modern multi tiered architecture is more scalable or secure or transferable or future proof that what was used to build 2 tier architecture in the past. And extra tiers, does, to some extent, allow you to more easily swap out a specific tier if it changes (changes to the presentation layer are easier now, fairly generally)

While you do have some merit in this I would also say even the most modern technologies out there are more forgiving that does not automaticly mean a system built on those techs is scalable. They come from good design and good coding. I've seen plenty of .NET systems that would fall flat on their face if scaled past say 20users Poor coding in modern techs is just as big a worry today as it was years ago.

Any way you really should be talking to your Architects for the information they know your software, they designed it and know its plus points, its abilities etc etc

Simple architecture diagrams showing the tiers, the connections, how clients can connect vpn/lan/http, the DAL pointing to all the different types of Data sources you support etc can all be done in visio in a couple of drag and drops and do a nice job of giving an overview.

Thomas_S_Hunterson

OP you'd want to be careful going into a presentation. If your clients send a techie, they will see through sales-speak quite quickly.

Just make sure you know enough about the product to back it up.

ressem

While YeahBaby's has provided very little information about the product, the impression I got was that it was a hosted service.
It'd be a bit much to have a customer company with 3 users with 2 servers.

If this is the case, then you meant to compare your hosted service to your competitors client-server architecture. If I assume that you are correct about your competitor, which I would not.

Either way, I'd go along with kayos's review. I'd think less of your company if presented with a writeup containing pointless falsehoods like those above.

2-tier can be described as N-tier where N=2. So you'll notice how silly 'the message' sounds.


-- Off Forum --

Mentioning 4 tier is probably not worth one line, especially as you may be asked to explain; distracting from the sales pitch which should be kept to the topics of solving real problems and reliability.

In which case going on about N-tier architecture to the prospective customer is a waste of time. It's an internal detail to your company that if done and used properly might save the developing company some mistakes, money and effort.

A section on "How our application is built" would be better used trying to convince people on how safe, secure yet readily available their data will be with you.

) Describing how the hosting provider has internet connectivity that does not rely on only one provider; how your hosting platform has no points of failure with regards to power, networking equipment, hardware; how the software/ hardware uses load balancing / clustering / reliable storage to ensure reliability.

) Copies of real audit procedures which detect and discourage your staff from looking at data out of curiosity.

) Do you want to be able to help when a user does something dumb like hitting the wrong delete button and isn't noticed till the new year? Real copies of your backup and restore procedures.

) Copies of test logs giving confidence that you have tested and know the point at which your application becomes unreliable or provides a poor user experience, and that you'll recognise and resolve such a situation on the live service before it becomes an issue.

) Convincing them that your mandatory updates will not corrupt their data or result in incorrect reports. Which might be demonstrating that your company's techies understand and implemented the database access layer and store correctly. You might get away with a few buzzwords here.

Basically proving to your customer that your company has done the hard work properly and professionally.

Sorry, but the contents of your post suggest poor internal communication, understanding and documentation.

stephenlane80

N-Tier relates to software architecture rather than physical server layout, which you could host on one server so it doesnt necessarily make it more expensive in terms of hardware.

The reaon N-tier is popular compared to other architecture is that it is very scalable, as you know each tier can be geographically dispersed and within each tier, it is easy to bolt on extra boxes if load increases.

ressem

N-tier is popular compared to other architecture is that it is very scalable, as you know each tier can be geographically dispersed and within each tier, it is easy to bolt on extra boxes if load increases.

Sorry stephenlane80 but that's not correct. And that's the point made by the others to YeahBaby.

If your app can do so, then it's a feature of your app and it's environment (by which I mean OS support for clustering, web server/ hardware load balancing, memcached distributed caching etc).
Not of N-Tier architecture.

For example the data store could be an embedded sqllite database or even a text file; the data tier could just be a list of 'get' and 'set' method calls which contain a hardcoded filename pointing at the local data store.
No support for increased load or distributed anything.

The application could still 'qualify' as having a tiered architecture, with separated business controller, business objects, user view tier and data tiers, written with well-defined interfaces between each tier.

Having an N-Tier architecture does not assure of any performance or scalability capabilities.
The customer has to rely on implementation and testing details.

fergalr

stephenlane80 wrote: »

N-Tier relates to software architecture rather than physical server layout, which you could host on one server so it doesnt necessarily make it more expensive in terms of hardware.

The reaon N-tier is popular compared to other architecture is that it is very scalable, as you know each tier can be geographically dispersed and within each tier, it is easy to bolt on extra boxes if load increases.

StephenLane:
Those too statements appear, at least at a glance, to be somewhat contradictory.
In the first statement you say n-tier doesn't relate to physical server layout, and the the second statement you say that n-tier can be geographically dispersed.

How can n-tier be more geographically distributable if the term doesn't relate to physical layout?



I think there's some semantic confusion here with what's been referred to by n-tier.
How would a client-server system, where the server part was distributed across multiple machines fit into this (crude, two-choice) taxonomy?

stephenlane80

hmm, i think were getting our wires crossd a little it here

ressm: i agree with you !!

For an application to be concidered n-tier like you say i just need to n seperae layers or dll's

That not to say that the objects will be kept on seperate systems, they may all be kept on one server, but the ALSO may be kept on multiple ervers if load increases,

A typical layout might be:

Application server for presentation layer on server1
Business objects on sever 2
text file data source server 3


But you could also have the exact same software on this hardware config:


Application server for presentation layer on server 1
Business objects on server 1
text file data source server 1

in secenario one you could also set up a cluster for the application server
and likewise for business objects or database if the load increases

agree ? no ?

ressem

Nearly :->
You're right and I'm wrong in that I did the old 3-Tier vs 3-Layer mixup for a bit of my last post.

So can I set down the scenario below as a possible setup for the OPs product. Borrowed from http://pranshujain.wordpress.com/2006/09/15/layers-and-tiers/

Now coming to physical architecture:

a typical way to keep the tiers in a web application is

<Firewall> Web Tier (Presentation Layer) <Firewall> App Tier (Business logic + Data access layers) <> Data Tier (Database/file system).

It is entirely possible to load all tiers into the same machine, but it is important to take care of not being dependant on references when going across tiers.

I still hold to the bit where I said that when you need cope with extra load, simply having a n-tier setup doesn't get you very far.

In the scenario above, it would be IIS / network hardware / akamai that would have the job of splitting up the incoming requests. The data tier would require it's own load balancing or request caching.

To support load balancing at the App Tier might require major recoding in the surrounding layers to use message queues or some ORB or changing communications so that they are stateless.

Your normal windows cluster primarily works to provides redundancy in case of failure. (Windows HPC server 2008 aside).

So I'm just saying that the system could be N-Tier and still be completely unscalable without major development work.

Which is why I think that the OP should provide details of testing rather than a mantra on how N-tier means this, that and the other.