My very first post on this blog, some six months ago*, was entitled “Systems security – why it matters“, and it turns out that posts where I talk** about architecture are popular, so I thought I’d go a bit further into what I think being an architect is about. First of all, I’d like to reference two books which helped me come to some sort of understanding about the art of being an architect. I read them a long time ago****, but I still dip into them from time to time. I’m going to link to the publisher’s***** website, rather than to any particular bookseller:
- 97 Things Every Software Architect Should Know, by Richard Monson-Haefel
- Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design, by Diomidis Spinellis , Georgios Gousios
What’s interesting about them is that they both have multiple points of view expressed in them: some contradictory – even within each book. And this rather reflects the fact that I believe that being a systems architect is an art, or a discipline. Different practitioners will have different views about it. You can talk about Computer Science being a hard science, and there are parts of it which are, but much of software engineering (lower case intentional) goes beyond that. The same, I think, is even more true for systems architecture: you may be able to grok what it is once you know it, but it’s very difficult to point to something – even a set of principles – and say, “that is systems architecture”. Sometimes, the easiest way to define something is by defining what it’s not: search for “I know it when I see it, and the motion picture involved in this case is not that.”******
Let me, however, try to give some examples of the sort of things you should expect to see when someone (or a group of people) is doing good systems architecture:
- pictures: if you can’t show the different components of a system in a picture, I don’t believe that you can fully describe what each does, or how they interact. If you can’t separate them out, you don’t have a properly described system, so you have no architecture. I know that I’m heavily visually oriented, but for me this feels like a sine qua non********.
- a data description: if you don’t know what data is in your system, you don’t know what it does.
- an entity description: components, users, printers, whatever: you need to know what’s doing what so that you can describe what the what is that’s being done to it, and what for*********.
- an awareness of time: this may sound like a weird one, but all systems (of any use) process data through time. If you don’t think about what will change, you won’t understand what will do the changing, and you won’t be able to consider what might go wrong if things get changed in ways you don’t expect, or by components that shouldn’t be doing the changing in the first place.
- some thinking on failure modes: I’ve said it before, and I’ll say it again: “things will go wrong.” You can’t be expected to imagine all the things that might go wrong, but you have a responsibility to consider what might happen to different components and data – and therefore to the operation of the system of the whole – if********** they fall over.
There are, of course, some very useful tools and methodologies (the use of UML views is a great example) which can help you with all of these. But you don’t need to be an expert in all of them – or even any one of them – to be a good systems architect.
One last thing I’d add, though, and I’m going to call it the “bus and amnesiac dictum”***********:
- In six months’ time, you’ll have forgotten the details or been hit by a bus: document it. All of it.
You know it makes sense.
*this note is for nothing other than to catch those people who go straight to this section, hoping for a summary of the main article. You know who you are, and you’re busted.
**well, write, I guess, but it feels like I’m chatting at people, so that’s how I think of it***
***yes, I’m going out of my way to make the notes even less info-filled than usual. Deal with it.
****seven years is a long time, right?
*****almost “of course”, though I believe they’re getting out of the paper book publishing biz, sadly.
******this is a famous comment from a case called from the U.S. called “Jacobellis v. Ohio” which I’m absolutely not going to quote in full here, because although it might generate quite a lot of traffic, it’s not the sort of traffic I want on this blog*******.
*******I did some searching found the word: it’s apophasis. I love that word. Discovered it during some study once, forgot it. Glad to have re-found it.
********I know: Greek and Latin in one post. Sehr gut, ja?
********.*I realise that this is a complete mess of a sentence. But it does have a charm to it, yes? And you know what it means, you really do.
**********when. I meant “when”.
***********more Latin.
Alice, Eve and Bob - a security blog 
3 thoughts on “Thinking like a (systems) architect”