Asking good questions

Dr John BrøndumLeave a comment

My PhD supervisor told me (many moons ago): “Once you know the right question, then the answer is obvious”. Of course, the real trick is to find the right questions without limiting yourself to what you already know; or think you know. Pohlman & Thomas describes a simple matrix of four types of questions to help improve your understanding “Relearning the Art of Asking Questions“:

  1. Clarifying questions help us better understand what has been said.
  2. Adjoining questions are used to explore related aspects of the problem that are ignored in the conversation.
  3. Funneling questions are used to dive deeper.
  4. Elevating questions raise broader issues and highlight the bigger picture.

Under the usual cost and schedule pressures, progress and deliverables are easier to reach through clarifying questions, but we miss the bigger, more important questions.

As one of my clients once said: “If you request a consultant to tell you the time, then they’ll grab your wrist and look at your watch”. That’s a clarifying question, so you (as a good consultant) may then ask “why?” (funneling), “how does that help you?” (elevating), and “why didn’t you look yourself?” (adjoining).

Context

Dr John BrøndumLeave a comment

Context is what gives meaning to what we say and do. It forms the basis for all of our decisions. Or as Diana Montalion eloquently expressed it: “In The Lord of the Rings, Frodo’s journey to destroy the ring is meaningful inside the context of Middle Earth. Otherwise, he’s a short, hairy guy with apocalyptic hallucinations.”

Next time you discuss something, make sure you both agreed on the context – it is difficult to understand each other, if one of you are referring to a “Frodo” and the other a “short, hairy guy”

#enterprisearchitecture #life #andallthatisinbetween

Knowledge patterns

Dr John BrøndumLeave a comment

Below is my illustration of Ikujiro Nonaka’s four knowledge creation patterns in “The Knowledge-Creating Company“.

Mr Nonaka’s four knowledge patterns are insightful and illustrate nicely the interplay between tacit knowledge and explicit knowledge. The article is well worth reading, but here’s the quick summary:

  1. Tacit to tacit knowledge (observe): One person through observation, imitation, and practice gains the skills of another person, e.g., presentation skills
  2. Tacit to explicit knowledge (articulate): One person articulates her tacit knowledge through verbal and/or written form. This allows others to gain knowledge through listening or reading, but it also aids the communicator to gain greater awareness of their own knowledge. Examples include software design documentation or mentoring discussions.
  3. Explicit to explicit knowledge (organise): The act of organising explicit knowledge to allow others to find and combine the available knowledge records, e.g., folder structures, libraries, or knowledge management systems
  4. Explicit to tacit knowledge (apply): The act of taking explicit knowledge and internalising it as tacit knowledge, e.g., software engineer read the design documentation and attempts to enhance the software.

Note how the four patterns are applicable to themselves, as there is both tacit and explicit knowledge required for you to be able to perform the above patterns

Conway’s Law and Organisational Restructures

Dr John BrøndumLeave a comment

Fred Brooks’ “The Mythical Man-month” cited Conway’s seminal paper on the relationship between software and organisational structures. Conway phrased the relationship as:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

https://www.melconway.com/Home/Conways_Law.html

In other words, software solidifies organisational processes and structures.

So what happens when you re-structure an organisation? And add more software. And re-structure again? The overall software system (of systems) will now reflect the new and the old organisational structures. Sounds messy.

Obviously, it is necessary for organisations to re-structure, but I am wondering how often an organisational re-structure activity includes consideration and impact assessment of the relevant technology systems?

 

Ghost structures

Dr John BrøndumLeave a comment

Cities around the world are filled with streets that are no longer streets. It isn’t too hard to spot the diagonal, no-longer-street “street” in the above photo because of its clear impact to the surrounding buildings.

You can see more in Geoff Manaugh’s blog post about “ghost streets” (Bldgblog).

If you zoom in then you see that the diagonal “street” isn’t actually a street, but building shapes, property lines or other forms of outdoor areas (like a car park).

These ghost streets – or ghost structures – are also a good metaphor for something you’ll find in software systems. Previous design decisions aren’t always re-assessed – too many to re-assess all of them – and especially if you are replacing an existing system, then it becomes very difficult to re-design the new system, because it must by necessity integrate with all the other systems (and it is a lot of work to re-work all of those).

The net result is that your new system with the new architecture and design is not as new as you think.