4th Edition of ‘Software Architecture in Practice’ has been released

The 4th edition of the seminal book ‘Software Architecture in Practice’ has been released. You can get your copy here: https://www.informit.com/store/software-architecture-in-practice-9780136886099

The book’s focus is on the practice of software architecture – that is what’s needed to reason about the system – such as information, process, and people.

It is a worthwhile investment – obviously if you work as a software architect, but also if you work with one or otherwise makes a living from delivering software.

#softwarearchitecture

Asking good questions

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

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

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

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.

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?