That's a horrible description. The best people with "software architect" in their title that I have worked with have focused on total system quality through striving towards simplicity mainly by focusing on development and tooling and using their position as the arbiter of technical decisions to guide the system under development to coherent whole that fullfills the business requirements in a technically sound way.

The most complex design tool outside of an IDE I've seen these guys use is plaintext and simple diagrams. They grok the thing that is being built in their heads from the CPU caches to the end-user abstraction.

The most horrible architects I've observed deliver UML:s, search for the most complex technical thing their mind can think of to solve a problem and then after saving the UML to disk think their job is "done" and hand-wave through the rest of the development pointing to the UML boxes.

The mediocre architects are a mix of these two.

An architect who is not participating in hands-on coding is a serious red-flag about the quality of the development organization in most instances to me. I'm sure there are counter-examples :)

> That's a horrible description. The best people with "software architect" in their title that I have worked with have focused on total system quality through striving towards simplicity mainly by focusing on development and tooling and using their position as the arbiter of technical decisions to guide the system under development to coherent whole that fullfills the business requirements in a technically sound way.

Thanks for the this. This paragraphs sums up perfectly what I strive for in my day to day work. It's clear and concise.

Agreed. That is as good a description of the architect's role as I've read. It is certainly what I try to do on a daily basis.