Software developers who have been in the industry for awhile will eventually notice certain trends in the industry, and meta-trends that play out over decades. One such meta-trend is a shift in what predominantly occupies our time and thought. The (micro) trend here is that we as software developers are always in over our heads with some new technology. There’s always some new Javascript framework to learn (Vue), or data pipeline tool to catch up on (Hadoop, Spark, Kafka). Very rarely do we think about programming abstractions (design patterns, OOP, functional programming techniques like the Cake Pattern, etc.). But there was a time, not that long ago, when frameworks weren’t top of mind, and instead people were thinking heavily about software abstractions.
One of those abstractions, one of the few that I think is useful today, is “Three-Tier Architecture”. If you read the Wikipedia page about this, you’ll find that it’s been taken over by a sort of academic-minded mathematical rigor that reduces it down to axioms and removes all sense from it. Luckily, some people remember a time when Three-Tier Architecture was a new concept, and at that time it was anything but academic. Rather, it was a marketing buzzword. A cool new programming paradigm that your software developers, steeped in OOP practice and dreaming of a shiny future where everything is an online DCOM object, could enable (with the help of Java, or .NET, or IBM VisualAge, of course).
Three-Tier Architecture is simply about decoupling fetching data, making sense of data, and presenting data. The idea is, you put your “business logic” in the middle step. The first step is only concerned with fetching data. The middle-tier wants the last 10 users that registered. Why does it want that? Doesn’t matter. Just provide it. The second-tier, the middle-tier, is where you request data and put it into an intermediate representation. These days, that would be JSON. A long time ago, before everyone decided that XML was the worst thing since “NULL”, that would have been XML. The last tier, the presentation tier, simply converts that intermetdiate data into whatever frontend graphics or GUI library expects to receive.
Doesn’t this excite you? Don’t you want to go out and build this? Think of the possibilities. You could have a fast NodeJS GraphQL backend that provides data. Your middle-tier could be written in a configuration-lite language. (Oh, and don’t forget a security layer in there, to gatekeep who gets to see what pieces of data. It’ll probably monitor the requests between the first and second tiers.) The third tier will be an iOS App. Or maybe a React page. Or maybe a Qt desktop app. Why not all three? Your business logic is taken care of. You just need to present the data, and take user inputs and pass them back to the middle-tier.
If this sounds a lot like Model-View-Controller, well, it’s similar. The main difference is TTA is also an organizational structure. There are clear lines of separation between the tiers. You can have separate teams for each tier. MVC is more about code organization, and more applicable to web monoliths like the average Rails app where one team of devs is responsible for the entire thing.
I really like the idea of TTA, but there’s a reason it’s only caught on in enterprise software development. On small, agile teams (which most companies organize their development into), there’s a pressure to ship frequently. If your work for the week is “worked on business logic in the middle tier”, you don’t have much to deliver to the stakeholders to show your progress. Maybe some green cells in a Google Sheet? That really only flies at large orgs.
Still, it’s always surprising to me how many software devs haven’t heard of this, despite how big of a thing it was once upon a time. Or if they’ve heard of it, they think of it as something from the “bad old days” of Java preeminence. I don’t see it that way at all.