What the heck does an Architect do?

I think I am in the same boat as you, but as the official job description varies from company to company, I think we can agree on a few basic parameters:

• Create foundations and patterns that should be followed and enforced
• Create Project Templates to be used for varying use cases so engineers do not lose their way
• Establish accepted and recommended technologies so engineers do not go off the beaten path
• Review code and QA part-time like a mystery shopper to ensure everything established is being followed as prescribed
• When you can, introduce CICD pipelines to help enforce and lead the direction of a given project

I think the responsibilities vary but on the technical side an architect is typically responsible for the overall structure of an application, patterns used, organisation, libraries and vendors adopted, sometimes data structure and data design (though in enterprisey environment there would be some DBA or data overlord person), approach to delivery.
These may overlap in part with a "solution architect" who typically has more of a birds eye view over a system, how parts fit, technology stack choices, vendor selection and generally synchronisation between practices across various moving parts.

Often also see architects involved in things like production readiness checklists - basically deciding what guidelines or best practices the org wants to prioritize and enforce

I can only agree with previous comments. In my role, it would involve deciding the servive responsibilities, third party services to use (aws rds, mongo atlas, elasticache and such). It also includes deciding and adopting new tech in the stacks. Decising from a requirements perspective how we should struchture APIs etc

There is no single definition. Where I work there are multiple people with the title 'Software Architect' (including me) and we don't all have the same job.

When I think of an architect there are a few different roles they tend take up. They are not exclusive - an architect could focus most of their time in one of the roles, or have some sort of split between then, and they can change over time. At the start of the hiring process of a new architect I always ask 'what type of architect do we want?' before looking at candidates and the relative split of these roles is what I consider the different types to be.

Senior Dev

A architect is still a dev and can still do dev work - adding new features, fixing bugs, investigating customer issues, etc. As a senior dev this work will tend to be more "important" by some criteria - hard problem, high risk, high visibility, etc.

Force Multiplier

Do things that makes everyone else's work better. This includes establishing best practices, evaluating new technologies, and answering tons of questions to help others in their tasks.

Actual Architect

The 'classic' architect task of designing a system to solve a problem without actually implementing the solution. May or may not end up being a Senior Dev that ends up working on the implementation.

Prototyper

When you have problem that no one knows how to solve or a possible solution who's feasibility is unknown someone needs to take a crack at it.

Executive Communicator

Executive/management should base their decisions upon technical realities. Architects are well placed to talk about both what their systems can do today as well as offering advice on future plans.

I think these roles are also independent upon the domain - security, infrastructure, front-end, back-end, etc all have these types of work and all of them can have architects that do them.

One interesting thing you may have noticed is that these are all things that a "regular" dev may be doing. Whether you have the word 'architect' in your title or not, if you are doing these types of tasks regularly you are an architect.

Question is quite ambiguous.
Solution Architect, System Architect, Cloud Architect, even IT or Software Architect but I just read last two someplace - might be made up by companies who put these ads.

Before, people thought it was necessary to have UML or such before writing code so they made those as System Architects and maybe some description about necessary servers. After it people started going cloud and hating so called OOP (class based would be more correct) and hating documentation because of UML. So we got then bunch of stuff for creating nice images. However main point of all these should be the same and should be called System architect or Solution architect. They should make a good IT solution for certain automation or problem solving. Now Solutions Architect might be different now, however it would be nice to have people developing solutions not hyped keyword infrastructure. Cloud is not a solution for everything neither is writing new software. A lot of solutons should be bunch of existing tools glued together with pinch of "custom" code for the missing parts and architect should be the one detecting which ones to write which ones to "plug-in". Buttt, many apps/webs should not be that big so each dev should be an architect in disguise to be able to put a small project, organise the parts well for maintenance both the code structure and tools around.

He abstracts invariance of the system to simplify it ;)