Click here to Skip to main content
15,906,625 members
Articles / Web Development

12 Attributes of a Good Web Application Architecture

Rate me:
Please Sign up or sign in to vote.
4.78/5 (5 votes)
11 Nov 2014CPOL5 min read 20.8K   10  
12 Attributes of a good web application architecture


So you have a working web app but is the architecture any good?

While every solution is unique, there are a few attributes that any good web application architecture should display. If you have been asking yourself the questions I listed previously, you should have a solution that shows most of these attributes.

Have a look at your last web app and see how it scores on this list of 12 quality attributes.

Developer Productivity

Since smart people are the most precious resource you have, any framework or architecture we adopt needs to help optimize developer productivity time.


  • Simplicity
  • Concise but not obtuse
  • Standardized way of doing things
  • Great supporting tools
  • Short feedback loops
  • Expressiveness
  • Quality 3rd party packages?


The elegance of the solution speaks of how well the solution fits the problem space and how coherent the solution is.


  • Consistent way of solving a problem
  • The most common tasks are the easiest to do
  • Clear guidance on how to make architectural choices
  • Easily extendable in the appropriate places
  • As simple as possible but no simpler
  • Strong cohesion / low coupling
  • The problem space forms a large percentage of the frameworks solution space


Usability is vitally important for a number of reasons. It improves trust, customer satisfaction and reduces support costs. Any technology you use should allow you to build a world class user experience.


  • No vendor specific technologies
  • Support the latest standards
  • Must provide fast response times in the UI
  • Allow for use of graphic and charting capabilities
  • Allow animation where appropriate
  • Must support A/B testing
  • Must support analytics


Security is the capability of a system to reduce the chance of malicious or accidental actions outside of the designed usage of the system, and prevent disclosure or loss of information.


  • Passes 3rd party penetration tests
  • Uses security standards wherever possible
  • Follows security best practices


Reliability is the ability of a system to continue operating in the expected way over time. Reliability is measured as the probability that a system will not fail and that it will perform its intended function for a specified time interval.


  • It doesn’t crash
  • Autonomic – when it crashes, it heals itself
  • No single point of failure


Performance is an indication of the responsiveness of a system to execute specific actions in a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place in a given amount of time.


  • Support an appropriate level of performance
  • Low latency to the UI (< 250 ms for 90% of requests, <2s for all requests) or provide mechanisms to compensate (messaging, caching, etc.)


Scalability is the ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged.


  • We prefer scaling out to scaling up
  • Easy to add more processing nodes
  • Easy to load balance new nodes
  • Each node should be low overhead
  • Licensing should not prevent scaling


Testability is a measure of how well a system or components allow you to create test criteria and execute tests to determine if the criteria are met.


  • Provide mechanisms to mock data.
  • Trigger back end processes via scripting
  • Batch processes should be fast when using small data sets
  • Easy to create known data
  • Ability to automate UI testing


Do you play well with others? Communication protocols, interfaces, and data formats are the key considerations for interoperability. Standardization is also an important aspect to be considered when designing an interoperable system.


  • Use open standards where available
  • Publish standards where not available
  • Provides you with many options when selecting 3rd party systems

Transparency and Troubleshooting

When something goes wrong, how easy is it to track down the error and re-produce it?


  • All errors and important events are logged in a meaningful way
  • Easily comprehensible stack traces
  • All data needed to re-produce an error is included in the log
  • Debug logs can be turned on and off
  • It should be easy to trace an error all the way through the application.

Community and Product Growth

There should be a strong community behind the product you are using. Having other people who have already solved the problems you are facing is a major factor in how easy a product or framework is to live with.


  • Many plugins and open source projects related to the framework
  • Active repo on github if it’s open source
  • Lots of questions and answers on stack overflow
  • A Google trends graph that is going up and to the right
  • Many books, blogs and tutorials


Deployment and propagation through different environments is a huge cost. A product that is difficult to deploy requires longer release cycles and makes it harder to respond to change or fix bugs.


  • Automated scriptable deployments
  • Automated tests are easy to write
  • Fast build times
  • File based configuration or easily scriptable configuration
  • Small physical size
  • Licensing should not prevent multiple environments
  • Easy rollback

How Do You Stack Up?

Next time you evaluate a web stack or your application architecture, go through this list and try to see if you can tweak your design to tick more of the boxes outlined above. If you keep these attributes in mind while building your app, you will end up with a better end product.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Architect Allan Gray
South Africa South Africa
Since I was young I always preferred teaching myself to learning from a structured syllabus.

This didn’t always make me popular with my teachers. I guess sleeping through the whole of Romeo and Juliet in an English class doesn’t make a great impression. On the other hand I formed an obsession with always researching something.

Over the years these obsessions would jump from topic to topic ranging from physics to lean manufacturing. Photography to functional programming. Cognition to physiology and strength training. Kitesurfing to fire poi. My obsessions may be random but are always led by my curiosity.

Over time I noticed that I was forming connections and finding patterns in unrelated fields and using knowledge I gained from studying the rudiments of things like cognitive psychology when trying to figure out why I was seeing certain behaviours in the teams I was working in.

I'm interested in communicating those underlying principles and connections in a way that is useful to others.

I have been working as a programmer, architect and manager for the last 12 years so there is a strong bias to helping junior programmers and software development teams improve.

I focus on underlying principles and not technologies.

Comments and Discussions

-- There are no messages in this forum --