Комментарии 38
Архитекты бывают разные: Enterprise, Solutions/Systems, Application/Software…
И если это Application/Software Architect, и он при этом не пишет регулярно код, то мне жалко команду, которая будет вынуждена реализовывать его идеи. Это я говорю как Application/Software Architect с 35 годами опыта: если бы я лет 20 назад перестал писать код, то моё сегодняшнее представление об имеющихся языках, технологиях, инструментах и их характеристиках было бы очень далеко от реальности, что неизбежно приводило бы к низкому качеству принимаемых мной решений и соответствующей реакцией разработчиков на мои требования и рекомендации. А, судя по статье, Вы описываете как раз такой тип архитекторов.
Чтобы решать все эти задачи, проектировать возможные решения и выбирать из них оптимальное, огромный опыт программирования не нужен.
Согласен, огромный - не нужен. Нужен регулярный. Плюс лично хоть немного но тоже регулярно работать с разными технологиями/инструментами, чтобы поддерживать актуальное представление о доступных возможностях. Потому что если архитект будет принимать решения только на основании прочитанных обзоров новых технологий/инструментов в интернете… ой.
На английском таких не пишущих код архитектов называют Ivory Tower Architect (хз как это будет на русском). Цитируя Фаулера:
A well-known architecture department anti-pattern is the “ivory tower”:
architects sit in the penthouse to define how developers should design
and build software, without developing any software themselves. Such a setup has one
cardinal flaw: it doesn't provide feedback to the architects as to the effectiveness
nor the cost of their decisions. Worse yet: some architects quite enjoy themselves
not having to deal with those consequences.
https://habr.com/ru/companies/wunderfund/articles/755890/
Там это переводится как «архитектор в башне из слоновой кости».
Это буквальный перевод, он не очень подходит - у нас не распространена идиома "башня из слоновой кости" и связанная с ней история. Лет 20 назад таких архитекторов на русском называли "облачный архитектор", намекая на то, что он летает в облаках. Но потом появились реальные облака, и для них появились свои архитекторы, и "облачный архитектор" начало означать совсем другое.
У нас роль Application/Software Architect выполняют разработчики. И, конечно, они пишут код. Статья в большей степени о Solutions/SystemsArchitect.
Поддерживаю, для вашего уровня обязательно. Я работаю уровнем выше и уже не пишу давно (хотя хочется) :(
Вот прям в точку. Можно не писать код, но знать как он пишется обязан
А какой у вас бэкграунд? Ну что нужно уметь/закончить,/ кем работать чтоб стать системным архитектором?
Доброго дня!
Образование: «Программное обеспечение вычислительной техники и автоматизированных систем», г. Оренбург.
Реляционные и документориентированные СУБД от запросов до пакетов (Orcle/MS SQL/LotusDomino).
Программирование: от бека до фронта, интеграции. Языки: PHP, JavaScript, C#, в том числе разработка аддонов под продукты MS
Несколько лет управления ИТ-отделом, где удалось создать две команды разработки с нуля и выполнить несколько проектов. В последнее время — архитектура.
Как раз таки опыт регулярной разработки нужно иметь, нередко бывают случаи что архитектор летает в своих облаках, а на земле его решения не то что бесполезны, но иногда и вредны ))
Как в первом комментарии отмечено - архитекторы бывают разными. Разные уровни ответственности - разные архитекторы. От отдельных сервисов/приложений - до уровня корпоративной архитектуры с тысячами систем в компании.
В статье лишь один аспект - участие в конкретной проектной команде по реализации конкретной задачи.
«Расспрашивает об уже имеющихся функциях системы» — и не просто расспрашивает, а бывает, что и смотрит код, чтобы понять, какой в итоге алгоритм реализован. Часто это необходимо, когда нужно определить способ устранения ошибки или причину ошибки в самом реализованном алгоритме. Расспрашивать о функциональности тоже приходится. Особенно, если система очень большая, над ней работают несколько команд, и на старте работ нет аналитика. Он (аналитик) потом обязательно появится и займется описанием и сбором требований для новых возможностей системы. Ему тоже важно знать, что уже есть в системе, и он об этом расскажет. Это и есть плюсы командной работы.
«Описывает требования, которые должен реализовать разработчик» — это тоже важно описать. Здесь важен уровень детализации и количество команд, которые участвуют в реализации решения. Возможно, при построении архитектуры одной маленькой системы, не связанной с другими системами, сами разработчики могут и знать, что уже есть в системе. Разобраться, кому из них и что запрограммировать. Но когда в решении участвует много команд, когда есть интеграции, очень важно, чтобы хотя бы кто-то один видел решение целиком от начала и до конца. И тогда условно, команда, которая «пуговицы очень хорошо пришивает», от архитектора получит информацию, где именно пришить эти пуговицы. При этом ему не нужно объяснять, как их пришивать. Команда итак хорошо умеет делать свою работу. Команда, которая «делает петли», по задаче архитектора, сделает их именно там, где потом ровным стройным рядом можно будет застегнуть пуговицы.
Света прочитал. Доступно написано. Боль понятна. Было тоже самое :-) И нет каких то простых и понятных шагов, чтобы внедрить практику в команду, в проект. Все индивидуально.
Архитектор приложений должен обладать правом авторского контроля. Если его голос лишь совещательный, то большая система быстро превращается в зоопарк.
Так-то да, но при этом он должен быть в состоянии убедить разработчиков что предложенная им архитектура/решения имеют смысл и сделают проект лучше. Потому что если разработчики не разделяют предложенные идеи, то их внедрение будет осознанно или нечаянно саботироваться. Просто потому, что без понимания что они делают они будут писать фигню, регулярно нарушая архитектуру и даже не понимая, что они что-то нарушили. А ревьювить 100% кода у архитекта времени обычно нет.
А вот когда хотя бы большую часть команды удалось убедить и они сами хотят делать именно то, что предложил архитект, то оставшимся одному-двум особо упрямым можно и приказать - сильно налажать им не позволят остальные члены команды.
Это правда. Если программер не понимает - зачем это всё, то сделает плохо. Мой коммент вызван тем, что я видел варианты, когда архитектор не имел никакого веса, и это поддерживалось начальством. Печальное зрелище.
Архитектор в первую очередь решает задачи, которые до этого не имели решения, сталкивается с тем, с чем другие не сталкивались, что не загуглишь, не подсмотришь на stackoverflow, и ещё подумаешь как спросить у chatgpt) Лучшее архитектурное решение, это совокупность компромиссов, где каждый из которых несёт наименьший вред принимаемому архитектурному решению. Описанный вами архитектор, без контекста его бекграунда выглядит как старший аналитик, которого просто назначили. Архитектор ещё должен контролировать выполнение архитектурных требований, а наиболее сложные и ответственные участки проекта писать сам. Архитектор который не пишет код - аналитик.
Вот читаю я все эти ситуации и мне кажется, что тут что-то пошло не туда в мире IT. Я вообще не понимаю, что значит Инженер не понимает зачем нужен Архитектор и саботирует его задачи? Обычно за такое делают выговор, а если не понятно увольняют.
Тут ровно 2 проблемы:
Это не задача Архитектора - доказывать Инженерам, что он нужен. Если он есть на проекте, значит бизнес принял такое решение, а значит и мотивы есть и есть чем объяснить это команде.
Если инженер не знает зачем нужен архитектор, значит он банально не компетентен. Наглядно ему это объяснить можно поставив одну из архитекторских задач по обоснованию и выбору БД, масштабируемости продукта или задач по оптимизации производительности. И потом просто показав как нужно решать такие задачи, а еще и не просто решать, но и обосновывать чем данный выбор лучше альтернатив.
Потому что это всё выглядит как непонятная возня вокруг девелоперов, чтобы они не дай Бог не обиделись. Разработка продукта - это не игрушки в первую очередь, хотя да этот аспект привносит хайп, веселье и улучшает атмосферу в коллективе. Но это не перво цель. Исходная причина - это зарабатывание денег компанией, для этого нужно всем работать в команде, уважать друг друга, и стараться решать задачи максимально приблеженно к срокам и заданию.
Это не ПЭТ-проект, не обучение отдельного инженера и не развлечение. Это - Работа. Поэтому задачи - это цели компании. Не согласен с задачей - спрашивай, обсуждай, пытайся разобраться. А не сиди себе тихонько в уголку и саботируй всю работу.
Это проблема не только архитекторов. Я как QA Engineer тоже с таким постоянно сталкиваюсь, что почему-то разработчики считают, что им нужно доказывать и учить, зачем нужно писать юнит-тесты, использовать статические инструменты анализа, документировать интерфейсы и думать что именно в них должно быть и как, и т.д.
Самый эпик который мне приходилось слышать от Principal Software Develooment Engineer:
"Почему это наш код, должен соответствовать задокументированной Архитектуре?"
Я даже не нашёлся, что ответить. Но через два месяца всё было отрефакторено согласно архитектуре.
Выводы:
Software Develipment Engineer, работает над очень маленьким кусочком продукта, он даже представить себе не может, на сколько вся система сложна в целом и сколько усилий требуется на её согласованную, эффективную и бесперебойную работу. В силу ограниченности этого, он физически не может принимать верные архитектурные решения, просто из-за отсутствия информации для видения полноты картины.
Это нормально, Архитекторы работают вширь продукта, разработчики же сосредоточены на работе вглубь отдельных частей. Они могут разбираться в моделях за которые ответственны гораздо лучше архитектора, но они никогда не будут лучше понимать поведение продукта в целом. Если это происходит, значит у человека просто не верный титул в подписи почты.
Результат работы Архитектора - архитектурные документы в различных их реализациях. Результат работы Инженера - это Дизайн документы отдельных модулей, их реализация в коде и юнит тесты на данный код в соответствии с дизайн документом.
Ну и естественно должно быть traceability между modules, units, software items в архитектуре с дизайн документами раскрывающими данный сущности.
Эт вы некомпетенты со своим "всех уволить"
Было желание ответить по сути, но… у Вас слишком наивно-идеализированное представление о том, как всё (должно быть) устроено. В реальности так не бывает.
Один только маленький факт, который рушит все Ваши идеи: документация всегда отстаёт от реализации. Т.е. по сути - дока врёт, и приводить реализацию в 100% соответствие доке - плохая идея. Поэтому делать "по доке" можно только в самом начале разработки, когда дока ещё опережает реализацию (но это быстро пройдёт). И никакие процессы, которые бы обеспечивали актуальность документации, в реальной жизни не работают. Потому что выбор получается между актуальной документацией и рабочим продуктом - и бизнес всегда выбирает продукт, а не документацию. Возможно где-то в enterprise, где лично я не работал, и где очень много лишних времени, денег и бюрократии, получается поддерживать актуальность документации… но я лично сильно в этом сомневаюсь.
Мне вот довелось поработать как в стартапах на 5 человек, так и в медицинском энтерпрайзе по роботизированной хирургии, где одних SDET было 120 человек. А еще сверху отдельный департамент QA, который следил за работой как разработчиков, так и тестировщиков, чтобы всё было по ISO 13485 и ISO 62304. Так что всё бывает.
Просто невозможно сделать медицинскую установку, автомобиль или самолёт по тем же процессным подходам, архитектурным паттернам и уровню документации как очередной веб- магазин или онлайн-казино.
Банально не пройдёте сертификацию и не сможете ничего продать. Ну в крайнем случае выйдет как у Боинга, всех обмануть пока 2 самолёта не упадёт, а теперь бизнес активно загибается.
Так что не торопитесь утверждать, что так не бывает, если конкретно у вас небыло такого опыта.
Если у вас нет актуальной документации - значит у вас нет тестирования, а то что есть - это полная профанация. Потому как тестирование, это сверка документации с реальным поведением продукта. Нет документации - не с чем сравнивать, продукт живёт своей жизнью и о качестве даже бесполезно поднимать разговор. Таким продуктам не нужны ни Архитекторы, ни Тестировщики. Только вот реакция пользователей потом вполне ожидаема и предсказуема.
Потому как тестирование, это сверка документации с реальным поведением продукта.
Документация бывает разная. Описание требуемого внешнего поведения приложения для тестировщиков может и должно быть актуальным, в отличие от документации описывающей реализацию (архитектуру, структуру проекта, используемые алгоритмы, etc.).
Что до прохождения сертификации, то есть большая разница между требованиями "документация должна способствовать прохождению сертификации" и "документация должна полностью соответствовать текущей реализации".
При этом надо заметить, что упомянутые Вами "процессные подходы" для медицины, автомобилей и самолётов никак не спасают ни от убивающих людей вакцин, ни от взрывающихся авто, ни от падающих самолётов. Знаете почему? Потому что всё это делают люди, а людям свойственно ошибаться даже непреднамеренно (опустим ситуации когда в некачественном результате есть явная заинтересованность). И никакое тестирование, сертификации и внешний аудит не дают совершенно никаких гарантий. Хороший пример: Почти во всех реализациях двоичного поиска и сортировки слиянием есть ошибка. Так что по факту всё это вопрос баланса - рисков и ресурсов. И да, баланс для стартапа отличается от самолётостроения. Но идеальной документации нет нигде, где кроме документации нужен ещё и работающий продукт.
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве.
Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов.
Если речь касается Энтерпрайза - всё просто. Открываем нужный ISO и читаем. Там всё прописано с полной инструкцией как провести приоритезацию модулей/юнитов, какой уровень документации какому модулю необходим. Но для это сначала нужна архитектура, где будет расписано, где какой модуль, сколько уровней интеграции, есть ли зависимость на hardware, third party, etc.
Нет архитектуры, нет требований, нет описания интерфейсов, так и говорить не о чем. Предел возможностей на таком проекте - это юнит тестирование.
Ну так и не надо втирать людям, которые делают очередной интернет магазин, что им жутко нужен архитектор)).
Если ты такой умный архитектор можно было сообразить такую простую вещь?
А кто втирал- то?
Я как-раз обратное предлагал. В весьма доходчивой форме.
А кто писал про увольнять инженеров, которые не понимают необходимость архитекторов? Если в 95 процентах случаев не нужны?
И не доходчиво, а нечитаемыми нудными лонгридами, и вы забавно переобуваясь на лету) Хорошая должность наверно?)
Зачем Вы читаете, если Вам это тяжело?
Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать?
И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять.
Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен?
Только долго ли на такое будут закрывать глаза?
Ахах, я не читал, дальше двух предложений, конечно.
Вакансии на ХХ гляньте. Там всё 99% корпоративные формошлепы.
Да программист возьмёт и сделает, и спросит, а зачем нам этот архитектор нужен, я и сам всё сделал. Вернее не спросит, тк давно привык, что сверху бродят те, кто прогать не умеют, но языком бла-бла.
Тоже с таким столкнулся. Работаю БА, пользователи все воют от токсика девелопера. Он уже пару раз приложился нецензурной лексикой. Но его руководство оберегают его, так коду уже больше 10 лет. И кроме него никто не помнит что там и как. Задачи решает как ему удобно. Приходится по два раза описывать, как хотел пользователь и как он реализовал. На откровенные баги требует заводить задачи на девелоп. Со стороны у него все идеально. Взять кого-то чтобы он научил не получится. Нормальный человек сбежит очень быстро.
Сорян, но по описанию "системный архитектор" это очередной менеджер при начальстве. Либо вы умеете проектировать ИТ архитектуру через паттерны проектирования и тд либо вы "составить список требований"
если компания держит такого архитектора который не пишет код, а лишь раздаёт указания по его реализации - значит, явно обходятся одними мидлами и джуниорами.
сеньорам, конечно, тут ловить нечего... чтоб кто-то решал на таком уровне как че внедрять и просто давал тебе на реализацию методы, классы и подобное - это как студентам на практике решать задачки препода. несерьезно и неинтересно. точнее, это норм на определённом этапе опыта. но когда ты уже сам начинаешь рубить архитектурную фишку и способен от а до я эффективно реализовать бизнес-задачу потому что уже прокачался - ты сам себе архитектор. и это правильно. никто лучше не сделает. техлид только должен дирижировать всем процессом и командами, задавая или проверяя паттерны и технологии, чтоб увязать это все в единый продукт. и более никто не нужен. ну и тимлиды понятно. имхо.
Четвёртый пункт некорректен. Если посмотрите вакансии для системных аналитиков, то увидите, что знание типов архитектуры, умение спроектировать API и опыт работы с брокерами сообщений требуются с уровня мидла, а понимание нефункциональных требований — с джуна. Всё, что Вы описали в четвёртом пункте для Архитектора справедливо и для системного аналитика.
Вероятно, Вы имели ввиду бизнес/продуктового аналитика.
Чем занимается IT-архитектор: фантазии коллег и суровая реальность