Прежде чем описать такого персонажа как Solution(s) Architect (далее SA) надо для начала пояснить принципиальные отличия между инженером и архитектором. Писать тут очень много, поэтому буду разбивать

Эти отличия в принципе подходят для всех ролей, например:
- Software Engineer -> Software Architect
- System/Infrastructure Engineer -> Infrastructure Architect
- Database Administrator -> Database Architect
- DevOps/Site Reliability Engineer -> Solutions Architect
- Cloud engineer -> Cloud architect

Пусть эти стрелочки не вводят вас в заблуждение - архитектор не всегда “лучше” инженера.

Я уже писал ранее, что архитекторы и инженеры работают (и должны работать) по-разному. Разница начинается уже в процессе onboarding (когда новый сотрудник только вышел на работу). Обычно инженеру, в зависимости от его основной роли, показывают его землю обетованную, продукты и проекты, знакомят с командой (иногда знакомят с другими командами, в зависимости от размеров конторы), помогают настроить рабочую станцию, системы и вводят в курс дела.

Условный сферический конь в вакууме (будь он Windows или Linux инженером) потратит первые месяцы на изучение конкретно своего (и зачастую только своего) домена (Под доменом понимается зона его экспертной оценки). Проще говоря Linux человечек не полезет в дебри Active Directory или SCCM. Он дойдет до этого (особенно в Scrum команде), но очень нескоро.

Архитектору же положено узнать все - от бизнеса компании и структуры организации до ВСЕХ продуктов и ВСЕХ процессов. Вот тут и кроется главная заковырка - изучить надо все, но запомнить все при этом будет невозможно. Остается достичь какого-то определенного абстрактного “понимания”, как все работает, и, поверьте, это далеко не самое главное. Не ждите, что с вас реально спросят как компоненты работают между собой. Это так же глупо, как спрашивать профессионального ретушера рассказать абсолютно все функции Adobe Photoshop.

Гораздо важнее на стартовом этапе понять не “как оно работает”, а какие причины и история стоят за выбранными системами и технологиями. Одним из моих основных вопросов на собеседовании был “почему”. Знать “почему” гораздо важнее, чем “как” и “что”. Это - первое отличие архитектора от инженера.

Узнав историю, вы сможете понять в каком (плачевном) состоянии находится контора и ее продукты и почему, и как с этим жить и что делать дальше. Запомните и запишите, поскольку это очень важно.
Архитекторов не нанимают, когда все хорошо. (На собеседовании вам об этом, разумеется не скажут, иначе можно спекулировать на зарплате)