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!

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.”

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’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)

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, and Flowers and his associates were denied the recognition they were due.

A fully functional replica of a Colossus Mark 2 was constructed about five years ago by a team led by the late Tony Sale. You can see it now at the National Museum of Computing. It is a fascinating and inspiring exhibition, and well worth a visit.

The National Museum of Computing is now creating a completely new gallery for its most famous exhibit. You can play a part in helping to build the new gallery by sponsoring a valve on a virtual Colossus. You can get your name in lights and help a good cause!

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, but there are many others as well. The frameworks are described and categorised, and there are links to source websites where available.

If you find that our viewpoint taxonomy doesn’t give you all the coverage you need, or would just like to find out how other authors and organisations approach the subject, this is a great place to start.

Alternatively, if you know of any frameworks which aren’t mentioned (I am about to email Rich about CapGemini’s IAF framework for example) you can email Rich through the website.

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.

If you’ve never heard of InfoQ before, it’s a great online resource: “… InfoQ.com (Information Queue) is an independent online community focused on change and innovation in enterprise software development, targeted primarily at the technical architect, technical team lead (senior developer), and project manager. InfoQ serves the Java, .NET, Ruby, SOA, and Agile communities with daily news written by domain experts, articles, video interviews, video conference presentations, and mini-books.” They also help organise the QCon conferences in London and New York.

If you’ve downloaded any of these documents recently, please download them again to get the revised versions. All comments welcome!

The subject was ‘”Big Data” when the size of the problem is the size of the data itself.’

You can find more information here.

Welcome to the new website for Edition 2 of Software Systems Architecture!

Edition 2 was published in November 2011 and is a major revision of the original book. We have updated most of the chapters and added over 130 pages of additional content. The most important changes in this edition are as follows.

• We have introduced a new viewpoint, which we call the Context viewpoint. This describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts). It extends, formalizes, and standardizes the relatively brief discussion of scope and context that used to be in Chapter 8.



• We have expanded the discussion of different aspects of the role of architecture in Part II.


• We have revised most of the viewpoint and perspective definitions, particularly the Functional and Concurrency views and the Performance and Scalability perspective.


• We have revised and extended the Bibliography and the Further Reading sections in most chapters.


• We have updated the book to align with the concepts and terminology in the new international architecture standard ISO 42010 (which derives from IEEE Standard 1471).


• We have updated our UML modeling advice and examples to reflect the changes introduced in version 2 of UML.