The Art of Architectural Governance – an Example

In my last post I wrote about the importance of questioning and listening, and described a simple but effective technique for information capture. I thought I’d follow up with a (hypothetical) example to show how it works in practice. In this example I am talking to Sally, the tech lead on a project which is running into some architectural difficulties.

I start by asking her, “what is your system supposed to do?” This is a nice open question which prompts her to give me a pencil sketch of the system, which tracks the repair status of cars operated by a car rental firm. The system is called CARS (Consolidated Automible Repair System) and is at the early design stage.

At one point she mentions “one-way rentals,” a term which is I haven’t come across before. I make a mental note of this and when she finishes her description I ask “what is a one-way rental?” It turns out this us where you drop off the car at a different place from where you collected it. “How does a one-way rental work?” I ask. This is another open question which drills down into one aspect of the system in more detail. (I’ve chosen to explore this because Sally seems worried by it – observing your interviewees’ body language and mood is always important – and because I have a gut feel it could be problematic.)

Sally walks me through how one-way rentals work. I ask a several more focused open questions, and finish off with “could the return be in another country?” This is a closed confirmation question, to which she answers yes. I end this part of the interview by playing back to her my understanding of how one-way rentals work. I’m largely correct, although I hadn’t realised that you had to arrange the drop-off at the time of booking.

We then turn to the architecture of the CARS system. Because I now understand the complexity of one-way rentals, one of the areas we are able to productively focus one is the way the system will manage distributed rental and repair data. Together we come up with a architecture which can replicate this data between the different sites in a timely and reliable manner.

Why has this technique been so important? Well, without it I might never have understood the importance and complexity of one-way rentals, and the significant implications this had for the architecture. I also had some assumptions about how this work, some of which proved to be incorrect. Playing these back to Sally quickly identified this and allowed me to correct my preconceptions.

Finally, this technique also helped quickly establish a relationship of trust between us. I was able to show Sally my genuine interest in her system, acknowledging her expertise and demonstrating that I understood what kinds of problem the architect for such a system has to overcome.