The Anatomy of a Web Application

Web Production consists of three core disciplines: User Experience Design, Interface Design and Development, and Software Design and Development. As a practitioner of each of these disciplines, I have long noted the great divide between the communities. The software community deals with software design and development, the interface community deals with interface design and development, and the user experience community deals with user concerns, or more specifically, the web application’s purpose.

The simple fact is, that in any web application, the degree to which the activities of each of these disciplines are done well will determine the application’s value. Weaknesses in any of these areas within an application will decrease the value of the application. Given this critical postulate, I’ve been working lately to model the interdependence between server software, the interface, and the user experience. This is the resulting model:

The Anatomy of a Web Application - Jason Stonebraker, 2011

The Anatomy of a Web Application - Jason Stonebraker, 2011

Most of this diagram is a whole lotta duh. But what is notable to me is the positioning of User Experience. The User Experience doesn’t wrap the interface or the software, nor does it sit atop it. It intangibly exists between a user’s expectations and his/her actual interaction with the application. Given this, one can see that an application’s purpose should always model the user’s expectations. That is not a new notion, it is sadly, simply not always done.

What sits atop as the primary driver is the application’s purpose, meaning purpose is the third element of a web application. It carries significant weight, and is as much a part of an application as the interface and the software. I don’t know about you, but that’s super interesting to me.

In any case, I’m very happy with this diagram at the moment. I believe it accurately models the interdependence of the three core disciplines, and may serve as a tool for better uniting them.


Measuring the Value of Web Applications

To view the framework visit:
5 Facets of Valuable Web Applications

Introduction to the Five Facets Framework

The term “valuable application” is used often, but seems to have little practical or consistent meaning. In an attempt to define what it means to produce a valuable web application, I propose a framework for qualitative measurement meant to facilitate communication and decision making among production teams, sustainment teams, and product owners in terms of a web application’s immediate and long-term value to the business and the application’s users.

When it comes to measuring value, organizations will sometimes base their determinations on arbitrary, incomplete, or inconsequential factors. They might measure the success of a project’s execution by comparing estimated versus actual costs, or decide that an application is complete when it satisfies its requirements, at which point, the application’s value is assumed. Both of these techniques serve a purpose, but neither of these account for an application’s ability to sustain its value, or even increase in value, after it is released.

This framework seeks to measure the less conspicuous, but more determinant factors of a web application’s value: its purpose, architecture, and implementation. The framework’s key principle is Continuous Improvement in support of Iterative Design.

The definition of a valuable web application will likely differ from one organization to another. Some may find the details of this framework suit them perfectly as-is, while others may find it necessary to make modifications. The important thing is that the discussion occurs, and measurable goals are agreed upon. My hope is that this framework will help facilitate those discussions in some way.

5 Facets of Valuable Web Applications


The Role of Language

The Role of Language

Language frames and informs the way we think and interact with one another. I believe the web industry is currently suffering from the unabated use of terms that don’t accurately frame and inform the creative, continuous act of web production.

Some of the terms I’ll suggest might resonate with you while others might seem utterly ridiculous, at least at first. Even if you choose to not use these terms outwardly, I invite you to think in these terms inwardly as you move through the process of producing, gifting, and offering. I believe you will find that these terms better represent the activities of web production, and provide a touch of humanity and continued accountability to an often impersonal business.

More importantly, I believe you will find that by simply making small adjustments to the language you use, even if only in your personal, internal speech, your perception of your role and the roles of those you work with will change, you will produce better work, and enjoy your work more as a result.

Suggested Terms

Click on each term for the reasoning behind the suggestion.

  • Produce – Consider using Produce in place of Design, Develop, or Build.
  • Gift – Consider using Gift in place of Deliver.
  • Offer – Consider using Offer in place of Release or Launch.

Suggested Term: Produce


Consider using Produce in place of Design, Develop, or Build.

When referring to the activity of an entire team, I use the term produce in place of verbs such as design, develop, or build. I do this for three reasons.

  1. Given that web production teams consist of project leaders, business representatives, users, designers, and developers, it makes sense to refer to the combined, collaborative activities of the team as production. Designers design. Developers develop. The “whole team” produces a web application.
  2. In his book, Extreme Programming Explained, Kent Beck places importance on iterative design recommending that teams “perform all of the activities of web [production] at the same time.” The term design and development implies phased thinking, and limits the activities of web application production to those two activities. Knowledge gathering, prioritizing, and planning are a few other activities that must continually occur throughout a web project. The term production makes no assumptions about the activities taking place, and allows for any activity to occur at any time and in any order when producing an application.
  3. The terms develop and build tend to carry the connotation that the web application being produced will reach a state of completeness. In my opinion, the notion that a web application will ever take on a final form is the most problematic misconception of web application production. There is no such thing as a state of completeness for most web applications. A web application will have varying degrees of value, and it will either be available or unavailable for use, but it will always be subject to change and improvement. This is true regardless of who is responsible for making those changes.

