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


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.