Writing SQL and drawing diagrams for enterprise systems inside of a huge company is not what the highly-compensated senior engineers tend to be doing. If you want to make more money, move out of being an “architect” and into being a principal engineer at a tech company (one whose business is making software; not a company that just happens to employ software developers).
Its not about diagrams and SQL, its about a bunch of things, that can be broadly related to "making everyone more effective at the work they do", "lead huge company changing projects" and "create enough value to have a budget to hire a large team and build a thing to achieve a business goal"
What the heck, principle engineer is considered higher than architect? What about principle architect? I might need a flowchart somewhere that describes all the tech levels above "senior software engineer".
From what I've seen architects are alongside engineers, not above. Also depends on what kind of architect - solution architecture tends to be a completely separate track, etc.
My job isn't to sit down and write code, most of the time. What I do is take a business requirement, go back and forth with a ton of business people to nail down exactly what they need or want to do, and then go on a series of requirements gathering sessions after figuring out the impacted or required systems. So let's say someone wants to digitize a specific set of communications. It makes more sense to build internal and scalable capabilities to be able to digitize any communication - so working out the technologies required to do that, the integration points, the patterns for how to do it. It involves learning a lot and then evaluating what you learned, and eventually diagraming it all out into an architecture that the domain and solution architects use.
The domain architects then would add in more detail and requirements within the systems that are affected and finally the designs get to the solution architects.
The solution architects go through the whole sketch and make sure it makes sense, that the data or whatever required will get to them and that their platform(s) are empowered and capable of performing the work thats being asked. They then design the solution for those technologies and when programming needs to get done then that is sent to the engineering teams to actually build it.
In terms of hierarchy the programmers/engineers tend to be the recipients of requirements rather than really being involved conversationally. I don't necessarily agree with this approach and I try to work directly with programmers where I can. And more often than not I'll work with them doing PoC coding in whatever technology - usually java, of course.
