Why Reference Architecture(s)? (Part 1)

Monday, October 12, 2009 |

A few weeks back, I posted a sample EA Capability Map. It generated a lot of discussion here, on Twitter and LinkedIn groups. Within these discussions, one of the insights from the map - Reference Architectures, specifically Business and Technology, are the business of Enterprise Architecture - was routinely challenged. These challenges came from many perspectives - the uber-pragmatist EA movement objected to investing into shelf-ware, the semantic pedants wondered what my definition of Reference Architecture was, the decision makers have never seen this expenditure justified by ROI, and so on. This was contentious enough to warrant a detailed treatment.


As I got into writing about the "why", I found a strange thing - the semantic pedants were more accurate than I gave them credit at the time - there is little to no agreement as to "what" a reference architecture is. While there are many perspectives on what a Reference Architecture provides, there is no "one" definition. So I'm scoping this post to just the "what", and leaving the "why" to Part 2. The intent is to get enough reactions and opinions to crowd-source a definition of Reference Architecture that can replace what is currently in Wikipedia (see below).

1. What is Reference Architecture

There are many definitions, which is part of the problem. The other part is that few actually define Reference Architecture. Here's a representative definition from Wikipedia:

A reference architecture provides a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.

A reference architecture often consists of a list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture.

Reference architectures can be defined at different levels of abstraction. A highly abstract one might show different pieces of equipment on a communications network, each providing different functions. A lower level one might demonstrate the interactions of procedures (or methods) within a computer program defined to perform a very specific task.

A reference architecture provides a template, based on the generalization of a set of successful solutions. These solutions have been generalized and structured for the depiction of both a logical and physical architecture based on the harvesting of a set of patterns that describe observations in a number of successful implements. Further it shows how to compose these parts together into a solution. Reference Architectures will be instantiated for a particular domain or for specific projects

Note, nowhere does the definition say what Reference Architecture is! There is plenty on what it provides, what are its building blocks, etc. No wonder Enterprise Architects can't agree on whether it is even needed.

So here is my definition:

A Reference Architecture is a set of predefined problem solutions for a given perspective.

To me, the implication is that while there may be Business Reference Architecture, a Technology Reference Architecture, a Risk Reference Architecture, an Organizational Reference Architecture, an ... Reference Architecture. But there isn't "one" Reference Architecture.

Your contributions are encouraged and welcomed!

Aleks


5 comments:

Matthew said...

These endless conversations about EA definitions are fun aren't they?

I like your definition because it does highlight the fact that you still have to ask 'a reference architecture for what?'

The only thing I'd say is that 'predefined problem solutions' isn't really right in my mind.

It's not that the problem solutions are predefined but rather it wouldn't be a solution if it didn't cover the components of the [solution] reference architecture.

So a reference architecture is a predefined structure for for a specific type of architecture to fit into.... maybe

Unknown said...

Matt -

Good point on predefined structure. It lends more credence to the idea that Information Technology has its own set of structures, semi-autonomous from lines of business - a business operating model of IT, if you will. Predefined problem solutions are nothing more than bricks and patterns. And while a lot of organizations invest into creation of these bricks and patterns, most miss a crucial link in the value chain: a process of describing problems in a consistent way that allows for new projects to properly reuse existing investments.

Regards,

AAB

p.s. My definition of fun may be slightly different, but then that is the point as well - everyone has a different perspective.

Paula Thornton said...

It all depends on what it's 'referring' to : )

Actually the real answer is fundamentally an architectural one -- something technologists are pretty bad at. Take a page from commercial construction. A series of architectural perspectives are brought together for a total package to define the structure, infastructure, environment, interior, exterior and landscaping of a building. Each of these major areas often require different specialties.

What we lack is a true guild of cross-architectural perspectives. Indeed, while Zachman was eventually persuaded to look at 6 different dimensions (the columns), his framework is a look at the 6 dimensions from a TECHICAL perspective. To be complete, Zachman's Framework would need to be repeated from the perspective of each of the columns in his existing framework...extending his 2D perspective to 3D.

Paula Thornton said...

I might contend that you've defined the artifacts OF a reference architecture, but not the architecture itself. The original did indeed focus on the true elements of a reference architecture: "a template, based on the generalization of a set of successful solutions"

A reference architecture is a heuristic, not an algorithm. You're defining the algorithm (see the diagram http://www.fastforwardblog.com/2009/09/16/e2-0-unleashing-the-potential/)

Including sample algorithms clearly helps define the potential and sharing such all together is indeed relevant, but the entire purpose of the heuristic is to extrapolate ACROSS the possible solutions.

The problem with reuse, as was recommended by another commenter is that almost every solution has to make a set of assumptions that rule out other assumptions relevant to other contexts. THAT is the entire justification for reference architectures -- that the reuse is not in the pieces but in the heuristics of the pieces.

dhestand said...

For my uses, a reference architecture represents an "exemplar" for a particular category of architectures. In other words, it combines the best practices and accepted approaches to making architectural decisions. Thus, it seems natural (at least to me) to think about different reference architectures for different uses, even within the same category. At the same time I believe that there exist multiple views or perspectives applicable to any particular reference architecture. These perspectives are useful for discussing the reference architectures within and between different groups. The perspectives also provide a backdrop for decision making around architectural strategies.