Comments 19
Как по мне, архитекторы не нужны. У нас архитектуру сервисов пишут те же инженеры, которые будут ее имплементировать, вне зависимости от грейда - и это замечательно работает.
Более того, выскажу еще более непопулярное мнение - все это вертикальное разделение труда - на программистов, тестеров, админов, архитектов - не нужно и вредит.
Ну вот посмотрите, программист - он инженер, и тестировщик- он инженер. Архитектор - он тоже инженер. Когда у меня спрашивают, чем я занимаюсь - я гордо отвечаю что я инженер. Но термин 'архитектор' - он явно выделяет чем инженер занимается.
А будет ли писать архитектуру инженер который будет её имплементировать, или специально выделенный архитектор - уже зависит от масштаба компании, объёма задачи и вообще количества задач. Потому что программист все-таки должен программировать, а тестировщик тестировать, хотя оба умеют и то и другое.
Разделение труда должно быть.
Вертикальное разделение труда ведет к майндсету «к пуговицам претензии есть?». Архитектор плюет на всех из своей башни из слоновой кости, программисты не хотят думать о том, что когда приложение крашится из-за недоступной базы - это не очень удобно и так далее.
На моем опыте, вертикальный овнершип работал и на маленьком, и на большом масштабе. Конечно, требования к инженеру получаются выше, но и растет он быстрее.
Аналогично про универсального инженера и отсутствие выделенных ролей, реален такой диалог:
-нам нужна локументация по проекту;
-мне некогда, я программирую и тестирую.
И при выделении ролей речь в первую очередь идёт не про выстраивание вертикали, а про распределение обязанностей при совместной работе, командной работе.
Возможно, что при назначении инженеру задач и программиста, и аналитика, и тестировщика, и архитектора, кто-то преследует иные цели, такие как быстрый рост команды, или экономия бюджета, или отсутствие ресурсов.
Что значит «некогда»? Эти процессы не происходят одновременно, проектная документация предшествует имплементации, а пользовательская - пишется после.
И если это делается одним человеком или командой, меньше вероятность того что документация разойдется с реальностью, кстати
Ну а когда он все будет делать? Сегодня он спрограммировал, приступил к тестированию. К нему приходят с новой задачей, а он нашёл ошибки при тестировании, у него откладывается подготовка документации и ввод в эксплуатацию. А тут ещё какие-то дедлайны придумали. А тут следующая задача пришла ещё. Конечно при таком подходе инженер многому научится, особенно планированию своего времени, а ещё тому что неплохо было бы чтобы он не один все делал, а с коллективом.
Как говорил один мой знакомый преподаватель, конечно я умею все это делать, но в аутках только 24 часа, а мне бы ещё хотелось поспать!
Так что разделение труда придумали не зря
Что значит «приходят»? Работа включает в себя не только имплементацию, но и проектирование, тестирование и прочие доки. С тем же самым успехом можно аппелировать к тому, что люди и дедлайны приходят прям во время программирования, да.
И никто ж не говорит что над каждой задачей работает строго по одному инженеру, все точно так же работают командами, просто модель владения сервисами вертикальная, а не горизонтальная.
Всего две вещи.
Первая про вертикальную иерархию. Её не придумали люди в целом и менеджеры или архитекторы конкретно. Иерархии предусмотрены природой в пищевых цепочках, социальном устройстве стай и т.д.
Вторая про разделение труда. Крупнейшие промышленные корпорации имеют сложнейшую структуру с максимальной детализацией и жёстким регламентом. Ваш смартфон собран не одним инженером, к нему приложили руку десятки различных подразделений и внешних подрядчиков.
Когда кто-то говорит "мы справляемся без менеджмента" или "У нас в команде полная взаимозаменяемость", для меня это вернейший признак уровня хобби выходного дня или гаражной разработки. Насколько это релевантно в контексте размышлений о роли архитектора?
Ну, мой опыт относится к компаниям масштаба нескольких тысяч инженеров (не всего сотрудников, а инженеров). Это еще гаражная разработка?
Менеджмент тут совершенно не при чем, я говорил исключительно про техническую часть работы. Все это разделение - это кмк вредная сверхспециализация, которая мешает, во-первых, холистическому, системному взгляду на продукт, а во-вторых, размывает овнершип.
Я работал в обеих моделях и по разные стороны баррикад (и кодером, и админом), и вот такая модель, когда человек или команда владеет всем жизненным циклом своего продукта, от проектирования до эксплуатации - на мой взгляд, наиболее здоровая и продуктивная. По сути, на это можно даже с определенной натяжкой смотреть как продолжение идей (оригинального, а не того, во что это в итоге вылилось) девопса и прочих «-опсов», когда стены между отделами совсем разрушились и все смешались.
Интересно, какой процент программистов может между делом active directory поадминить, ну или маршрутизацию правильно прописать?
• корпоративные архитекторы («enterprise»),
Как по мне, так корпоративный архитектор, т.е. тот который про Enterprise Architecture, вообще может не знать про существование ИТ, поэтому вопрос:
Gregor Hohpe задается в статье: «Должен ли архитектор программировать?»
не имеет смысла. Или тогда нужно всегда и везде уточнять, что речь не про архитектора предприятия, а про ИТ-архитектора предприятия.
Простая Enterprise Architecture. Архитектура компании садоводов
EA как минимум общаются с управлением ИТ, знают какие системы есть вообще и эксплуатируются, а также знают сколько стоит внедрение той или иной системы. Т.е. тоже работают непосредственно с ИТ, но больше с бизнес-уклоном.
А про уточнение про какой вид архитектора идёт речь - это да
EA как минимум общаются с управлением ИТ, знают какие системы есть вообще и эксплуатируются,
На предприятии может быть ровно нуль из ИТ, см. мою ссылку выше. ЕА для таких предприятий (которые вообще без ИТ) концептуально мало чем будет отличаться от предприятий с ИТ.
Кроме того: информационная система предприятия – это не только ИТ-технологии в привычном понимании, но и вся (не только ИТ-шная) информационная составляющая предприятия, в том числе, которая (информация) существует исключительно в виде бумажных документов и циркулирует в неавтоматизированных процессах.
конечно же, зачем небольшому ООО "Какая-то фирма" нужен EA. То, что уже сейчас становится видно на отечественном рынке, это то что EA нужен крупным организациям, имеющим большой реестр ИТ, бизнес-процессов, если говорить еще более приближенно - то это компании, которые строят свои экосистемы, возможно те, которые переходят с ПО западных вендоров на отечественные разработки.
Если честно, что значит "нуль из ИТ" не очень понял, как вообще такое возможно, что это за предприятия которые вручную работают в такое время, как они еще существуют на рынке (если, конечно, это коммерческие организации подразумевались в примере).
конечно же, зачем небольшому ООО "Какая-то фирма" нужен EA. То, что уже сейчас становится видно на отечественном рынке, это то что EA нужен крупным организациям,
Основная мысль, которую я пытаюсь донести в т.ч. в Простая Enterprise Architecture. Архитектура компании садоводов - чтобы научиться делать что-то сложное (ЕА крупным организациям) нужно вначале научиться делать простые вещи, например, ЕА для простых предприятий. При этом, наличие в компании ИТ не влияет на общий подход (концепцию архитектуры, EA framework) к построению ЕА.
И ещё добавлю, что и книгу читал, и рассуждения строю с точки зрения Solution. Именно в нем мне видится определённая романтика ИТ
Архитектор в ИТ — он как философ. Все вопросы и решения может подвергнуть сомнению