Suggested Term: Offer


Consider using Offer in place of Release or Launch.

The terms release and launch are used by production teams to mark the milestone of making a web application, or a feature enhancement to a web application, available to the application’s users. These terms grate me too. They too connote a sense of finality, and the milestone is often celebrated as the end of production activity for a given web application. This is great news and a great accomplishment for the team, but it is merely the beginning of life for the web application itself. An application has no value until it is made available for use, and it is only then that its value can be truly measured. From the user’s perspective, the web application is brand new. The user, and the business for that matter, will not be as convinced of its value as the production team will have been during its happy hour celebration. From an outward-in perspective, the production team has offered an application that may or may not be accepted by the users and the business. By all means, celebrate the milestone, but bear in mind that just like child birth, the work has only just begun. No I don’t recommend using the word birth in place of offer. I don’t want to have to wake up to hop on a 5am “birth call.” Gross.

Suggested Term: Gift


Consider using Gift in place of Deliver.

I’m not a fan of the verb deliver or the noun deliverable in the context of web application production. When I think of delivery, I think of the UPS guy leaving a non-descript brown package at my door, and walking away taking no responsibility for the quality or fitness of the product inside. In searching for a better term, I arrived at the word gift. Granted, using the term gift in place of deliver in a business environment is a bit of a stretch. However, for the giver, the term gift carries with it a sense of accountability and the anticipation of welcoming enthusiasm from the recipient. If I am on a production team that will be handing off a web application to an altogether different sustainment team, I am likely to do better work if I think in terms of gifting the application I’ve helped to produce as opposed to delivering it and bailing undetected. Also, like the terms develop and build, deliver connotes the problematic misconception of finality.

5 Facets of Valuable Web Applications

For an introduction to the framework read:
Measuring the Value of Web Applications

The Five Facets Framework

The framework consists of four parts

  1. A definition of a “valuable web application”.
  2. A snowflake diagram that specifies the facets of a valuable web application.
  3. A series of statements for each facet that help determine the degree to which each facet has been satisfied.
  4. The “Harvey Ball” system of qualitative measurement which provides five states of completeness to be applied per statement.

Defining Value

A valuable web application concisely serves its business purpose, assuredly functions as expected, and can be straightforwardly and continuously improved.

The Snowflake Diagram

5 Facets of Valuable Web Applications - Jason Stonebraker

5 Facets of Valuable Web Applications - Jason Stonebraker

Qualitative Measurement

Harvey Balls

Harvey Balls used for qualitative measurement of each statement below.


  • The application’s business purpose is clearly defined.
  • The business domain is clearly defined.
  • The functional requirements are clearly defined.
  • The application owner has affirmed that the application serves its business purpose.
  • The application increases the value of the large scale structure.


  • A domain dictionary exists to ensure a ubiquitous language based on the language of the business.
  • The model serves, and is confined to its business purpose.
  • The model accurately reflects the current understanding of the business domain.
  • The ubiquitous language is used in all relevant aspects of the code.
  • Data storage is structured to mimic the domain model.


  • The objects, fields, variables, etc. of the system are explicitly named according to their purposes.
  • The behaviors of the system are reduced to their lowest common denominator.
  • The code concisely serves its functional purpose.
  • The code is well abstracted to avoid duplicate functionality.
  • There is a clear separation of business and technical concerns.


  • The code is well commented, and those comments clearly describe the code’s purpose.
  • The code is well documented and provides insight to developers who are unfamiliar with its purpose.
  • The code functions as expected.
  • The application builds efficiently and successfully.
  • The components are plainly and usefully organized.


  • Functioning unit tests exist for every test-worthy aspect of the code.
  • The tests are well named according to their purposes.
  • The tests are well commented, and those comments clearly describe their purposes.
  • The tests are plainly and usefully organized.
  • The tests run efficiently and successfully.

