A reference architecture provides a blueprint for advancing your business or technology strategy. But it can take a variety of forms, depending on your needs and your audience.
Put a dozen technologists in a room and ask them to define a reference architecture, and you'll likely end up with a dozen disparate definitions. Some might consider reference architectures to be detailed technical diagrams that show a representative implementation of a particular technology, down to hardware specifications and technical interfaces. For others, a reference architecture shows conceptual or functional building blocks that might solve a business problem, independent of the underlying technology.
Agree to agree
While debating the various definitions of reference architectures might make for an interesting conversation over cocktails, any definition is correct as long as it's clear what the reference architecture is meant to accomplish within your organization and serves the task at hand. If you've selected a vendor product and are ready to integrate it into your IT environment, a deeply technical reference architecture provided by the vendor makes perfect sense and can save weeks of implementation time. On the other hand, if your company is considering a strategic shift that involves a major change in the way business is done, a reference architecture that represents a different business functionality and how it relates is appropriate.
Just because a vendor or research organization defines a reference architecture in a certain manner doesn't mean you have to follow its convention. Rather than sticking to some organization's "official" definition of a reference architecture, determine what questions the architecture is meant to answer and who the audience will be for the architecture. Once you've agreed on these key points, socialize and share examples of how the architecture you're developing will solve some organizational problem or help resolve a business challenge.
Less is more
In addition to endlessly debating the definition and purpose of a reference architecture, there's the risk of treating the reference architecture as a monolithic, static diagram that shows anything and everything that will one day be in place. Some of the most effective reference architectures I've seen are not single diagrams at all, but multilevel diagrams that distill a complex IT environment into a high-level representation that's broken down into more detailed levels. Similarly, presenting a series of diagrams that depict how the architecture evolves over time can be a highly effective way to convey when different functionality will be deployed and to present different scenarios for how implementation might proceed.
In most cases, one of the key purposes of a reference architecture is to answer the question of what resources and timeframe will be required to implement a major enterprise project. Using a series of architectures that show not only functionality, but an evolution of that functionality, makes a compelling and readily understandable story.
Understand the audience and objective
With a story in mind for your reference architecture, and a realization that it need not be a single, massive diagram, consider its primary audience. Two reference architectures for the same technology could be vastly different depending on the audience. If you're attempting to convince the CEO that a major enterprise project is viable, detailing strategic capabilities and their interrelationships will be far more effective than a technically nuanced depiction of a complex interface. While this can be difficult for technically minded staff to grasp, consider what questions your audience is likely to ask, and what decisions or input you'd like from them, and let that guide the level of detail present in your reference architecture.
The most effective reference architecture is often a series of diagrams, each depicting a related aspect of a business problem at a given moment. Your reference architecture might be several diagrams at various levels of detail or it might be a series of diagrams with nary a mention of servers, networks, or applications. As long as the diagram helps advance your business or technology strategy, it has met its ultimate objective.