Comments 10
Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:
Тут очень важно пояснить до какого размера компания должна вырасти чтобы весь этот зоопарк стал мало-мальски оправдан. А то чаще все эти игры в Кубернетесы и хайлоад начинают играть просто чтобы в них играть с важным видом (ну и в резюме записать).
Тут, мне кажется, никто не даст точного ответа - когда компания выросла и пора внедрять. Тут, скорее, нужен грамотный ИТ-управленец в бизнесе, который будет готов взять на себя ответственность и сказать - "Пора!"
У меня есть дополнительные пример - бизнес думает, что сейчас это модно и трендово внедрить Kubernetes и AI подходы, а у самих 3 сервера на Collocation и непонятные перспективы.
И да, очень много людей/безнеса делает Kubernetes ради Kubernetes. Согласен. Но сейчас уже меньше.
потом пришли:
облака;
Kubernetes;
распределенные системы;
DevOps;
GitOps;
микросервисы;
Они же не сами пришли. Кто-то их привел. Кто этот негодяй? И зачем?
Архитектор должен стоять на страже и не дать запороть продукт таким дебилизмом.
Задача архитектора обеспечить систему важными для неё архитектурными свойствами.
Всё. Больше он ничего не должен, остальное детали и следствия.
Их привел бизнес и ИТ директор - потому что модно, а архитектора у них еще нет. И только потом осознав, что у них бюджет на облака сливает половину выручки, они начинают думать - что нужно что-то делать. Ну и как раз, вдруг найдут эту статью и у них появится мысль - пора нанимать архитектора, без него не вывезем )))
как правильно пишет @Inecs, в подавляющем большинстве сначала разводят зоопарк, а потом уже приводят директора зоопарка) сталкиваюсь с этим нередко )
Логика карьерного роста поощряет такой дебилизм. Создание проблем и демонстративная ворьба с ними повышает ценность специалиста на рынке труда и для текущего работодателя.
Когда арх (да или кто-нибудь) говорит бизнесу - "нельзя" - обычно он почти сразу идет нахер.
Сколько раз пытался подстелить соломки, предупредить, ... тебя просто не слышат.
Тут тоже надо понимать, может цель этого бизнеса освоить и распилить выделенные бабки, а вы тут со своим "как правильно". И прямо это конечно же никто не скажет. Поэтому такой архитектор в первую очередь должен иметь очень развитый EQ чтобы без слов понимать что от него на самом деле хотят.
Кто говорит "нельзя", правильно идет нахер. Аргументировать нужно прогнозом последствий.
Как по мне, основная проблема роли архитектора, что он не является владельцем “ресурса”. Трудового в первую очередь. Поэтому у него есть большой риск скатиться в рисователя воздушных замков, “весёлые картинки” которого либо складываются в стопку в чулане. Второй вариант они просто рисуются по факту реализации и он чисто техпис. Держать архитектора в тонусе/контексте очень сложно, потому что его руководитель зачастую сам не в контексте и действует реактивно.
Поэтому во многих даже крупных компаниях стараются не использовать эту роль.
Архитекторы в ИТ — кто все эти люди на созвонах и почему без них современный бизнес начинает страдать