A reference architecture (RA) is a particular kind of reusable asset that is basically a “ready-rolled” architecture that has been used and proven in a number of other situations and can be applied (wholly or partly) to to solving different problems (though within a particular context). The question is, when does the  architecture of a system become one that can be reused elsewhere and therefore become a reference architecture? I have a colleague, Bruce Anderson, who was instrumental in the early pattern movement who once said to me that something can only be called a pattern if there are at least three known instances of it. One of the things that made the famous Design Patterns book so powerful and continues to make it so enduring is that it was based on rigorous research by the authors who trawled through several systems designs to look for common themes and harvest them into the catalogue of patterns that make up the book. Whilst a reference architecture could be considered a kind of pattern it has some differences that make it harder to find multiple instances that are already ‘out there’. Namely:

1. A reference architecture is, by definition, a large-grained asset typically made of  many subsystems which in turn are made up of interdependent components. There are many ways of assembling these components together, any one of which will usually do the job. It is unlikely therefore that exactly the same assembly of subsystems and components will exist in more than one architecture. Consider the architecture of an online retail store for example. There will be subsystems for allowing new customers to register and change there contact details, managing the ordering process and for managing the database of products that are for sale. However the internal components that make up these subsystems could be wired together in many different ways. Who is to say which is best?
2. Architectures at the system level are typically documented in a multitude of different ways. Some may use rigorous modelling languages such as SysML captured in a modelling tool whilst others use more informal documentation consisting of pictures and words captured using a word processor. This makes it difficult to compare like with like when trying to find “best of breed” which is, after all, what we are trying to do when harvesting architectural assets.
3. Large-grained assets consisting of complete architectures are likely to contain a considerable amount of intellectual property that give companies competitive advantage so they are unlikely to offer them up as potentials for becoming an industry reference. Some subsystems my be covered by patents (amazon’s one-click ordering for example) so are at least accessible but many will not be generally available for anyone to view.

These three factors (and there are probably more, feel free to comment) make it difficult to find similar architectures, compare them to see which is best and to harvest them as a reference for others to use which is the whole intent of the patterns movement. What to do?

1. Reference architectures can be built. With an enterprise, a bank for example, it should be possible to build a reference architecture bottom-up. By deploying architects with the right industry and technology skills components can be selected and assembled in an optimum way that makes most sense for that organisation. This can then be a reference for other parts of the organisation to use. For companies that provide consultancy across multiple clients this can be a very powerful way to achieve reuse across projects however it does require a significant up-front investment as well as ongoing maintenance to keep the architecture current.
2. Reference architectures should be described using a standard approach. It helps to document architectures using a standard set of work products. In the book The Process of Software Architecting we describe a set of work products that can be used for documenting a systems architecture (Architecture Overview, Functional Model, Deployment Model, Architecture Decisions etc). The point about using a standard set of work products to describe a reference architecture is that these can then form the basis of the documentation of the system that is to be built based on the reference system.
3. Reference architectures are made to be changed, not used as-is. Once a reference has been defined it will almost certainly be changed to a lesser or greater extent depending on its “fit-gap” to the requirements of the new system. It’s usually worthwhile to do a formal fit-gap analysis to determine this and to use the output as part of the documentation of the new system.
4. For reference architectures context is critical. This really follows from the previous item. Knowing the context (functional and non-functional requirements) is critical to the applicability of a reference architecture being reused. There is a danger it will be forced to fit when it makes no sense to do so. For example the new system has particularly stringent performance requirements that mean the way components are wired together in the reference architecture cannot be applied to the new system.

A reference architecture is associated with a particular domain of interest (retail banking, online commerce etc) and typically includes many different architectural patterns, applied in different areas of its structure. Since a reference architecture is an architecture, it is no surprise to find that the best  reference architectures are described in exactly the same manner as any other architecture using the same work products.