Mockups Vs. Proof-of-Concept Prototypes

There are many types of prototypes. Some projects create UI prototypes. Others might proto-
type an architecture consideration. In fact, every project has different needs regarding a prototype.
However, for your purposes, these prototypes can be classified into two principal groups:
mockups and proof of concept.

A mockup is meant to verify the requirements and use cases through the creation of a number
of key screens in the system. Also called horizontal prototypes because they take
a single, horizontal picture of the application. They do not go deeply (or vertically) into the
other layers of the application such as the business objects and the database layers. Mockups
are a great way to determine whether the requirements are complete and understood. They
also help validate the use cases, the navigational structure, and some of the logical interactions
of the application.

Mockups do have shortcomings. They do not help you prove any of the architecture concepts
for the system. They also do not validate the technology decisions. Mockups are
great tool for moving from paper to something more tangible.

A proof-of-concept prototype(POC) is meant to validate the requirements and confirm the technology recommendations and high-level design. A POC is also called a vertical
prototype because it looks at the application across the entire stack (UI, services, business objects, and database). POC prototypes have also been called reference architectures,
because they provide a reference for the development team on just how the system
should work from top to bottom. This removes ambiguity, creates a standard, and eliminates
a lot of risk.
We create a POC prototype by choosing a key requirement of the application and
then building it out through each layer of the design. It makes more sense to prove out a riskier
requirement than to work with a well-known requirement. The latter might be easy, but it lacks
the risk reduction you are looking for with a proof of concept.