In my experience an "architect" is someone that used to write code (maybe 10-20 years ago - maybe only for a few years to begin with) but followed incentives aw

In my experience an "architect" is someone that used to write code (maybe 10-20 years ago - maybe only for a few years to begin with) but followed incentives away from the practice. Now they read blogs written by other architects about technologies that none of them have used. They champion the iterative process, but have 20 hard requirements up front that "make sure we can scale" (there are 5 users of this intranet app). They have 30 minutes free per day to produce any deliverables, all other time is spent in meetings. The deliverables produced are diagrams which have a few boxes and arrows pointing between them. Engineers are quick to ask, "Aren't those arrows backwards? We pull data from that service, right?". To which the architect replies without thought, "Ah, yeah, you're right. This is more of a work in progress, something to work off of." The next slide in their presentation is about database normalization and shows some data model that they hallucinated without looking at the data. The engineers chime in again, "Do we care more about the size of the data on disk or read times here?". The architect doesn't understand why you would challenge "best practices". You don't understand why the person presumably leading the initiative is unaware that computer science is fundamentally about trade offs. It's not always like this, but the bigger the company, the more statistically probable it is.