Reference Models, Reference Architectures, and Reference Implementations

"All models are wrong, but some are useful." -- George Box

I often see confusion over reference models, reference architectures, and reference implementations.  In this post, I’ll share my experience and learnings and observations:

• Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes.  It’s like holding up a diamond and looking at the different facets.  It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives.  They are also useful for pulling together a bird’s-eye view of a domain or problem space.  A well-known example is the OSI model.  Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context.  By using a model, you can focus on higher-level concepts, ideas, and decisions.
• Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain.  It’s the high-level “blue prints” for putting the pieces of the puzzle together.
• Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation.  This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

I think the confusion is usually because the argument usually hinges on whether a reference architecture or reference implementation needs to be in code, when that’s really just a form factor decision.  The distinction is actually the focus and concern, independent of how you share it, although code can help illuminate a reference implementation and a reference architecture.  The other confusion is often around how big or small it needs to be to determine whether it’s a reference architecture or reference implementation, but that’ also a herring.  Again, it goes back to what the focus of the example is.  If it’s an exemplar of the architecture, it’s a reference architecture.  If it’s an exemplar of the implementation, then it’s a reference implementation, and each serve different purposes, and require different levels of detail or abstraction.

Reference Model Examples
Reference models give us a quick way to see and talk about a given problem space.  Here is an example of a simple reference model that does nothing more than frame out some cornerstone concepts for cloud computing.  In this case, it’s a visual model for cloud computing:

This is another of my favorite reference models.  In this case, this is a continuum of moving up the stack with types of cloud services from IaaS to PaaS to SaaS :

I also like a few of the cloud reference models, especially how they can be used for overlaying security concerns.

Reference Architecture ExamplesThe beauty of the reference architecture is that you can shape the application before you implement it.  One of the simplest ways to achieve this is to whiteboard it.  When you put it on the whiteboard, you can focus on key engineering decisions and avoid getting lost in the details.  You can focus on a conceptual, physical, or logical view, … you can focus on the business perspective, user perspective, or technical perspective … and you can move up and down the stack to zoom in or zoom out … but the main point is to show how the bits and pieces should fit together.  The power of a reference architecture is that it creates a shared mental model for the architecture and design and it can help you identify the key decisions and key risks early on.  This helps you both shape a skeleton solution as well as identify what you need to prototype, especially in terms of cross-cutting concerns, or tracer-bullets.  From an agile perspective, the Reference Architecture complements the system metaphor and it helps you identify potential areas to spike on.  Here are a few examples …

One of my favorite reference architecture examples is the reference architecture from the ESB Toolkit.

Another of my favorite reference architectures is the reference architecture for the PetShop Sample Application:

One approach I like to use for sharing reference architectures is what I call Application Scenarios or Scenarios and Solutions.  It’s a whiteboard sketch of the end-to-end solution.  Here is an example:

Another of my favorite approaches is to use what I refer to as Application Patterns.  It’s like the Application Scenarios, but I overlay patterns on top.  Here is an example:

The real key of reference architectures is that they help you explore the thinking and design at a higher-level before getting lost in the weeds.  Getting lost in the weeds is a common problem with reference implementations.  That’s why it’s helpful when they include a reference to their corresponding reference architecture.

The best combinations I find for nailing a problem space include a reference model + reference architecture + reference implementation.