If you’re in Enterprise IT, you’re going to hear one buzz-word a lot. The buzzword? 2-tier Architecture or 3-tier architecture. I like to refer to it as n-Tier architectures. So what exactly is it and what does it mean?
A Tier in an architecture is simply the number of layers of an application or system between the customer (end user and the data). The question is why is this important and WHY would you want one?
The reason is throughput, modularity, and redundancy (if done properly).
The traditional 2 tier architecture.
A simple example of a 2 tier architecture would be wordpress or any application where the application actually accesses the data / database directly.
This application architecture is sufficient for small websites, but they offer little to no redundancy unless you have someone who really knows what they’re doing to make it more than redundant. In fact, one could with little effort turn a 2 Tier architecture to a 3 Tier Architecture. While this is the most simple form of a data driven architecture, it serves it’s purpose, but isn’t considered a true Enterprise Architecture. Luckily, I have the skills and knowledge to make thing my 2-Tier wordpress Architecture perform like a true n-tier architecture application with all of the bells and whistles including redundancy. It wasn’t easy, but then again, nothing worth it ever is it.
A more common architecture today is the 3-Tier architecture. This includes the Customer Presentation layer (web or application interface), the middleware layer which includes a modular component that if properly architected and implemented will be completely modular and allow customer applications to be modified very easily. For example, imagine you have an application that takes in data and converts it to multiple formats.
In an ideal situation, each output format would be written into a module and the appropriate module would be called and the data would be formatted into the module’s format and returned to the presentation layer. This gives the application architecture and the application provider to offer additional formats in the future. Whether they are simple versions of a format or transaction and all of its various anomalies based on the errata that always comes with the standard as it changes over its lifetime.
If a customer asks for a bridge to another application infrstructure, a module can be written and plugged into the middleware allowing the two systems to be integrated with very little or no disruption.
This is a good example of a 3-Tier architecture. You can do hot-backups and implement redundancy with the middle tier. Performance is also increased, because you can connect to the third Tier (Database or Datastore) as a clustered instance and transact your EDI processes against a cluster member that is not overloaded. (As compared to a two tier architecture).
As architectures grow and applications become more complicated, the number of Tiers can grow, hence, the name n-Tier.
In an ideal world, most applications would be built as n-Tier architectures, but unfortunately, this is not an ideal world.
Hopefully, this helps the people who are looking and planning architectures for their various applications. Designing an n-Tier architecture is not something you can just pick up overnight. In fact, I’m going to warn many of you that “middleware” packages are NOT and should not be considered once sized fits all. If a vendor tells you it is, be wary, and implement the solution in your Lab environment against your real situation before actually buying the product. If the vendor refuses to work with you on this task and requires a purchase prior to this test, Caveat Emptor.