Human-Centered Architecture: Overview

Let's treat technical architecture as an exercise in human-centered design, and learn from ergonmics and human-computer interaction.

NOTE: CURRENTLY IN RAMBLING DRAFT MODE! - TODO Add examples of human-centered principles and show the parallels

Why Architecture Should Be Human-Centered

The stereotypical techie got into software because he (yes, "he") can't deal with people. If this is true, he chose the wrong business. Many techies have to deal with managers, clients, and analysts. But forget about them for now, because what I'm talking about is strictly t2t: techies dealing with other techies.

Even the most hardcore geek - the mythical beast fed pizza through a slot in the door - interacts with techies. In some cases, he may actually talk to them. In all cases, he is writing software which will have to be understood by an audience of techies, even if the audience consists of himself at a later point in time. So hopefully he can see others' point of view and communicate accordingly.

When software is written without empathy, maintainability suffers. You get interfaces which defy logic and data structures not representative of any construct in this universe. Consequently, fixes and enhancements are extremely slow. Even if the maintainer is the original developer, he will have difficulty recalling how everything works. Complicated systems cannot easily be stored in one's head; human memory is imperfect, and works by retaining broad patterns. It won't do much to help you remember that your sysFunkFactr variable was actually a counter for potential errors, and it will do do even less to help you recall that you should never attempt to reset sysFunkFactr when systemXFactr is negative and today is Tuesday. These concepts are almost as difficult for the original developer to recall as they are for a new maintainer to learn.

Software architecture is a human-centered activity. "Architecture" here means anything as minor as the names of a variable and as grand as the blueprint of a multi-organisational distributed database. The common element is that humans must understand, evaluate, and maintain these artifacts. So they had better be designed by someone who is cognisant of human cognition.

These ideas are hardly controversial and not barely original. My point, though, is that human-centered design should be an explicit part of mainstream software architecture. Before I discuss what should be done, let's look at what we already have.

How Architecture is Already (Sort Of) Human-Centered

Gerard Weinberg wrote about psychology and software as long back as the 1970s. Likewise for Constantine and Yourdon, who argued that diagrams such as their data flow models were all about working with the strengths and weaknesses of human psychology. And Peopleware, focusing more on process issues, was penned by DeMarco and Lister in 1987.

One might have thought the industry would have carried these ideas forward as it matured. It hasn't. Human-centered design and psychology of software are hardly mainstream topics. However, we should not be too pessimistic, because many of today's practices certainly are human-centered. The only problem is we have stumbled upon them by trial-and-error, rather than based the work on explicit application of human-centered design principles.

Here are some contemporary approaches which respect human facilities:

Beyond Trial-And-Error

Each of these approaches evolved through a slow process of trial-and-error. Any human-centered rationale given is usually vague, rarely based on human-centered design principles, and almost never validated by empirical evidence. Typically, the closest it gets is a statement like "the language is cool because it lets me work the way I think". Or, "this API is much improved because you don't have to call it a million times just to do the most basic thing". It's nice to know many contributions are intended to support human cognition, but there is a distinct lack of theory and validation.

Software architecture has progressed in this way not by design, but by a process of trial-and-error. Better than nothing, but we have a long way to go. There are several benefits to explicitly considering how software architecture can be more human-centered. I call this approach "Human-Centered Architecture", and it promises these benefits:

A good example of research that considers human-centered architecture is Helen Purchase's work in visualisation. Here is a field which should be 100% human-centered --- there's no point representing data visually unless a human can benefit from seeing it. And yet, few have dared to go beyond fancy algorithms and actually see if there is any benefit. The results can be different from expected, and are certainly worth studying. Here is a paper which considers performance using UML diagrams).

So What?

Everything above should be pretty obvious to you. And equally apparent is that I've said nothing of any practical benefit. If I finished here, you could accuse me of being a truism-spouter, and I would not find that very pleasant. So I intend to provide some concrete examples, patterns, and advice on how to make your architecture more human-centered. To start with, check out the Programmasaurus, which supports self-documenting code, a key practice of human-centered architecture.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.