The importance of why

If you have kids or know small kids then you’ll know that kids go through a phase (I hope) where the most important word of their vocabulary is ‘why?’. Asking the same question can be a very important technique to uncover the best architecture. But let me just stress that that does not in any way imply that you should treat your stakeholders as kids! You’ll not last long….

John Zachman is famous for his Zachman Framework, although it is an ontology according to himself. The framework is build on the primitive interrogatives: What, How, When, Who, Where, and Why. Rather than just ask ‘why?’ (like a child), then think of ‘why’ as a reflective word, e.g., reflective interrogatives might look this:

  • What (Inventory: entity and relationships): Why did we choose / have these business / systems / technology entities, and why do we think they are related? The aim is to reflect on what we have and whether we truly understanding their role, and how they work as part of the ‘bigger’ picture.
  • How (Process: Input and transform): Why are we doing what we are doing, why do we want to do it in some other way?
  • When (Timing: cycle and moment): Why might or would our business, system etc cycles and moments (events?) be important?
  • Where (Network: location and connections): Why do we have or why did we choose our business or system locations? Why are they connected in the way they are?
  • Why (Motivation: End and means): Why do we choose our goals? And why was the allocated means deemed correct or sufficient?

‘Why’ doesn’t uncover all important aspects, but it can help in understanding the reasoning and rationale for why we are where we are. It helps bring together the context we, as architects, need to make better decisions while showing the right and relevant technical leadership. Leading people towards, e.g., Cloud Computing (picked pseudo-randomly), without fully understanding the ‘why’ can be costly.