Explaining principles, and making them work

Over the last few years, many different definitions of the concept of enterprise architecture have been proposed. However, rather than focusing on definitions, the focus should be on what we can achieve by adopting architecture methods. Once we know the goals of architecture initiatives, communication/ documentation as well as the process aspects follow naturally (see e.g. this pervious blogpost).

One of the key concepts in the enterprise architecture discipline is that of a principle. Different interpretations of this concept, naturally, exist in practice. For example:

• A principle signifies a point, or points, that allows for the formation of a norm or rule that guides the development of ethics by which you operate (IBM, 2007)
• A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance (TOFAF9)

Even more, in the book “enterprise architecture – creating value by informed governance” it is proposed to distinguish between:

• Principles as inherent laws – referring to properties of a system that can be observed and validated
• Principles as imposed laws – referring to properties of a system that can be validated
• Guidelines – referring to properties of a system that are specific enough to provide guidance to operational behavior to make it fit within the borders set out by imposed laws.

Indeed, the field of enterprise architecture is mostly concerned with the latter two. Obtaining agreement on what exactly entails a principle, or attempting to explain the concept to newcomers to the field can be quite challenging. Recently I found a way to explain the concept by using an analogy from the field of (classical) music.

Consider the situation where a composer wishes to compose a symphony. Even though the “rules” for writing a symphony are rather loose, there are certain “principals” that have to be followed none the less (as a side note: it is interesting to note that the word symphony derives from Greek, meaning ‘agreement or concord of sound’). Beethoven’s 5th symphony clearly falls in the category of symphonies. As such, one can argue that Beethoven followed the principles rather neatly when composing this work. However, Shostakovich’ 13th symphony is a whole different story as it consists of a number of songs. Therefore, one can argue that Shostakovich bended (or even broke) the rules somewhat.

Back to Beethoven’s 5th symphony. It can be argued that the actual score of this piece – i.e., the result of the composing process – is its “design”, whereas an actual performance is its implementation. The design is strict: every note by every instrument is clearly mapped out. The composer also has the opportunity to add clues as to how the piece should be performed: tempo, speed, punctuation etc.

These clues can be seen as principles indeed for the conductor when a performance is rehearsed and executed. Again, the conductor has certain liberties with respect to the performance as be seen by comparing these two performances of Beethoven’s 5th:

In short: similar to the concept of (enterprise) architecture, the definition of what constitutes a principle is not very interesting in practice. Of more value is a discussion of what one wants to achieve using principles. Sticking to TOGAF’s “qualitative statement of intent” seems good enough indeed.

This leaves the question on how principles should be formulated in practice. This is a topic for yet another blog post (soon to follow). However, as can be seen in the simple example of classical music: more restrictive principles lead to more predictable results … provided one chooses to follow the principles!