Blog

IASA UK Architecture Summit, London 22-26 April

Eoin and I are both fellows of IASA, the International Association of Software Architects, a global organisation which promotes “the advancement of [architectural] best practices and education while delivering programs and services to IT architects of all levels around the world.” The 2013 Summit is taking place in London, UK and Eoin and I are both running various sessions during the week.

On 23rd April we are running a one-day tutorial on “Software Architecture using Viewpoints and Perspectives,” which will present and discuss our approach to defining and describing architectures for complex information systems. Our objectives for this interactive tutorial are to:
– provide an overview of the viewpoint oriented approach to software architecture
– introduce and explain our viewpoint set
– introduce the concept of a perspective, to guide the consideration of the quality properties of a system
– introduce and explain a set of perspectives and show how they can be used with our viewpoint set.

Eoin is also running an intriguing session called “A Team, A System, Some Legacy … and You,” in which he will describe his experiences working on the architecture of existing systems, and the principles and techniques that he has used to be mostly (his words, not mine!) successful in doing this.

Lastly, I am running a session called “Real-World Architecture Review.” In this session, I will present a number of tools and techniques I have developed to do architectural reviews that are objective, consider all the important aspects of the system under review, and lead to better architectures.

The IASA Summit looks to be a great event for new and experienced architects alike. We hope to see you there!

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.

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!