Structure? Really?

This blog will, if I find time and motivation, explain what I think is a pragmatic approach to documenting and keeping software architecture for everyone—every developer, every software project (big and small), and of course every software architect (if you think that there are or should be such people as software architects).

The postings will be presented as a sequential, doubly-linked list that grows over time—most probably together with my understanding of what I really want to explain and say. But of course, it's a blog—so you can jump to whichever posting you like ...

It will take some time until I explain that—simple, and straightforward—approach. In the meantime, I will hopefully find time to look at various misconceptions in and around software architecture—misconceptions, of course, in my view. Others may, and will, think differently.

For example, in What is a software architecture? (from 2006), Peter Eeles claims:

If you were to ask anyone to describe "architecture" to you, nine times out of ten, they'll make some reference to structure.

and, therefore

It should not surprise you then that if you ask someone to describe the architecture of a software system [...], you'll probably be shown a diagram that shows the structural aspects of the system.

Now, I hasten to say that I find Peter Eeles's article very good as a very short, but still comprehensive introduction to the standard view on software architecture. Read it!

However, to return to the question of "structure," Peter Eeles's text does what unfortunately quite a few texts in software architecture do, namely to venture into non-software territory, and then haphazardly drawing shaky conclusions. "Structure," when used in civil engineering, is not that much related to some "structural aspect": Rather, it is simply another word for "object" or "building," in a general sense. So if people use the word "structure" when uttering their thoughts about architecture, this does not at all mean that a completely different architecture—namely that of software—should therefore or similarly or analogously be concerned with the structural aspects of a system.

Of course, software architecture is concerned with structural aspects of a software system. But this has not much to do with civil engineering and its architecture.

And on the whole, this issue is not really important on its own.

However, the same mistake—looking at other disciplines like architecture of buildings or electrical engineering; and then drawing conclusions from what they do—is also made in quite a few software architecture texts with respect to diagrams and drawings.
And there, the consequences are much more grave; my personal opinion is that we all have been brain-washed (ok: "brain-washed") to believe that software architecture inherently requires diagrams. Now, diagrams are useful—but not in the way they are useful in most other engineering disciplines; and, almost obviously if you look at them, not in the way they are mostly presented in software architecture texts.
To find out why, you should, at least as an experiment, try hard to document your software architecture once without diagrams. You'll learn something.

But this is another topic, for somewhen later.

But let me "start at the beginning", in the next posting: Why don't we have a useful software architecture documentation?