Dimensions of (enterprise) architecture

One of the issues that keep popping up when discussing (enterprise) architecture is the question: what is it? Unfortunately it seems necessary to keep discussing / refining / extending definitions, not only when two architects converse, but also when starting a new architecture project in a firm. I've seen situations where it took several months to agree on a definition of EA in one department of an organization when we found out that other departments had an entirely different approach. This is pretty much regrettable. As Hans Bot puts it eloquently at the Weblog of Erik Proper:

It's amazing the debate is still going on … Why is it, that in IT, we tend to hijack a word from another industry, and give it an altogether different meaning? … The IEEE working group did a very good job in defining those terms back in 2000. Architecture is a property of a system reflecting its internal cohesion; its harmony with its surroundings and its design principles … If only IT people would accept (and practice) the difference between an architecture description, a view as part of the architecture description (either made during the design of the system or afterwards) and the architecture itself, much confusion and mystification would be prevented.

I couldn't agree more. In teaching EA, though, I've found that it makes sense to distinguish three dimensions of enterprise architecture to guide the course, the discussion of the subjects et cetera. In the course "Enterprise Archtiecture in Practice" I used the following slide to introduce these perspectives:

The first dimension deals with the question "What is enterprise architecture?". As Hans put it, architecture is a property of a system. In the case of EA, the system under consideration is an enterprise (thus assuming that architects have a systemic view of enterprises). Paraphfrasing the FRISCO report, it can be argued that since each architect has a unique perception of the enterprise under consideration, each architect sees the architect of this enterprise differently (in FRISCO terms, an architecture is a special model which exists in the mind of a human actor). Therefore, it is essential to communicate about architectures. This is also argued in e.g.  the Archimate approach. 

This brings us to the second dimension: documentation. This dimension deals with the question "How are architectures documented?". In my opinion, this is where most of the big architecture frameworks and architecture languages come on. Think IAF, Zachman, Archimate et cetera. It appears that there are two main aspects of architecture documentation. First of all, there is the style of architecture blueprints in the form of (semi) formal models. This is what most people expect from architects: walking around with A0 sized plots of e.g. the application landscape. The second style pertains to architecture principles (ignoring the distinction that is sometimes made between 'principles' and other types of regulations such as 'rules', 'guidlines' etcetera). Neither style is right or wrong, in my opinion. Both are equally valuable, depending on what one wants to achieve. For example, the blueperints tend to provide a lot of information and insights which may be used for decision making whereas principles may be used in Project Start Architectures to guide projects within the enterprise.

This brings us to the last dimension which pertains to the question: "What is an architecture used for?". This refers back to the comment by Hans Bot. In my experience, more and more organizations start working under architecture. This means that they use the EA way of thinking  for governing the enterprise with a strong focus on brining together the worlds of what traditionally is called 'business' and 'IT'. Probably the most succesful and widespread use of EA is the Project Start Architecture. 

Splitting up these dimensions and discussing them seperately has worked well in practice, at least in a teaching setting. As long as there is no widely agreed upon feel for what EA is, especially outside the architecture community, it may be necessary to continue to discuss these dimensions with each new architecture initiative. This is unfortunate, as it is more important to get the work done.