| My view as a "full stack" architect and developer. Depends on the size of the firm. Very, very large ones will see you write little code -- generally to the detriment of the company, the architect, and the teams they interact with. Good architects are hands-on. They write proofs of concept implementations before recommending a tool or technology. Bad architects dream up nothing but gormless and inscrutable charts and diagrams that, like crap ink on vellum, slowly fade into illegibility in a remote Sharepoint server. Good architects clarify and explain. Their job is to assist teams in melding disparate technical viewpoints with that of the business -- who themselves often lack focus. A good architect facilitates that: they'll rarely look at lines of code, per se, but more the general trend and direction. Bad architects dream up complications that serve no one but their own ego. I once worked with an "architect" who spent most of his time mapping out some data, represented in JSON, using eBNF -- a tool used for specifying formal grammar for computer languages. It could've been solved with an example + some data typing in the margins. Don't be like that dude; people struggled to make sense of the trivially simple data we had to store. For larger things use a schema-like structure; for smaller things, trust that people and teams are not stupid. Good architects are skilled at everything. They've hacked up CI systems in batch or bash files, before the current tooling even existed. They've built all manner of systems, in a range of environments and possibly languages. They're pragmatic, and can spot trouble a mile ahead. Bad architects envelop themselves in what ever the buzz du jour is: like microservices, which is never an opening gambit for 99.9% of problems you're going to encounter in a greenfield project. They're the ace up the sleeve when all other performance and scalability efforts have failed. Good architects know when to tell a tech lead to lay off the technobabble: chroming your CV is not in the interest of the business as a whole. Good architects prefer plain, old working tools. That usually involves a RDBMS. Sometimes many; and often times you need to make existing ones talk to other things. Bad architects thing old means bad. XML is not bad; what people did with it was, for example. |
At my current company it's actually a fight as it's not necessarily the architects themselves that want to shit out diagrams all day.
It's a part of the job, for sure, I'm just pointing out it's not always the architect.
but your points about hands-on, respect simple, and having a wide base of experience is 100% spot-on imo. I do agree with your point about the diagrams, just wanted to point out that's sometimes due to pressures rather than wants.