How it Works

  1. Using the statements provided, or those that work best for your organization, apply a Harvey Ball to each.
  2. An empty Harvey Ball indicates that the statement was not at all satisfied by the web application produced, while a full Harvey Ball indicates that the statement was completely satisfied.
  3. If any Harvey Ball other than a full ball is applied to any statement, a reason must be provided as feedback to the production team so the team can improve upon that facet by fully satisfying the statement.
  4. Once Harvey Balls have been assigned to each statement for each facet, the satisfaction of each facet is calculated by averaging the responses for each statement. A simple way to do this is to give each Harvey Ball a numeric value; e.g., an empty ball equals 0, a quarter ball equals 1, and so forth to 4. The average can then be taken of each response for each statement for a given facet, and the result will determine the completeness of that facet. This result is converted to a Harvey Ball and is applied to the facet. This is done for each facet.
  5. Now that each facet has been measured, the overall value of the web application’s architecture and implementation can be determined by averaging the results for each of the five facets. The resulting Harvey Ball is applied to the core Value giving the overall value of the web application as represented by a single Harvey Ball.


This is an example of a snowflake diagram after the completeness of each facet has been measured. The five facets were then averaged and the result was applied to indicate the overall value of the web application’s architecture and implementation.

  • The Harvey Ball found under the word Valuable is the final gauge of the web application’s value.
  • The Harvey Balls applied to each of the 5 facets indicate the degree to which improvements must be made to each facet to increase the overall value of the web application.

When a production team is passing off an application to a sustainment team, this framework provides a great instrument for productive, future-focused discussion between the production team, the sustainment team, and the financial decision makers. Financial decision makers can now make informed decisions with regard for the anticipated shelf life of the web application.

Snowflake diagram with Harvey Balls for qualitative measurement.

Snowflake diagram with Harvey Balls applied for qualitative measurement.


An application’s business purpose is highly likely to change over time. This is the primary reason for making Continuous Improvement the guiding principle behind producing web applications. The goal is to simply scale up the activity of iterative design and apply it to the application over its entire lifespan. In this way, a web application should exist for as long as there is a business need for it, and further it should appreciate in value over time rather than depreciate as most web applications do.

This is a framework for measuring the value of a web application’s architecture and implementation. Much of it assumes an adoption of Eric Evans’ Domain-Driven Design for its business focus in software architecture, and Kent Beck’s Extreme Programming for the importance it places on iterative design and test-first development.

The Snowflake diagram was inspired by Peter Morville’s User Experience Honeycomb. The Snowflake measures an application’s value to the business, while the UX Honeycomb measures the applications value to the user. The best application’s are valuable in both regards. The user experience is tantamount however, and for measuring its value I continue to use Morville’s User Experience Honeycomb just as I have for the past five or more years.

In my experience, a web application’s value is primarily determined by its interface architecture, its software architecture, and the flexible and testable implementation of both. Poor interface architecture or poor software architecture will always result in a less valuable application. Inflexible implementation will result in an application that begins to depreciate in value the moment it is launched. Given that this framework is meant to measure the business value of a web application’s architecture and its implementation, I suspect that the same five facets can be applied to both the interface and the server-side software equally well, though that is guesswork on my part. In any case, measuring both will ensure that the application is capable of delivering a valuable user experience.

Measuring value can assist in technology selection. It’s a simple matter of knowing your goals and making decisions that support those goals. Many of my blog posts concern an older version of Microsoft’s Entity Framework ORM solution. That particular version of the ORM did not in any way support a separation of concerns. However, the latest version of the Entity Framework does. Knowing this, it is easy for me to decide that I will not use the older ORM solution since it would prevent me from producing a 100% valuable application. The same rings true for ASP.Net Web Forms; they can be ruled out outright. Whereas the ASP MVC framework suits the bill perfectly, as would many frameworks available for php, Java, Python, Ruby, etc. upon which ASP MVC is based.

Some facets may be deemed more important than others; for instance, if an application completely fails to meet its business purpose, then the degree to which it can be improved is meaningless excepting that at least the application can be improved. Most businesses would prefer that the application serve its business purpose first and foremost, and that its testability, for example, is of less concern to them. Of course, an application that cannot have its quality assured is unlikely to sustain its value in the long term, adapt to later changes in its business purpose, or even increase in value over time as more is learned about the business domain. In any case, your organization may choose to weight the grades of the responses per facet. I tend to think that all facets should have equal weight when measuring value, because the goal is to apply full Harvey Balls to all five facets with Purposefulness being the driving facet.