My Not So Private Tech Life

Evolutionary software architecture (ESA) has been one of my favourite topics for quite a while, despite the fact that I often look down my nose at people calling themselves "software architects". If you're interested in ESA (and if you understand spoken German) you can listen to my take on it or just read the slides.

Now - for our customer's sake - I'm sometimes called an architect myself; that's why Willem's article on customer-oriented architecture made me reconsider my attitude about "software architects" in general and my personal approach in particular. He writes:

I used to like the “architect also implements” pattern. Johanna Rothman’s "Architects Must Write Code" seems to be a more prescriptive variant of the pattern - I’m missing the contexts in which it applies, and contexts in which it doesn’t. Reading "Architect as Consultant"? it seems Johanna believes architects who don’t program on “the project” can’t work. [...]
If you’re building just a house, “architect also implements” might be feasible, or maybe it is the master builder that also designs. If you’re re-building a city, having the urban planner run around with a hammer and a box of nails would be seen as micro-management.

I whole-heartedly agree with Willem's point of view that a software architect's role strongly depends on a project's context - size being one of the more important contextual parameters. As for me it all comes down to a few principles:

• A good architect has to be very knowledgeable on the topics he considers to be his realm of decisions & recommendations. He must be able to actually show how his recommendations can be realized at the next lower level.
• An architect should strive for getting as much concrete feedback as possible and as quickly as possible in order to (dis)prove and adjust all decisions he's been making.
• An architect must stay long enough to face the music of his decisions. In other words: He's the last to leave the sinking software.

In projects where "the architect" has the last word as for programming model, design and development approaches those principles basically lead to our starting assumption "Architects Must Write Code", at least now and then. The larger the project and the larger the organization the more there's a need for someone considering full-time how the suggested software can be divided (and conquered), how the system will be embedded in the existing landscape and how all this fits in with the company's "strategic" development platforms and ERP systems. In those projects, however, there's probably room for a couple of architects, all of them with different decision scopes. And probably we should give them different job titles, too.

That said, I still have difficulties to imagine a software architect of value who cannot write code (any more). In the end, even Frank Lloyd Wright was able to hammer in a nail straight and sound and in the exact right spot. At least, I wish he was that sort of guy.

Update

Willem followed up on this story with Architect also hammers nails. However, there seems to be a flip side to Frank Lloyd Wright's way to trade-off form against function. In Stewart Brand's How Buildings Learn Wright is cited as follows:

If the roof doesn't leak the architect has not been creative enough.

I wonder whether that fits my idea of quality software. I bear with him, though; we all have our skeletons in the closet.

Johannes