Coding the architecture or architecting the code

Many have asked the rhetorical question „Should software architects code?” In my experience if you ask that question directly to an architect who does code you get a resounding “yes” and a look that suggests heretical attitudes in just thinking of asking. Ask the same question to an architect who does not code, you get a resounding “No” and are left with the impression that coding is somehow a menial task that real architects don’t need to get involved in.

Sometimes though, if I listen carefully or reflect on what I do or have done, I get glimpses of what software architects hope to achieve by coding. This leaves me with the impression that the question should be rephrased to “Why should software architects code?”

Let’s list some answers:

A software architect has to communicate with the developers in order to guide them in implementing the architecture. Writing code is the only way to communicate the intent of the architecture. Ultimately this comes down to the fact that no “language” exists to communicate architectural intent that is both understood by developers (who read it) and architects (who write it). Although UML goes someway to fulfill this need, judging by the number of architects who feel they should code, it doesn’t seem to go far enough in explaining architectural intent.

The architect has to ensure that the system being developed actually implements the proposed architecture. As documentation is suspect and may even not be there, the architect has to read the code. But wouldn’t it be more efficient to have a tool that extracted the architecture from the code so that the architect only needed to make a comparison? Unfortunately tools to visualize the architecture based on the code do not seem be mainstream, especially in the context of modern distributed software systems (i.e. the type of system we really would like to see the architecture for!).

Architects need to code to understand new components, frameworks, ways of doing things etc. Most artifacts that are intended for general use in the software world are, from the viewpoint of an architect, terribly documented. Instead of providing clear advice on where a component (or framework or library) can be used, what problem it solves and in what context it solves that, most documentation forces the reader to go through page after page of coding examples which only show how it can be used. In short, the how, why and where are not there.

And some just like coding. The problem with this is that the architect can find themselves very quickly on the critical path for development leaving little time for architecting the rest of the system.

Most of the above are about one thing - communication of the architecture - be it from architect to developer, developer to architect (via the implemented system) or supplier/vendor etc. to the architect. Software architects seem to be trapped like the prisoner in Plato’s cave. They cannot see the architecture, but only the shadows of it in the code.

Isn’t about time to change that?

Architecture that learns

I recently came across a rather old (1997) BBC series on architecture - buildings rather than software. The series - "How Buildings Learn " - concentrated on what makes a building adaptable to the continually changing needs of those who live in them. The parallels to software architecture are astonishing. There is even an interview with Christopher Alexander - that's right, the man who inspired the patterns movement.