Science is the only way we have of shoving truth down the reluctant throat

All of these people may have wonderful insights, ask the questions that need to be asked, put forth challenging hypotheses, and may even be correct and true much of the time. But however sure they may be, they can never make mankind sure. They can convince only those who already agree with them, and a few more. Science is the only way we have of shoving truth down the reluctant throat. Only science can overcome characterological differences in seeing and believing. Only science can progress.

-- Abraham Maslow, Toward a Psychology of Being

Centralised monitoring cannot achieve the highest level of availability

Using central monitoring for problems fundamentally includes a delay in detection and therefore cannot be used to achieve the highest level of availability. For that you need distributed inline failure management. Central monitoring is still needed to cover systems that have no capable upstream component and also for aggregating information, especially for systems that are degrading but not yet incapacitated.

This is all very much in line with Lean or Six Sigma concepts of defect detection.

Level 0, Mistake-proof the design, that is reduce the likelihood of failure (or eliminate failure classes) by design
Level 1, Handle failures in-line
Level 2, Use a centralised monitoring system
Level 3, Wait for customers to complain

If availability is the first rule of enterprise architecture, then an architectural design that makes in-line failure management difficult should be by default considered bad.

This holds also with social systems. Handling problems with centralised departments and teams is fundamentally slower than setting up socio-technical systems to handle problems in-line, which is itself not as preferred as mistake-proofing.

How to build people before you build software

I've been reflecting a lot lately about why things are the way they are and how they might change.

Toyota has a concept of building people and then building cars which I think is the key insight.

Take a look at Peter Abilla's recent blog about focusing on people, not just tools:

What most folks forget is that ‘Kaizen’ was truly built upon the philosophy that “Toyota builds people and then cars” — that is, Kaizen came from the notion that the collective intelligence of your line workers is valuable and that people, if given the training and the chance, can truly do amazing things. This is an example where the Technical came from Philosophy — the tools and methods used in Kaizen are supported and even stems from the Philosophy of ‘Respect for People’.

Does zebra striping tables actually help?

A nice experiment described at A List Apart on whether or not Zebra Striping tables improves task performance or user preference.

Conclusion: No statistically significant differences between a zebra striped table versus a plain table.

Don't shape the people to fit the roles...

Don't shape the people to fit the roles; shape the roles to fit the people

A key difference when you have the Lean mindset

When you think or hear "That's the way things are done here"...

When you have that sense that you're about to accept imperfection...

You interrupt with "Why?"... repeatedly until you understand the root cause... and then you address it.

If you're a good problem solver...

Solve the problem that's there not the one they tell you is there.

Simple rules for enterprise architecture?

Thinking about simple rules in order of priority...

1. Available - Availability is more important than anything else. Do not introduce things that reduce the overall reliability of the enterprise. This should lead to things like decentralised graceful degradation.
2. Easily verified - How are you going to test it? How are you going to test it when it's running (aka monitoring)?
3. Single Source of Information - Don't present contradicting data to customers.
4. Easy to Describe - The enterprise architecture should reflect the enterprise's structure. See Conway's Law. This works both ways. Change the architecture or change the organisation.
5. Least Number of Systems - Less stuff to deal with, monitor, and fail.

See also Design Beyond Human Abilities.