Арх решения (солюшен который) это как арх проекта - архитектурно говорит какой компонент какую функцию будет выполнять, с каким компонентом, по какой технологии будет взаимодействовать. При этом под компонентом подразумевается и система. Далее в каждой системе есть системный архитектор: он декомпозирует свою систему на компоненты и так же расписывает-какой с кем и как технически. Если новый компонент, то арх выбирает стэк. Системный аналитик же описывает логику в рамках своей системы/компоненты. На примере: проект - надо поменять у стула (офисный стул на колесах) колесики, чтобы кататься в разные стороны. Солюшен скажет - меняем на 2 и 3 ножке 2 колеса, на 1 и 4 не меняем - там уже и так нужные. Колесики надо пластиковые, такого-то диаметра, вращающиеся. Системный архитектор 2ой ножки говорит - стержень ножки нужен такого-то диаметра, шайбу надо и резиночку (в таком порядке перед завинчиванием расположи шайбу резиночку и привинтится. Для отвинсивания/привинчивания используй ключ гаечный такой то. Системный аналитик по полученным инструментам скажет: сначала отвинтим - берем ключ, крутим влево до тех пор пока не отвалится старое колесико. Берем новое, сначала шайбу рукой правой, потом резиночку рукой левой, потом стержень приставим, возьмем ключ, с помощью ключа, крутя вправо, привинтим до упора. Аналитик и архитектор 3ей ножки может также сделают, а может, в силу особенностей своей ножки, скажут делать немного по-другому - крути влево, как пример.

Очень часто путают роль (функциональные работы) и должность

На примере сбт 5летней давности как раз и можно понять эту разницу :) солюшен арх - арх дка, который готовил концептуальную архитектуру решения на проект (hld). Потом отдавал ее арх систем. Что-то правили, что-то принимали как написано. Потом аналитик писал тз, а арх смотрел - на соответствие  концепту hld и оптимальности/корректности  в рамках системы. Тим лид часто одевал шапочку системного арха чтобы описать интеграционное взаимодействие.

Спасибо! Понятно, надо выдерживать уровень абстракции.
Тоже часто вижу, что архитектор выполняет роль аналитика и наоборот. Многие компании считают, что четкое разделение на уровни компетенций - это долго и дорого. В таком случае начинается смешения ролей в рамках проекта или направления - те вот проект, твоя задача его сделать, ресурсов особо нет, делай все сам, может быть кто подскажет или поможет.
Мне грех жаловаться, тк в таком случае нарабатывается переходный опыт.
Рынок ценит то, что дает прибыль. Компании бывают обоих типов, лично я уверен, что второй тип исчезает, когда у сотрудника при выполнении своих должностных обязанностей просто не остается времени на другую (работу широкого спектра) работу и он вынужден будет специализироваться. Это часть роста компаний, часть взросления компании как системы.

Просто профессия архитектора интересна тем, что в ней нет некого пути или cookbook по которому можно разобраться в профессии. Есть несколько основных вводных, описание порядка мышления и серпантин технологий, все из которых выучить не удастся (да и не нужно). В каждой компании своя кухня, но всегда задаешься вопросом - как идти дальше, что учить и как оценить свои достижения. Походе тут ответы всегда будут философские. Особенно с последним вопросом - кидаешь резюме, берут - значит достоин))) Иначе иди думай, чего тебе не хватило.

Что учить? Рома хорошо сказал - если работа соответствует направлению профессии, идет новый опыт, ты приносишь компании профит, то стоит на этом и сосредоточиться. По сути учиться надо менять мышление и нарабатывать паттерны, изучать и тестировать технологии.

А идти нужно туда, где тебя ждут. Это я уже аналитиком понял)

А так ли надо учить? :) может научиться быстро находить ответы полезнее, с учетом скорости изменений. Не учить надо, скорее понимать ;)

Ну, я пошёл в ИТМО на переквалификацию и с уверенностью потерял на этом год. Учиться в прямом смысле и правда не всегда хорошо.

Мой друг хорошо говорит, что сейчас он стал "решателем проблем", а босс сказал, что "есть два типа людей - которые пашут и которые не пашут" видимо к этому мы и движемся.

Пришел к такому же делению

Нотацию квадратики и стрелочки. Т.е. просто рисуют то, что считают полезным, Потом такие диаграммы мало полезны, если рядом нет автора  Так как непонятно, что означает данная конкретная стрелочка или квадратик. Очень часто на таких диаграммах пытаются одновременно показать и статику, и динамику, и таймер пририсовать.

Ровно наоборот. "Большие и серьёзные" нотации полезны только таким же любителям нотаций. С этой картинки никто не считает информацию, кроме другого архитектора, а это и означает абсолютную бесполезность.
А любой документ должен быть ориентирован на читателя, а не на писателя.

Поэтому нотации - в мусорку, квадратики и стрелочки - в жизнь.
И учитесь рисовать максимально понятно, а не максимально наукообразно ;)

Ровно по этой же причине здоровые люди не используют в жизни кванторы, например (хотя иногда и хочется)

Алексей, я с вами согласен по поводу простоты и понятности.
Но не согласен по поводу нотаций. Нотации как раз и призваны упростить жизнь.
Вам для каждого квадратика и стрелочки объяснять приходится давать или подписывать, а с помощью нотации и легенды всё становится понятным мгновенно. Я специально проводил опросы: всё понятно с первого взгляда даже тем, кто видит первый раз, если есть легенда.

Легенда - совершенно другое же, тут согласен что она полезна (но недостижимый идеал имеет встроенную прямо в картинку легенду, а не подпись снизу)

А именно большие и сложные нотации - их проблема в том, что их надо знать. А вероятность, что проджект-менеджер, тестировщик, программисты, админ и бизнес-заказчик знают "любимый архитектором раздел UML" - она околонулевая же

Базовый набор ArchiMate можно выучить за 2 дня.
Его (или подобный язык) надо использовать при обсуждении решений.
А UML это уже для программных архитекторов и разработчиков. Он может быть нужен или не нужен, уже зависит от ситуации. Но он точно не нужен для общения с бизнесом и даже с архитекторами предприятия или решений.
Если мы хотим общаться и понимать друг друга, конечно нужно знать язык. Но как я сказал, ArchiMate прост и более того, его можно упрощать в рамках организации (многие так и делают).

Мой вариант ответа: они комфортно чувствуют себя с теорией множеств, о которой им когда-то давно рассказывали. Модель это множество элементов и множество отношений над этим множеством, т.е. подмножество декартова произведения множества на себя + классификаторы элементов и отношений. Диаграмма - любое подмножество множества элементов и множества отношений. В общем, как в TOGAF-е: архитектурные артефакты - это списки вещей, матрицы вещей и картинки вещей В чем рисовать элементы множества? Да в чем угодно: список, табличка, граф...

Мне этот подход не очень нравится. Я бы каждом элементу присвоил бы URI и бросил бы модель в web, а отношения сделал бы не бинарными, а N-арными, что упростило бы модель.
Но, архитекторы консервативны :-)

"Здравствуйте, дорогие участники проекта, сегодня я хотел бы рассказать, над чем вам всем придётся работать ближайшие месяцы. Но только сначала быстренько сбегайте, пожалуйства, выучите архимейт, это всего-то пару дней займёт" )

Тут все зависит от конкретики. Если команды все те же, то на уровне предприятия можно сделать политику. Если вы впервые видите людей, то можно легенду ту же писать. Всяко это понятнее простых квадратиков.
Я однажды на инициации проекта с заказчиком договорился о языке, им все очень понравилось. Там были архитекторы, руководители, программисты, админы.