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
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. An airline doesn't want the systems used by its pilots to resemble the systems used by its accountants. 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. It is not practical to solve every problem from scratch. 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.
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 guy who is exceptionally good. It would be doubly stupid to impose a minimum height rule, firstly because you might exclude the best 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 short 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 this 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 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.
See also From Enabling Prejudices to Sedimented Principles (March 2013)
Bryan Lawson, How Designers Think (1980, 4th edition 2005)
Peter Rowe, Design Thinking (MIT Press 1987)
Updated 23 November 2013