Как стать автором
Обновить

– А у нас нет мышей! – А мы заведём… Какая польза от архитектора решений

Время на прочтение8 мин
Количество просмотров12K
Всего голосов 18: ↑16 и ↓2+14
Комментарии13

Комментарии 13

Искрене возмущён заглавной картинкой этой статьи!
Ну какое отношение столь низкоразвитые животные как коты имеют к науке, образованию и архитектору решений?
Если уж так хотелось украсить статью картинкой животного то единственно верным был бы такой вариант:
image

А как же обезьянки?

Для любого начинающего свинолюба настольной книгой является Вербер "Отец наших отцов", где простым и доступным языком объяснено и почему во многих массовых религиях нельзя есть хрюш и причём здесь обезьянки!
Если коротко, то в наших далёких предках есть не только обезьянки но и… :)

За 20 лет в IT я видел всего двух толковых архитекторов. Работа с ними была просто песня. Все остальные это просто канцелярские крысы не понимающие в разработке примерно ничего. И я знаю насколько коллег которым такую горе-архитектуру приходилось править уже ближе к продакшену. Вот где ужас.

Я бы тоже расстроился на месте тех коллег, которым самим пришлось переделать всё, начиная с архитектуры, да еще и на препроде. Ошибиться может каждый, но не совсем понятно, почему запрос на изменение архитектуры не ушел обратно в архитекторов? Очень похоже на какой-то сбой в коммуникациях или неотлаженный процесс разработки. Это была разовая история или случалось постоянно?

PS: с толковыми людьми вообще приятно работать, а с толковыми архитекторами так вдвойне) надеюсь, они будут попадаться чаще
Ответ-то простой — дедлайны. Хоть тушкой, хоть чучелкой но деньги с заказчика взяты и проедены и надо показывать результат. Обычно на этом этапе на проект кидают тех кто может хотя бы как-то заставить дышать. Самая мякотка если до этого проект делали индусы.

Насчет отлаженности процесса тут существует несколько точек зрения. Часто с точки зрения руководства если деньги идут и большие факапы случаются редко — все построено правильно.
Дедлайны есть у всех, как и ограниченность стоимости (бюджет), и ограниченность содержания (скоуп проекта).

Дело скорее в управлении проектами, или даже в уровне зрелости организационного управления проектами. Чем выше уровень зрелости, тем более стабилен процесс достижения целей проектов. Может статься, что в компании из вашего примера и архитекторы-то на данном этапе не сильно нужны, а куда как важнее причесать сами процессы разработки и проектную деятельность в целом.
Отсутствие настоящих архитекторов на некоторых проектах объясняется просто — хороший архитектор это как минимум хороший разработчик, плюс ответственность не только за себя, плюс опыт, плюс софт скиллы. Таким образом вырисовывается оклад*2 а то и *3 от разработчика, а в противном случае выгоднее оставаться просто разработчиком, востребованность выше. Но для работодателя что архитектор, что кодер все на одно лицо.
Прежде чем будет повышение в финансовых компенсациях (если вообще будет), будущий архитектор должен прокачать свои хард и софт скиллы, это вы верно написали. Но вот с опытом может быть загвоздка — не во всякой компании есть подходящего уровня проекты, да ещё такие, на которых можно поучиться без особого ущерба для самой компании и её клиентов. А без практики архитектор как-то странно смотрится.
НЛО прилетело и опубликовало эту надпись здесь

Интересная статья, понятно описаны перспективы, развитие, значимость, важность и нужность архитектора в компании.
«архитектору решений надо быть готовым проконсультировать любых приходящих за советом и уточнениями – от бизнеса до эксплуатации» — даже если на коллегу напал тупняк, рассказать простым языком, помочь разобраться.

"ландшафт предприятия", "домены", "архитектурные артефакты"… — по уровню абстрактной воды статья зашкаливает за чуть менее чем 100%. Хотя наверное про такие вещи что-то конкретное и не напишешь.


Рассказали бы лучше как с этим в Yota. Есть ли в ней гениальные архитекторы, способные создать уникальную, подходящую именно для этой компании архитектуру, а не тупо скопировать хорошо зарекомендовавшие себя решения других компаний. Которые, кстати, у всех больших компаний создавались эволюционно, практически в стиле "фигак фигак и в продакшн", а не путем напряжения мозгов гениев с целью выяснить как же оно там будет через 10 лет в компании-то.


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


Руководителям компании людей, которые употребляют более трех абстрактных слов в одном предложении, надо уволять нафик, ничего кроме словестной водищи, разливающейся по документам в компании и интернетам, и бесполезных митингов такие люди не создают.

Привет, Илья.
Рад, что зашёл почитать и с прошедшей тебя денюхой)

Теперь по пунктам.
«ландшафт предприятия», «домены», «архитектурные артефакты»… — по уровню абстрактной воды статья зашкаливает за чуть менее чем 100%. Хотя наверное про такие вещи что-то конкретное и не напишешь.

Если есть спрос, будет и предложение. Возможно, действительно, имеет смысл написать отдельную статью (или даже цикл статей), подробно раскрывающую смысл упомянутых «абстрактных терминов» и вместе с ним красоту мира проектирования)
Пока же предлагаю посмотреть в сторону вводной статьи по UML. Там уже сейчас примеры архитектурных артефактов рассматриваются более конкретно.

Рассказали бы лучше как с этим в Yota. Есть ли в ней гениальные архитекторы, способные создать уникальную, подходящую именно для этой компании архитектуру, а не тупо скопировать хорошо зарекомендовавшие себя решения других компаний.

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

И есть ли у этих гениальных архитекторов какая-то ответственность, а не тупо как обычно «это все программисты виноваты», не смогли видите ли реализовать гениальность архитектуры.

Без ответственности никуда. Она обязательно присутствует на всех этапах процесса разработки. Вопрос в зоне ответственности — кто за что отвечает. И если системный архитектор видит, что в планируемом решении возникает избыточная сложность в его системе, он подсвечивает этот момент архитектору решений. И уже задача архитектора решений разделить сложность, уменьшить её до допустимого уровня, но при этом сохранить реализуемость самого решения в целом.

Руководителям компании людей, которые употребляют более трех абстрактных слов в одном предложении, надо уволять нафик, ничего кроме словестной водищи, разливающейся по документам в компании и интернетам, и бесполезных митингов такие люди не создают.

Не совсем понятно, к чему этот призыв — то ли общаться односложно, то ли не общаться вовсе. Ведь абстрактное мышление свойственно всем людям, а в мире IT (и программистам, в частности) и подавно.
Возможно, тут речь о чём-то наболевшем, когда спускают задачи без достаточно толковых объяснений? Если так, то может имеет смысл обратиться к своему руководителю и подсветить узкие места в коммуникациях? И может заведёте себе архитектора решений)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий