для меня сеньор включает в себя некоторую комбинацию из перков:
- имеет X лет опыта. X разнится от технологии к технологии
- может быть наставником/обучающим/ментором
- эксперт в стеке Y + 1
- может в одну каску реализовать целиком систему/подсистему, т.е. full life cycle development (от работы с требованиями до выведения системы из эксплуатации)
- не мыслит категориями плохое/хорошее решение. понимает что "плохое" решение, в глобальном смысле, может быть хорошим на коротком промежутке времени. хорошее решение - то, которое достигает поставленной цели. т.е.
- открытость к мнению отличному от своего
- работа с рисками
- ориентация на результат для бизнеса

Если очень по простому, то:
- junior решает только четко сформулированные задачи с заданным способом решения "сделай форму/сервис по подобию". Требует постоянного надзора и плотного присмотра.
- middle решает типовые задачи самостоятельно, понимает их и уточняет. Не требует присмотра.
- senior тот, кто может поставить задачи и присматривает за junior. Плюс имеет богатую экспертизу в решению стандартных и не очень стандартных задачах.

А так соглашусь, что четких критериев нет и все упирается в з.п.

ну вот для того что бы "ставить задачу" и нужны перки который @dreamore  упомянул

Слушайте, а зачем архитектору ИТ-решений знать чем мидлы у разработчиков отличаются от сеньоров?

думаю, что опять попутали системных- и ИТ-архитекторов

кстати одно из лучших определений на фоне количества сломанных об эту тему копий.

Я бы сказал, что ит архитектор включает в себя enterprise, solution и system в компаниях, которые пока не разделили их на уровне отдела кадров

Т.е. когда деления нет, но пишут в трудовой ит архитектор или архитектор ис

Но делать люди с одной записью в трудовой и в одной компании могут совершенно разные вещи

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

Ну как я понимаю тренд в осмыслен и позиции solution, это охват и сшивка зон enterprise и system.

Хотя тут надо сначала определится, что конкретно для вас значит ит архитектор

Потому, что он архитектор, а не проектировщик.

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

Я в который раз запуталась, чем архитектор-ИТ решений от системного отличается.

Да ничем, все зависит от ролей в проекте поставки решения.

Да, в каждом болоте свои лычки. Мне непонятно сейчас, как именно в _этом_))

Я знаю и другие варианты. Например, когда архитектор готовит решение: взять ли собственных разработчиков или позвать аутсорсеров, или взять что-то готовое к себе или по подписке; создавать ли новую команду или бросить задачу в "чёрную дыру" уже существующей команды к тем задачам, которые там уже болтаются несколько месяцев без движения. По поводу ответственности. Конечно архитектор отвечает и за поставку и за интеграцию между командами и за выбор технологий (который часто сделан не им, а разработчиками). В общем, с таким объемом ответственности, командой руководить - как-то перебор. Она либо самоорганизуется либо самоуничтожится. Архитектор то здесь причем?

Он им указывает светлый путь, а они идут либо туда, либо лесом?))

А зачем вообще разделение на мидлов и сеньоров?