A funny story I have heard many times is that of a helicopter pilot who was lost in the fog. He saw an office block in the gloom and a person at the window. He shouted out “Where am I?” and the person in the office block shouted back “In a helicopter”. On hearing this the pilot immediately flew straight to the nearest airport and landed. The passengers turned to the pilot and asked “How did you know were we were from that answer?” The pilot replied “Well it was completely correct and utterly useless so I knew it was someone from a IT telephone support service and I know where they are located so could find the airport.”
I was reminded of this yesterday when I was asked to look into a customer support issue on security. I had a look at the initial issue and the response which was completely correct and accurate; indeed if anything was rather too voluminous. However it wasn’t what the customer was looking for and so the customer quite reasonably escalated the problem. In fact the problem wasn’t really a technical one (as so often is the case with security issues) but rather a physical one but of course the technical support person could only see the technical (and not very good) solutions.
So what has this got to do with architecture? It occurs to me that all too often the discussions people have don’t take account of the environment or model that other person is working with. Just like to a man with a hammer every answer involves hitting things to a programmer every answer involves programming. The trick is to understand the domain that the discussion and issues exist in and then work in that domain.
This is of course what architects do day in and out; understanding the level of abstraction that is being worked at and the resolving the issue at that level.
A few days ago someone pointed me to a book called “Blink” on this blog. I was sat at the airport last night (my second home.. seat 5A is my primary one J) and found the book on the bookstand so proceeded to read it (one of my few skills is I can read incredibly fast). The premise of the book is that you can analyse things very quickly and get to the correct answer very quickly by slicing the problem. The trick is to slice the problem at the right level and then get the right answer far more quickly and accurately than someone who tries to do a full analysis. I agree with this and feel that it is one of the key attributes of a “good” architect; the ability to asses a situation or problem at the correct level, just use the appropriate and relevant data at that level and get the answer very quickly.
I feel very fortunate that I am able to do this well; given my lack of many other skills it is very valuable in both my day to day and professional life. I wonder how it can be cultivated.