Smart Architecture Published: 1/17/2009

I've been an Information Technology professional for nearly 15 years now, working in a variety of fields ranging from utilities to transportation logistics to market research. The last 10 years I've spent primarily as a system architect / designer on everything from small Windows desktop utilities to enterprise client / server systems. I've been fortunate enough to have ridden the wave of new technologies, embracing things like XML, AJAX, and new versions of .NET as early as possible.

I'm a firm believer in the architectural concept of abstraction, which lends us the concept of seperate application tiers; encapsulating components of a system and enabling component reuse and system scalability. Too often, however, I've seen these principles abused in one way or another. Misunderstood by those who fail to apply them when needed, and equally by those who overuse them in situations where virtual separation is more appropriate than physical.

It's the latter I feel compelled to discuss today. Simply put, there are times when physical separation of logical tiers is not only unnecessary, but causes problems where there need not be any. I've designed systems to be lightweight and easy to maintain, where requirements alow, for example, direct binding of UI elements to a combination business / data layer made up of stored procedures, views, triggers, and tables in an SQL Server database. In cases such as these, it makes little sense to encapsulate and separate the logical layers of the application into actual physical ones. More is not always better. With no benefits per requirements, such abstraction creates unnecessary layers of code that must be loaded and executed at runtime, and understood, documented, and maintained at design time. It also denies developers the option of taking advantage of industry-proven rapid application development tools (such as those found in Visual Studio .NET).

To be clear: I'm talking about systems without complex business requirements or large and intricate data sets. Designing and building an intricate and complex physically separated multi-tier system from requirements such as this is like using a wheat thresher to mow your lawn: it's over-expensive, unwieldy, and simply not a targeted approach.

Why write and maintain hundreds of lines of business logic and data access layer code when you can bind a DataGrid to a set of stored procedures containing exactly that - your business and data access logic? That's like hiring a chef from a 5 star restaurant to make you a Pop Tart. Why insert custom physical business and data access layers into a design when a DataAdapter and DataSet address the exact same functional requirements? That's like hiring an electrician to replace a light bulb.

It's easy in the IT industry to adapt a set of unwavering principles and never look back. We all have so much to learn and understand in an ever-evolving world that it's comforting to have absolutes to hall back on. "Always have physically separate application tiers" or "never use GUIDs as primary keys" (I'll discuss that one in a later post) - this is a dangerous and slippery slope, because above all else, the transitive nature of our industry requires that above all else we remain flexible.

Only if ont truly understands a concept can one make a determination to abandon it in certain circumstances. Failing to evaluate a project's unique requirements and coming up with an appropriate and optional targeted solution is an indicator of ignorance. Only fools make blanket statements, and only a fool would go to a neurosurgeon to get a hangnail removed.

It boggles my mind how some people can rise to the level of, say, System Architect, and still not know this. The key to success in any industry, but even more so in one as fast-paced as ours, is flexibility and using the right tools for the job. I urge anyone who is in any position of design responsibility to remember this.

Questions or Comments? .

VB to C# and C# to VB translation provided by Instant C# and Instant VB.