6 principles for web applications that last

In the past, procedural programming methods often produced large, monolithic applications, with every function programmed into the code itself. That led to maintenance nightmares as the code grew more convoluted over time, often ending in what's commonly known as spaghetti code.

Modern web applications avoid these issues with tiered architecture, where the database, business logic, and presentation are loosely coupled. Each tier works with the others to make a single application, but each also operates independently. Building this way takes more upfront effort, and it pays off in three places:

• Security: You can enforce security differently on each tier. The database tier may require more security than the presentation tier, and separation gives you full control over each.
• Scalability: You can scale individual tiers as needed. Cluster the database tier, for example, without touching the other two.
• Flexibility: You can modify or enhance one tier without touching the others, like adding a new presentation layer for a new class of device without rebuilding the application underneath.

How much does architecture matter to security specifically? In a word: It's essential.

Sethi shared a cautionary story on the value of good architecture: "I once reviewed a web-based accounting application where the developers decided to implement their own JavaScript presentation framework with a service-based backend. In order to speed up performance, the JavaScript framework was responsible for making all authorization decisions. The development team was horrified to find out that it was trivial for attackers to bypass JavaScript security controls and access the backend services directly. This effectively meant anyone who could reach their web server could perform any accounting activity, even without credentials. Their architecture made it very difficult to fix because it effectively meant changing the way every transaction occurred. The fix was a very expensive, multi-year effort."

Key takeaway: Separating your web application architecture into tiers dramatically improves the application's security and its ability to adapt over time, and leaves you with applications that grow with your business.

Usability was always important. Now it's a necessity, because user expectations have changed. People expect the well-designed, intuitive interfaces they get from their smartphones and consumer applications, and they bring those expectations to every business application you put in front of them.

Usability is a vague term, though. How do you actually build applications that have it? Three steps:

Talk to users early and often. The first step toward usability is understanding what users want, and that means talking to them throughout the entire process, not just at the beginning.

Develop in small, agile cycles. Miscommunication combined with long development cycles leads to disasters. Developers spend months building what they think the users want, only to learn the users wanted something completely different. "In past decades, development cycles could be months, sometimes even years," Granados said. "Today, it's not uncommon for new code to be pushed every couple of weeks. Quick development cycles help ensure that the team is focused on only the most important priorities. Fast development cycles also prevent teams from wasting months developing a feature that nobody ends up using."

Measure everything. Usability goes beyond asking users what they want. You must also understand how they use the completed application, which is how you know what to improve next. "Once you understand what they told you they want, you need to use analytics and cold hard numbers to see if their behavior matches their words," Granados added. "Measuring user behavior will give you indisputable data on whether or not your app is being successful."

Key takeaway: Users have options, and they're less likely to tolerate a confusing application. Focus your development on usability and on solving your users' problems, and you'll save the time and expense of re-creating an app nobody uses.

Maybe your company hosts its own applications in-house and has no plans for the cloud. Maybe you prefer to keep your applications and data in-house and manage everything yourself. This guide won't try to convince you that one path is better than the other. In fact, plenty of companies are moving workloads back on-premise these days, which proves the deeper point: Deployment plans change, in both directions.

Who knows what the future holds? A new manager arrives and decides everything moves to the cloud. A current manager changes their tune, or a cloud bill changes it for them. When that happens, your applications must be ready. They must deploy anywhere.

The danger of ignoring portability is that it compounds. As Wassell put it, "a lack of forward architecture planning may keep an IT organization stuck on outdated systems and unable to meet these changing organizational priorities. Staying the course and developing with outdated technologies on legacy architecture essentially means investing further in a legacy system that is now incrementally more difficult to move away from."

Key takeaway: Use a tiered architecture to separate the components of your applications, and a language that can be ported to a new platform. When your application needs to move, to the cloud, back on-premise, or to a new database, your resources go to the shifting business priority, not to rewriting or repurchasing software.

Summary

Chances are, you don't want to replace your business applications every few years. You want applications that grow with your company and adapt to changing technology.

Technology is evolving faster than ever, which makes that harder than it sounds. Built incorrectly, a modern application today might be outdated in just a few years, and no business can afford to rebuild on that cycle. These six guidelines put you well on your way to long-lasting, flexible applications:

• Separate your architecture: Tiered architecture dramatically improves an application's security and adaptability, and leaves you with applications that grow with your business.
• Plan for device fragmentation: Nobody knows which platforms or devices will matter in a few years, but you must prepare for them anyway. Cross-platform design positions you for whatever arrives.
• Design for usability: User expectations keep rising. A confusing interface frustrates users and drives them to other options, so build around the user and measure what they actually do.
• Build for integration: Applications that last must communicate with a growing and unpredictable set of platforms and services. Open foundations keep those doors open.
• Prepare for the cloud: Even with no cloud plans today, build applications that port anywhere, on premise or in the cloud, so a deployment change never forces a rewrite.
• Use well-established technology: Widely used, well-supported technologies simplify future maintenance and insulate you from compatibility dead ends.

As technology evolves at an ever-increasing rate, flexibility becomes critical to a company's success. Companies that follow these guidelines lay the foundation for applications that adapt to future changes, whatever they turn out to be.

White paper updated July 2026