The Art of Architectural Governance pt. 1

(This is the first in an occasional series.)

An important part of the architect’s job is to have oversight over projects during their design and build phases. You need to ensure that the system that is built is the one that you (or some other architect) designed, that everyone is lined up behind the architecture’s vision and principles, and that any architectural limitations or omissions are picked up and dealt with before they get out of hand.

I’ll talk about what this involves some other time; for now I want to talk about the skills you need for effective architectural governance. One of the most important of these is Questioning and Listening. If you don’t know what’s going on in your projects – what people are doing and what problems they are facing – then you can’t possibly have any constructive influence over them. (Incidentally, if you have need of the related skill of Detecting Liars then you are probably in a worse situation than can be dealt with in one blog post.)

When I started as a consultant at Logica, which had an excellent graduate training programme, one of the first courses they sent me on was called Information Gathering. I had no idea what this was about, but it turns out that the techniques I learned in those three days have stood me in good stead throughout my career. I make use of them almost every day: whether it’s in a structured process such as requirements capture, or in a more informal setting – just finding out what’s going on – I don’t think I could do my job effectively without them.

The techniques are fairly straightforward in theory but require a lot of practice and self-discipline to get right. It all starts with Open Questions. An open question uses words like “what,” “why,” or “how,” or phrases like “tell me about” or “walk me through.” Open questions encourage people to share what they know and consider what they are saying, and often reveal facts and opinions that they consider trivial, but are actually really important. Closed questions, on the other hand (which typically have a yes or no answer) tend to just reinforce the biases and assumptions of the participants and should generally be avoided.

Open questions often unleash a flood of useful information, and as well as writing it all down (you can record interviews, but many people find this intimidating) you need to be able to process and respond to what’s being said on-the-fly. The way to do this is to listen out for key words and phrases and then drill downinto these with more focused open questions. This is where you can start to uncover something really vital that needs your attention: the system actually has a single point of failure, for example, or there is a requirement that hasn’t been implemented, or the team actually have their own ideas about the architecture and aren’t building what you specified at all. Drill-down is essential if you want to find that important nugget of information hidden underneath a mass of facts.

There are two further techniques you can use. The first of these is feeding back, and it’s important that you do this regularly. Here you explain to your questionee what you think they’ve just told you, in order to get their confirmation or more likely be corrected on something you’ve misunderstood. The second is to use targeted closed questions to elucidate specific facts. You shouldn’t do too much of this (see above) but they are sometimes helpful.

I’ll go through an example of using these techniques in a subsequent post, but this skill is something that is best learned in the classroom, where you can try it out in a risk-free environment. In my view it’s the most important “soft skill” you need to master to be an effective software architect. it’s even more important than the ability to think in the abstract, to see the big picture, and negotiation and compromise (of which more later).

I’ll leave you with one final thought: there is no such thing as a stupid question, and there is no question so obvious that you won’t benefit from asking it. Good luck!