5 traits of good systems architecture

Two books 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: 97 Things Every Software Architect Should Know, by Richard Monson-Haefel; and Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design, by Diomidis Spinellis and 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 that 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: e.g., 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 examples of the sort of things you should expect to see when someone (or a group of people) is doing good systems architecture:

1. 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.
2. A data description: If you don't know what data is in your system, you don't know what it does.
3. An entity description: Components, users, printers, whatever, you need to know what's doing what so you can describe what the what is that's being done to it, and what for.
4. 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.
5. 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, useful tools and methodologies (the use of UML views is a great example) that 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. So document it. All of it.

You know it makes sense.

This article originally appeared on Alice, Eve, and Bob – a security blog and is republished with permission.