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!

Back Story

I’ve just come out of a fairly long period of poor health due to back problems. After two prolapsed discs, three rounds of spinal injections and about four hundredweight of prescription painkillers, I hope to be a little more active on the site from now on.
This has been a painful illustration of the effect that a sedentary lifestyle (regular swimming doesn’t really help) has had on the state of my spine. I’ve had occasional mild back pain for years, and my physio tells me that if I’d dealt with it when it first appeared I would have avoided the agonising spasm that my lumbar spine went into (twice) last September, and the neck problems I’ve had since Christmas.
I’m finally back at work now, and as you’ll see Eoin and I are collaborating on a couple of things over the coming months. I’ll also be discussing some architectural initiatives I’m involved in (or leading) at work. Watch this space!

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!

Teaching Computer Science

While the UK produces many highly-skilled computing graduates (disclosure: my son will be one in a couple of years) the quality of computer science teaching in primary and secondary schools leaves a lot to be desired. This has little to do with the teachers (who are motivated and talented in my personal experience), but an unimaginative and outdated curriculum which focuses more or less exclusively on how to use Powerpoint, Word and maybe a bit of Excel. So our children get reasonable exposure to computers as a tool for teaching and learning, but learn almost nothing about how computers actually work.

As a result we have a generation of young people in the UK who are depressingly ignorant about computer programming, computer hardware and networking. We teach our children about Newton’s laws, chemical reactions, and photosynthesis, but not about CPUs, networking, or compilers. Apart from the members of the school’s Computer Club (if there is one) we don’t give them the chance to write software or build their own computers. We teach them Ohm’s law but not Moore’s Law.

John Naughton is a columnist for The Observer and professor of the public understanding of technology at the Open University. He feels strongly on this issue, and has written a manifesto calling on the UK Education Secretary, Michael Gove, to overhaul the ICT curriculum. He wants computer science is taught as an “academic discipline in its own right and not … merely acquiring skills in the use of constantly outdated information appliances and shrink-wrapped software.”

Arthur C Clarke famously said that “any sufficiently advanced technology is indistinguishable from magic.” However there is no reason why this should be true of information technology. As Naughton says in his manifesto, “in a world shaped and dependent on networking technology, an understanding of computing is essential for informed citizenship.”

First UK Review of Edition 2 gets 10 stars!

We’ve had our first UK review of Edition 2, which you can find here.

The reviewer gives us 10/10, saying that we “provide a thorough yet concise discussion of the principles underlying their subject, often with reference to original sources, coupled with a pragmatic discussion of the application of their ideas, clearly based on a great depth of experience.”

He adds that the book is “well written, with a readable yet authoritative style, so that even material on familiar topics is enjoyable to read. It is a mark of the authors’ clarity of thought and expression that they have represented the relationships between core concepts as simple UML diagrams, which provide a clear and concise overview of some of the key ideas.”

He recommends it for practicing or aspiring IT architects, who will “find in this book much pragmatic, actionable advice on the production of effective architectural descriptions, all of which is backed by a clear and readable account of the more fundamental ideas upon which that advice is based.”

Incidentally, our current tally of five-star reviews at Amazon.com is 22 out of 25!

IASA Meeting in London

A lively IASA meeting in London last night. Paul Preiss, who runs IASA (the International Association of Software Architects), was at the meeting and he walked us through IASA’s certification programme.

IASA’s mission is to get software architecture established as a profession, and to put in place a mechanism whereby we can be registered and assessed like doctors, teachers or indeed building architects. They run a comprehensive training, mentoring and certification programme and have branches throughout the world.

If you are interested in the profession of software architecture, you should definitely consider becoming an IASA member. The IASA website has details of a chapter near you.

(Disclosure: Eoin and I are IASA Fellows and have provided material for their website in the past)

Sponsor a Valve on Colossus

Colossus was the world’s first electronic digital programmable computer. It was designed and built by a team led by Tommy Flowers at Bletchley Park, UK, and was used to help decipher encrypted messages between Hitler and his generals during World War II.

Ten Colossus computers were in use by the end of the war. The intelligence gained is generally acknowledged as having shortened the war by two years and to have saved countless thousands of lives.

Colossus remained highly classified after the war, and Winston Churchill specifically ordered the destruction of most of the Colossus machines into “pieces no bigger than a man’s hand.” It was erased from the history of computing, read more ››

Survey of Architecture Frameworks

Rich Hilliard is one of the people behind the ISO 42010 architectural standard (the international revision of IEEE 1471). He runs a website for the standard, which has a lot of material about architecture frameworks, standardisation and taxonomies.

One of the most useful pages is a Survey of Architecture Frameworks. Rich and his colleagues have collected information on a wide range of architectural frameworks from industry and academia. Ours is there, of course (!) along with well-known frameworks such as TOGAF and Phillippe Kruchten’s original 4+1, read more ››

Eoin and Nick Interviewed on InfoQ

You can see a short interview that InfoQ did with Eoin and me on our new book here.

In the interview we talk about the motivation behind the first edition of the book, and the rationale for some of the changes we made for the second edition (for example, adding the Context viewpoint). We also discuss architecture in the context of some of the “hot” topics for InfoQ readers such as cloud computing and agile development.
read more ››