What is Reference Architecture?

A previous post discussed how no two organizations seem to define the role of the architect the same way. It just occurred to me that the same thing holds true for another common deliverable of the enterprise architect: the reference architecture. I’ve had the opportunity to work on a few reference architectures with a few different companies and I can certainly say that no two were the same, although there was certainly commonality between them.

There are at least two questions that have come up in multiple efforts. The first is whether or not a reference architecture should recommend specific technologies (e.g. “if you meet these conditions, you should use vendor product MagicFooBar”) or only describe the capabilities required, leaving implementations teams to choose a technology that fits (e.g. “the services tier must be exposed using XML-based interfaces”). The second question is one of depth. How much guidance should a reference architecture give? Should it go so far as to place constraints on how individual classes are named, or how the file hierarchy is set up in the source code repository? Or should it remain at a level somewhere above the design of individual classes? It may seem simple at first glance, but I can speak from experience that once you start providing some guidance, it’s very easy to get pulled into the depths.

What’s the right answer to these questions? I don’t think there is one. Why? Because reference architecture is about guidance, and the guidance needed in any one particular organization is going to be dependent on the skills of the staff, the organizational structure, the technologies involved, the problems being solved, etc. So what do you do? In my opinion, a good course of action is to focus on delivering guidance that is singular in purpose, at least within a single deliverable. What does this mean? It means that you should avoid trying to answer all of the questions within a single (and likely very large) document. Rather, each deliverable should start with one simple question, and focus on answering that question clearly. For example, rather than having one big reference architecture that attempts to cover all possible business solutions which could easily include web UIs, desktop UIs, mobile UIs, workflows, services, automated processes, applications portals, content portals, collaboration portals, and much more, consider having a separate document for each one, forming essentially a hierarchy of documents. The earlier documents discusses things more broadly, intending to answer the question of what collection of technologies are needed for a solution, but not necessarily guidance on the appropriate way to use that technology. For that, once the decision to use a particular technology has been made, a separate document goes into added depth, and the process continues. The reference material will eventually work its way down to development and operational guidelines (or hook up with those that may already exist).

Of course, all of this is easier said than done. It’s not easy to determine the “right” hierarchy up front. Again, the litmus test to apply is whether the document has clarity and singularity in purpose. If you find yourself with a document that starts getting onerous to use, consider breaking it apart.

What are others thoughts on this? As always, this is simply my opinion (after all, this is my blog, so that’s what you’re going to get), but I also am always interested in the thoughts of others and striving for a more collective wisdom. What has been successful for you when trying to provide reference guidance to teams? What hasn’t been successful? Use comments or trackback.

Update: I was just checking my feeds and there were two others blogs that discussed reference architectures: this one from George Ambler and this one from Simon Brown. Enjoy.

4 Responses to “What is Reference Architecture?”

  • […] whether or not a reference architecture should recommend specific technologies (e.g. ???if you …http://www.biske.com/blog/?p=354Third-party Developers Can Integrate Applications Directly Into … – SYS-CON MediaBy Engin Sezici […]

  • Michael Klose:

    Very interesting post.

    We have approximately the same dilemma – shall we employ one or only a little reference architectures or one for each problem (web, mobile, BI, collaboration, search, external access(extranet) etc.) or even one step more in detail, one reference for one special constellation like “external collaboration” … ???

    We plan to work with so called target architectures, too. These kind of models are between reference and solution ones. What about the discrete relationships (1:m or n:m) between reference, target and solution architectures ?

    Waht do you think ? Thanx.

  • Mike Quinlan:

    This is another question like what methodology is the best and which one should be used. Sometimes it’s a combination of techniques across methodologies that when applied judiciously to the family of problems to be solved results in the best outcomes. Why?! Because we haven’t allowed ourselves to be constrained in our problem solving process. I think the RA is the same. It’s a balancing act where sometimes too much depth or breadth is bad where other times it’s good. It is a judgement call that will always be second guessed. These things are our tools and should be sharpened and applied just enough. That application of judgement to each situation is what makes our profession challenging and impossible to replace with a software package.

  • I am about to do a reference architecture for integrating 2 commercial products through Web Services.

    My understanding is that the the reference architecture should provide abstractions to solve the problem, but use an adapting pattern to bring in the current technical choices.

    E.G. ‘Abstract Layer’ might be shown as ‘Persistence Subsystem’, extended by Hibernate, .NET Entity Framework, etc.

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.