De-Fuzzing Reference Architecture

Those of us tasked with working on higher-level topics, such as Enterprise Architecture and Strategy, dread when asked the simple question — “what do you do?” When deliverables lack tangibility and clarity, responses to this question leave the questioner dazed and almost sorry for the respondent. A common term tossed into the response, as a placeholder for uncertainty and incompleteness, is reference architecture.

This term can mean many things or anything to different people. If left undefined, it gives the impression of fluffiness and fuzziness that breeds frustration and waste. Those tasked with implementation may question your ability to ground concepts and thinking into reality and concreteness. Hence, definitions are useful. Here is my definition of a reference architecture:

The articulation of considerations, options and known standards to guide the design of a product, solution or system, based on observations from surveys, experience and experimentation, in a language and visual format familiar to the target audience. [my definition of a reference architecture]

The truth is, once the intent, value and context of usage are made clear for a given audience, having a formal definition does not matter.

The real question is —

“what is it that we want to do?”


“what do we want people (whoever they are) to do?”

Having clear answers to these questions are the start to de-fuzzing the meaning and delivery of reference architecture. The intent, content, audience and value need to be clear. The word “reference” suggests the output provides guidance and standards from observation, experience and experimentation, as opposed to a definition of what is to be built. An “architecture” suggests it is structured, coherent and verifiable.

There are various definitions of reference architecture found on the Internet, but the above rule of clarity (intent, content, audience, value) can be found in each. Consider an alternative definition to mine that comes up as the top result in a google search:

(1) Clarify the medium and format of what is going to be delivered e.g. “a document”. This informs the tools required, the nature of work to be carried out and the skill-set of contributors to be involved. Alternative ways of delivery could be a presentation or query-able knowledge-base.

(2) Agree on the structure and scale of what is going to be delivered e.g. “a set of documents”. One deliverable might be insufficient, but the scale of the system domain under question might require the deliverable to be decomposed into several documents.

(3) Identify the primary audience and stakeholder(s) e.g. “project manager”. Have an understanding of the type and format of information they regularly consume. The status-quo might also play a role here. In some cases the reference architecture is “passed down” the reporting lines as policy, while in other cases it is treated as a “nice to have”, with the expectation that it describes the best way and alternatives to be considered.

(4) Identify other interested parties who might need to use the reference architecture. Is it necessary to create different views or layers? Is there need and space for training others on how to interpret and apply the reference architecture?

(5) Make it clear what the audience/ reader should do with the document e.g. “refer for best practices.” The outputs should deliver what they say on the cover, including the evidence and links to sources for validation. A reference architecture could also deliver “learning” from experimentation in a coherent, actionable manner.

(6) Make the domain of relevance clear. A reference architecture without a specific domain is a philosophy of higher-level guiding principles rather than an architecture. An architecture, even a reference architecture, needs to be domain bound. The smaller this domain, the more relevant and actionable the reference architecture.

(7) The intended value of the reference architecture should be communicated, as this helps the audience judge its purpose and limitations e.g. “select the best delivery method.” Implementation teams then know where to go when this decision needs to be made.

(8) Having examples from the domain and stating the relevant technologies, helps to clarify the context of the reference architecture.

(9) Alternatives and sources of components and capabilities to be considered, when implementing, should be well documented and linked.

A reference architecture is not necessarily a blocker before a technology project is started. It can be developed in parallel or after delivery, serving as the documentation of a postmortem and lessons learnt. If it is created before a project starts, then it requires surveys, trials and experiments in order to inform good practice. Below is a suggested taxonomy of possible classes of reference architecture, depending on the audience, solution and current gap in knowledge within an organisation or project team.

The acronym for the five different aspects of a reference architecture is MUSIC, which has proven to be memorable in conversations at any organisational level or domain of understanding:

  • [M]embership: the listing and categorisation of architecture elements considered relevant to the domain.
  • [U]sage: user stories, business cases, processes, workflows and means of explaining activities in the domain.
  • [S]tructure: how the various elements in a domain are interconnected to support usage.
  • [I]nteraction (or Integration): the interfaces and messages exchanged between architecture elements during usage.
  • [C]ontrols: the constraints and policies used to govern interactions.

Now this doesn’t suggest that all reference architectures need to deliver 25 documents or subsections, covering each of the areas identified. This illustrates there are likely 25 different areas where considerations, options and responsibilities need to be articulated in an organisation or project. This will change depending on your audience. There is no fuzziness or fluffiness in reference architectures. They are the result of exploratory effort and are the tangible outputs of near-term applied research.