From Sedimented Principles to Enabling Prejudices

I have often asserted (on this blog and elsewhere) that principles are over-rated as a driver for intelligent action. However, that doesn't mean principles are completely worthless. In this post, I wish to explore some of the ways in which principles may have some limited use within enterprise architecture.

I am going to identify four rough categories of principle. There may be other categories, and the categories may overlap.

1. Universal Truths
2. Governance
3. Style Preferences
4. Enabling Prejudices

This is a long post, and I think the final category is the most interesting one, so if you are short of time, please read that one first.

---

Universal truths. This kind of principle is something one has to accept and believe, because the evidence in its support is overwhelming. For example, all computers of a given construction must obey certain logical principles, as rigorously proven by Gödel, Turing, Church, von Neumann, and others.

(There aren't many universal truths in the enterprise architecture domain, and the word "proven" is widely abused to mean "something that everyone believes" or "something that nobody has convincingly disproved" or "something that is vaguely associated with a bit of maths or science". I'm not impressed by "proofs" that haven't been published anywhere, are based on wishful thinking and received wisdom, or turn out to prove something fairly trivial.)


Governance. An enterprise or ecosystem may be regulated by governing principles, which are essentially high level rules or policies controlling the structure and behaviour, and constraining certain classes of decision. For example, an enterprise software architecture may be based on certain global principles about accessibility or security, which ultimately link to some specific outcome.

Some EA frameworks arrange principles, policies and rules into a pseudo-hierarchy, but the dividing line between principles and policies can be pretty arbitrary.

Governing principles may be reinforced by standards, but usually the principle is broader than simply conforming to the standard. For example, a principle of accessibility may reference various accessibility standards, but software designers may be expected to strive for enhanced accessibility beyond the minimum standards.


Style. An enterprise or ecosystem may have some stylistic preferences. For example, applications within the Apple ecosystem tend to have a predictable look and feel. In some areas, these stylistic preferences may be elevated to the status of principles.

Some people think that all systems within an enterprise or ecosystem should have a common look and feel. This is a bit like insisting that all the rooms in your house should be painted the same colour, from the kitchen to the bedrooms. Feng Shui practitioners preach the opposite idea; they say that a building should have different zones, with different "look and feel". They then have some complicated rules associating different colours with different compass points, which we don't need to go into here.

In some cases, there are strong reasons for making systems look and feel different. When a pilot is flying a plane, it's probably not a good idea for the flight controls to operate in the same way as the accounting system she uses on the ground for submitting her expenses. A system may even have a different look and feel according to context, thus a database operator may be presented with a different interface when working with the live database, forcing her to slow down and consider every action twice.

In other areas, differences between systems are annoying and may increase levels of error. On Apple computers, and inside some applications, command-D means Duplicate. On Windows, command-D means Delete. I'm sure I'm not the only one who gets these mixed up, and I am grateful that the Windows command at least has a Confirm/Cancel step. In some other systems, the Delete function wipes the file immediately, which is tough if you're used to a Confirm/Cancel/Restore. Other stylistic differences may make navigation harder. For example, regular users of Microsoft Office may detect some minor style differences between the different applications. Just because you've used a particular function in Word doesn't mean you can find it in Excel or Powerpoint. Perhaps it's there, but hidden under a different name in a different submenu. Of course, Microsoft has cleaned up many of these style differences over the years, but perhaps inevitably some remain.

Style often originates with arbitrary choices or one person's aesthetic preferences. Someone once thought it would be a good idea to have X for cut and V for paste, but it could equally have been two other letters. But nowadays users are so accustomed to X and V for cut and paste, that it would be perverse for a designer to use any other letters.

Overarching stylistic rules and guidelines may be presented as local principles, valid for a particular suite of applications. They represent a set of often originally arbitrary choices and preferences, which have been adopted by or imposed onto a community of designers.

I see a subtle difference between style principles and governance principles, and one clue is the nature of the argument that emerges when people don't want to follow them. Style arguments tend to be presented in aesthetic terms - the old design is old-fashioned, younger users want something cool, etc, etc. Governance arguments are presented in terms of outcomes - this would not produce the outcomes we want, or has some other side-effect.


Finally, I get to what is possibly the most controversial one.

Enabling Prejudices. One of the key insights of the early work on Design Thinking (Bryan Lawson, Peter Rowe) was the importance of heuristics, or what Rowe (following Gadamer) calls enabling prejudices, which will hopefully get us to a good-enough solution more quickly. 

As Christopher Alexander notes:

At the moment when a person is faced with an act of design, he does not have time to think about it from stratch. The Timeless Way of Building p 204

We always approach a problem with a set of prejudices or prejudgements. Depending on the situation, these may either help us to solve the problem more quickly (enabling), or may lead us astray (disabling). The acid test of a set of heuristics or design principles is that they are mostly enabling most of the time.

Perhaps one important difference between education and training is that good education encourages the students to think more deeply, whereas good training teaches students to solve problems more quickly. (Or reliably or effectively, or some other adverb.) Thus training initiates and indoctrinates the students into a set of enabling prejudices, which will give them greater practical power.

Inexperienced practitioners may rely heavily on the principles they were taught in training, or have learned from books. As practitioners gain experience, their prejudices may become more refined, more personalized, and more deeply embedded. A lot of the principles articulated for enterprise architecture reflect this kind of enabling prejudice.

Obviously there is nothing wrong with an enabling prejudice when it is correct. A basketball coach might have a reasonable expectation that tall people are generally better at basketball than short people. But in an ideal world, a good basketball coach would be open-minded enough to notice a shorter player who is exceptionally good. It would be doubly stupid to impose a minimum height rule, firstly because you might exclude a really good player, and secondly because you will never get any feedback to tell you to revise the rule.

Now here's the twist. Many enterprise architecture frameworks suggest that practitioners should agree a common set of principles. But here's a contrary thought. Maybe a healthy enterprise or ecosystem encourages diversity of prejudice. (The shorter guy only needs one basketball coach to spot his talent and potential.) If we all have different approaches to problem-solving, then we are collectively more likely to find good solutions to difficult problems, and more likely to spot possible pitfalls. The value of diversity applies both when we are collaborating and when we are competing. Whereas a community with a single (attenuated) set of enabling prejudices would lack resilience, forming a dangerous form of intellectual monoculture.


Some might complain that allowing heuristic variation introduces fragmentation, inconsistency and incoherence into the enterprise or ecosystem, but I think that's incorrect. As I see it, maintaining integrity and consistency is the job of the governance and style principles. The heuristics (enabling prejudices) perform an entirely different job, and I think it is wrong to try standardizing and enforcing them in the same way as the other principles.

---

Christopher Alexander, The Timeless Way of Building (New York: Oxford University Press, 1979)

Dan Klyn, Skirmishing With Ill-Defined and Wicked Problems (TUG, 5 July 2013) - review of Rowe

Bryan Lawson, How Designers Think (1980, 4th edition 2005)

Peter Rowe, Design Thinking (MIT Press 1987)

Stanford Encyclopedia of Philosophy: Gadamer and the Positivity of Prejudice


Related posts: What's wrong with principles (Feb 2010), What's wrong with principles 2 (July 2010), The Power of Principles - Not (Jan 2011),  From Enabling Prejudices to Sedimented Principles (March 2013)

Updated 11 November 2018