Комментарии 53
НЛО прилетело и опубликовало эту надпись здесь
Цикл статей — хорошая идея. Напишите подробнее о чем бы Вы хотели бы услышать?
НЛО прилетело и опубликовало эту надпись здесь
Самые ценные знания – это знания, которые ты получаешь на практике. В теории все хорошо работает, а на практике все далеко не так. Практический опыт дает незаменимые знания.
Основная сложность состоит в том, что нужно предвидеть, с какими трудностями можно столкнуться на всех этапах выполнения проекта. Причем не только в своей области, но и смежных с ней.
Например при построении ЦОД такими областями являются строительство и инженерные системы.
Эти навыки приходят только со временем и не существует универсальной литературы.
На каждом этапе свои нюансы. На начальном этапе сложность в получении информации и ее обработке. Полное понимание приходит только со временем. Это касается не только технической информации, но знаний об устройстве бизнеса.
Основная сложность состоит в том, что нужно предвидеть, с какими трудностями можно столкнуться на всех этапах выполнения проекта. Причем не только в своей области, но и смежных с ней.
Например при построении ЦОД такими областями являются строительство и инженерные системы.
Эти навыки приходят только со временем и не существует универсальной литературы.
На каждом этапе свои нюансы. На начальном этапе сложность в получении информации и ее обработке. Полное понимание приходит только со временем. Это касается не только технической информации, но знаний об устройстве бизнеса.
НЛО прилетело и опубликовало эту надпись здесь
Например при построении ЦОД такими областями являются строительство и инженерные системы.
Существуют типовые инженерные и строительные проекты (с богатой историей), на которые можно опираться в процессе обучения и некоторого планирования.
Кроме того, не стоит без острой необходимости работать с теми строительными компаниями, которые ранее никогда не строили ЦОД-ы — у строивших и портфолио есть и опыт прогулок по граблям и понимание, что такое ЦОД, который хотят от них получить.
А огласите весь список ценных знаний в закрытом доступе. Мы то о них, видимо, не в знаем :)
На лицо незнание матчасти, где-то в статье речь идет про СТИ, а где-то про архитектуру приложений:
«Ожидание: программист легко может переквалифицироваться в ИТ-архитектора.
Реальность: у системного инженера больше шансов начать новую карьеру.»
Архитектор например Java и Архитектор по инфраструктруе (СТИ) — две совершенно разные области в IT. И если Java программист захочет стать архитектором по инфраструктуре, ему придется изучать и сети и серверное оборудование и СХД и тд. и не важно какие информационные системы он «писал» — учить все равно придется.
«Ожидание: программист легко может переквалифицироваться в ИТ-архитектора.
Реальность: у системного инженера больше шансов начать новую карьеру.»
Архитектор например Java и Архитектор по инфраструктруе (СТИ) — две совершенно разные области в IT. И если Java программист захочет стать архитектором по инфраструктуре, ему придется изучать и сети и серверное оборудование и СХД и тд. и не важно какие информационные системы он «писал» — учить все равно придется.
Архитектура приложений и архитектура информационных систем – это разные вещи. Архитектура информационной системы — это совокупность софтверной и железячной архитектур. Именно поэтому я подчеркиваю: чтобы стать архитектором информационных систем, программисту (который наверняка имеет представление об архитектуре приложений) нужно получить знания по закономерностям построения архитектуры в «железной» части информационных систем. Сюда входит изучение процессов построения вычислительных сетей, сетей передачи данных и архитектуре инфраструктурного ПО — такого, как виртуализация, системы резервного копирования, системы мониторинга и др.
У меня сложилось впечатление, что в статье описана специальность ИТ-архитектора не в широком смысле, а в конкретной компании/команде. В одном человеке, Анне, была замешана не только роль архитектора, но и тимлида, менеджера продукта, проекта, бизнес/системного аналитика и тд. И история получилась соответствующая.
НЛО прилетело и опубликовало эту надпись здесь
А я ничего не имею против. Сам по табелю системный аналитик, а ролей выполняю вокруг огого ;)
Просто зайдет в статью человек «далекий» от ИТ и кааак прочитает, что оказывается ИТ-Архитектор должен с бизнесом на его языке говорить.
Просто зайдет в статью человек «далекий» от ИТ и кааак прочитает, что оказывается ИТ-Архитектор должен с бизнесом на его языке говорить.
НЛО прилетело и опубликовало эту надпись здесь
По мне не надо «травмировать» архитектора общением с бизнесом (как и программиста, тестировщика и ряд других «внутренних» специалистов). Для этого есть закаленные аналитики/менеджера, они узнают и спокойно донесут концентрат знаний до архитектора. А архитектор в случае чего попросит уточнений у аналитика, который снова спокойно выудит их у бизнеса/его окружения/других источников. Случай, когда архитектор не смог получить от аналитика ответы или сомневается в них, да так, что пошел сам к бизнесу — по мне не нормальный.
НЛО прилетело и опубликовало эту надпись здесь
Интересно. А вот как по мне — так это абсолютно нормальный случай. Архитектор и аналитик находятся на одном уровне коммуникаций, просто аналитик выясняет функциональные требования системы, а архитектор — нефункциональные.
Конечно в какой-то конкретной команде всю коммуникацию можно держать через аналитиков. Но с таким же успехом тогда её можно построить и через архитектора. Это порочная практика в обоих случаях.
Ещё один момент, почему архитектор должен понимать язык бизнеса — архитектор участвует в пресейлах. А это значит, что надо уметь хорошо молоть языком и диаграммы рисовать не только в UML и с представителями заказчика говорить на одном языке.
Конечно в какой-то конкретной команде всю коммуникацию можно держать через аналитиков. Но с таким же успехом тогда её можно построить и через архитектора. Это порочная практика в обоих случаях.
Ещё один момент, почему архитектор должен понимать язык бизнеса — архитектор участвует в пресейлах. А это значит, что надо уметь хорошо молоть языком и диаграммы рисовать не только в UML и с представителями заказчика говорить на одном языке.
Аналитик должен выяснить и функциональные, и нефункциональные требования. Грубо, аналитик формирует все требования к системе (тактико-техническое задание), на основании которого архитектор формирует один или несколько вариантов технического задания, возможно через стадию разработки одной или нескольких концепций.
Архитектор иногда участвует в пресейлах, если заказчик или собственные сейлзы на этом настаивают. Например, если заказчик хочет непосредственно с технарем поговорить, или если сейлзы сыпятся на технических деталях.
Архитектор иногда участвует в пресейлах, если заказчик или собственные сейлзы на этом настаивают. Например, если заказчик хочет непосредственно с технарем поговорить, или если сейлзы сыпятся на технических деталях.
ИТ-архитектор департамента развития корпоративных продаж.
Другое название — консультант/менеджер по продажам, скорее всего продукции определённого вендора.
Держа в голове архитектуру проекта, он ставит задачи конкретным специалистам, следит за качеством и сроками исполнения тех или иных работ и в конечном счете отвечает за то, чтобы вся команда выполнила задачу, поставленную бизнес-заказчиком.
Это функции менеджера проекта (ПМ). ПМ работает на основании «рабочего плана-графика», в котором описана последовательность конкретных задач. Список задач формируется на основании требований заказчика. Для каждой задачи определяются сроки и необходимые ресурсы. В разработке технической части «рабочего плана-графика» обычно принимает участие ИТ-архитектор.
При этом ИТ-архитектор должен очень хорошо уметь говорить с бизнесом на его языке.
Жаль что вы обходитесь ещё и без бизнес-аналитика.
ИМХО: функцию ИТ-архитектора кратко можно сформулировать примерно так: На основании существующей инфраструктуры и требований заказчика, разработать технологический стек проекта(проектов). Иногда это ещё назывется — разработать ТЗ.
Другое название — консультант/менеджер по продажам, скорее всего продукции определённого вендора.
Нет. Я работаю со всеми вендорами. Выбор вендора зависит от определенных условий. В одном заказчике это корпоративный стандарт, в другом важную роль играет цена, и т.д. Консультант и менеджер по продажам выполняет совершенно другие функции, нежели ИТ-архитектор.
Это функции менеджера проекта (ПМ). ПМ работает на основании «рабочего плана-графика», в котором описана последовательность конкретных задач. Список задач формируется на основании требований заказчика. Для каждой задачи определяются сроки и необходимые ресурсы. В разработке технической части «рабочего плана-графика» обычно принимает участие ИТ-архитектор.
Не соглашусь. По-вашему, менеджер проекта может оценить качество выполненной задачи? Он может оценить, насколько корректно составлена спецификация оборудования? Или, например, понять, все ли лицензии учтены и все ли трансиверы добавлены?
ИТ-архитектор не должен выполнять роль ПМ, но он должен обладать навыками и умениями этой должности.
ИМХО: функцию ИТ-архитектора кратко можно сформулировать примерно так: На основании существующей инфраструктуры и требований заказчика, разработать технологический стек проекта(проектов). Иногда это ещё называется — разработать ТЗ.
В качестве ответа приведу пример. Заказчик решил построить отказоустойчивый ЦОД. Архитектор собирает список сервисов, под эти сервисы пишутся требования к серверам, СХД и другому оборудованию. Далее проектируется сеть и способы обеспечения отказоустойчивости для каждого сервиса. После согласования с заказчиком архитектуры архитектор передает требования пресейлам по каждому направлению и получает от них спецификации. И только потом пишется ТЗ. Все зависит от масштабов проекта. Вы описали частный случай.
ИТ-архитектора, работу которого вы описали в статье, по-другому можно назвать «эникейщиком».
В организации должны быть (крайне желательно) должностные инструкции, в которых описываются функции и обязанности, которые должен выполнять человек, назначенный на определённую должность или проектную роль.
Конечно, в реальном проекте, ИТ-архитектор может выполнять много несвойственных ему задач. Но, при этом, он должен хорошо понимать, что относится к его прямым обязанностям, а что к функциям тех проектных ролей, которые он замещает.
Зачем это надо (это же так формально и скучно)? Хотя-бы для того, чтобы аргументированно ставить впрос об открытии новых вакансий и оптимизации своего рабочего времени.
Вопрос — должностная инструкция ИТ-архитектора в вашей организации — она вообще есть (в виде утверждённого документа)? вы с ней ознакомлены?
В организации должны быть (крайне желательно) должностные инструкции, в которых описываются функции и обязанности, которые должен выполнять человек, назначенный на определённую должность или проектную роль.
Конечно, в реальном проекте, ИТ-архитектор может выполнять много несвойственных ему задач. Но, при этом, он должен хорошо понимать, что относится к его прямым обязанностям, а что к функциям тех проектных ролей, которые он замещает.
Зачем это надо (это же так формально и скучно)? Хотя-бы для того, чтобы аргументированно ставить впрос об открытии новых вакансий и оптимизации своего рабочего времени.
Вопрос — должностная инструкция ИТ-архитектора в вашей организации — она вообще есть (в виде утверждённого документа)? вы с ней ознакомлены?
Я сам работал ИТ-архитектором и как ни странно все именно так — надо знать ИТ технологии, чтобы разговаривать с инженерами на их языке, а иногда и руками, надо знать людей и технологии менежмента, чтобы убеждать людей и учитывать требования бизнеса, надо много заниматься документацией. Можно конечно распределить обязанности, но в итоге за все вместе несет ответственность именно ИТ-архитектор, именно он делает сборку и ведет все это вместе. Конечно если проект большой, может быть более четкое распределение ролей, а может и быть несколько архитекторов. Еще прекрасно известно что в теории и на западе например именно так и происходит, но в реалиях нашей страны, приходится делать все. И кстати так даже интересней так как одно и то же занятие надоедает. Особенно например только пилить документацию :)
Softliner, а вы какой архитектор soft или hard, или hard && soft?
Меня зовут Анна Лисовская, я ИТ-архитектор
Требую фото! :)
No photo, no video! :)
> Требую фото! :)
GreenStore, это здорово, что Вы зашли на наш сайт и разместили тут фото наших сотрудниц, но среди них нет фото Анны :)
Вы с трудом ладите с «Пауэр Поинтом» и не слишком в восторге от того, что вам нужно выступать перед клиентами.
Кто-то из специалистов разъяснит мне, в чем сакральная сущность навыков PowerPoint и презентаций для архитектора?
НЛО прилетело и опубликовало эту надпись здесь
Если архитектор не может доходчиво и понятно объяснить сложное, не важно кому, СД или разрабам/админам, то его карьера будет, возможно, яркой, но не долгой.
Представьте строительного архитектора, которые заикаясь рассказывает про свою задумку строительства условного моста или высотки.
Представьте строительного архитектора, которые заикаясь рассказывает про свою задумку строительства условного моста или высотки.
Не надо путать «объяснить» и «продать».
Судя по попыткам объяснить мне нечто странное ни у кого из поясняющих не возникло критического осмысления того самого «списка необходимых навыков».
Презентации, умение подать себя и свою мысль, умение отвечать за других это отлично…
Но разве это ключевые навыки без которых ИТ-архитектор немыслим?
Есть условия необходимые и достаточные.
Так вот как минимум половина из того списка не относится ни к необходимым, ни к достаточным.
Презентации, умение подать себя и свою мысль, умение отвечать за других это отлично…
Но разве это ключевые навыки без которых ИТ-архитектор немыслим?
Есть условия необходимые и достаточные.
Так вот как минимум половина из того списка не относится ни к необходимым, ни к достаточным.
Забудьте про ИТ. Представьте, вы градоначальник. Вам нужно построить стадион, или нетривиальную развязку. И вот вам представляют проект, и Архитектор что-то бубнит себе под нос, показывает разные умные, но совершенно непонятные схемы.
Может он и хороший Архитектор чисто с технической стороны, но вы то не строитель, и вам умные схемы и бубнеж не нужны.
Да, умение понятно объяснять сложные вещи, возможно не самое ключевое свойство архитектора. Но точно не последнее.
Может он и хороший Архитектор чисто с технической стороны, но вы то не строитель, и вам умные схемы и бубнеж не нужны.
Да, умение понятно объяснять сложные вещи, возможно не самое ключевое свойство архитектора. Но точно не последнее.
Варианты:
— попрошу дать переводчика с «архитекторского» на русский
— попрошу своих спецов сделать оценку проекта с резюме на русском.
Понятно объяснить сложные вещи архитектор должен уметь, но не бизнесу, а технарям, которые будут его архитектуру реализовывать. Это необходимое условие. А вот бизнесу — так, при прочих равных будет плюсом. А для самого архитектора может оказаться и минусов — вместо работы по презентациям таскать будут.
— попрошу дать переводчика с «архитекторского» на русский
— попрошу своих спецов сделать оценку проекта с резюме на русском.
Понятно объяснить сложные вещи архитектор должен уметь, но не бизнесу, а технарям, которые будут его архитектуру реализовывать. Это необходимое условие. А вот бизнесу — так, при прочих равных будет плюсом. А для самого архитектора может оказаться и минусов — вместо работы по презентациям таскать будут.
тут неправильно определили требования к архитектору, у него есть конкретные задачи за рамки которых можно выходить если есть время и умения, но они вовсе не обязательны да и платят не за это, больше похоже на то что основная работа архитектора у вас уже зделана и больше эта позиция не нужна, потому и занимаетесь всякими не архитекторскими задачами.
В любой профессии могут быть различные отклонения в ту или иную сторону. Уверен, где-то есть примерно такие архитекторы, которые у вас представлены в секции «ожидание». Просто они работают не в одиночку, а в связке с разного рода менеджерами. Где-то делают ставку на универсалов, а где-то задачи разделяют между узкими специалистами.
Что касается знаний по железу, большинство программистов, как мне кажется, когда думают о профессии архитектора, представляют себе именно архитектора программного обеспечения. Разумеется, если проект не чисто софтварный, но включает в себя и построение аппаратной архитектуры, то в железе разбираться придётся. Ну или понадобятся два архитектора: один по софту, другой — по железу.
Что касается знаний по железу, большинство программистов, как мне кажется, когда думают о профессии архитектора, представляют себе именно архитектора программного обеспечения. Разумеется, если проект не чисто софтварный, но включает в себя и построение аппаратной архитектуры, то в железе разбираться придётся. Ну или понадобятся два архитектора: один по софту, другой — по железу.
Если бы не знал работу других архитекторов, то после такой статьи задумался бы об уходе из ИТ. Да, иногда им приходится представлять архитектуры бизнесу, но особых навыков продаж от них не ждут — для этого другие люди есть. И сами презентации они готовят. А уж заниматься менеджментом задач персоналу гораздо дешевле поручить ПМу. В общем и в целом за 20+ лет в индустрии, понимание роли архитектора у меня сводится к разработке технических решений и их технико-экономических обоснований.
По поводу отсутствия важного пласта информации в интернете — чистая правда.
К примеру недавно хотел найти рекомандации по организации структуры проектов для ASP.Net WebAPI + HTML & JS, но так ничего и не нашёл. Примеры — это либо Hello World, либо пространные рассуждения об архитектуре веб-приложений, а меня интересуют удачные примеры разделения проектов на части, структура и именование папок, организация взаимодействия между слоями, вопросы конфигурации, масштабирования и стратегий кэширования. Вообщем хотелось бы увидеть разбор архитектуры больших проектов с их плюсами и минусами.
Но такого найти не удалось…
Если у кого есть полезные ссылки — пожалуйста поделитесь в личку или тут.
К примеру недавно хотел найти рекомандации по организации структуры проектов для ASP.Net WebAPI + HTML & JS, но так ничего и не нашёл. Примеры — это либо Hello World, либо пространные рассуждения об архитектуре веб-приложений, а меня интересуют удачные примеры разделения проектов на части, структура и именование папок, организация взаимодействия между слоями, вопросы конфигурации, масштабирования и стратегий кэширования. Вообщем хотелось бы увидеть разбор архитектуры больших проектов с их плюсами и минусами.
Но такого найти не удалось…
Если у кого есть полезные ссылки — пожалуйста поделитесь в личку или тут.
Думаю что вашей статье не хватает более четкого определия предметной области и чуть большего описания типа систем которые вы разрабатываете.
Это примерно как пытаться описать чем занимается программист, не уточняя область в которой он работает.
Согласитесь, описание фронтенд разработчика и разработчика прошивок для роутера будут очень разными.
Как дополнение к вашему расказу, предлагаю глянуть эту статью:
https://dou.ua/lenta/articles/software-architect-position/
В ней описывается роль IT Архитектора в которой уклон делается в сторону разработки програмного обечпечения а не железа.
Это примерно как пытаться описать чем занимается программист, не уточняя область в которой он работает.
Согласитесь, описание фронтенд разработчика и разработчика прошивок для роутера будут очень разными.
Как дополнение к вашему расказу, предлагаю глянуть эту статью:
https://dou.ua/lenta/articles/software-architect-position/
В ней описывается роль IT Архитектора в которой уклон делается в сторону разработки програмного обечпечения а не железа.
'ИТ-архитектор департамента развития корпоративных продаж' — вы продавец или в лучшем случае менеджер, а не архитектор.
Не скажу конкретно про автора, но в каком-нибудь немаленьком интеграторе вполне может быть департамент развития корпоративных продаж, и там может быть архитектор, основная функция которого проектировать за заказ ИТ архитектуры, безо всяких продаж.
Сомневаюсь, что безо всяких продаж. Как раз в маленьком такое может быть, где, грубо говоря, два департамента — обслуживания и развития продаж, а если в большом и у развития продаж есть свой архитектор, то его основная функция создавать архитектуры, которые будут развивать продажи. Ну или представлять уже разработанные так, чтобы они развивали продажи. В любом случае внутренним заказчиком прежде всего будут маркетологи, которые знают (или считают, что знают) какие архитектуры разовьют продажи.
Напоминает разговор двух подружек, одна из которых недавно родила, а вторая ещё нет. Первая в красках расписывает свой опыт, раскладывая всё по пунктам, начиная от вынужденного изменения образа жизни во время беременности и заканчивая уровнем сервиса в обычной российской больнице. В итоге она заканчивает свой монолог фразой: "Никогда больше не буду рожать!" На что вторая подружка ей отвечает: "Я тоже!"
Единственная мысль, которая крутилась у меня во время чтения статьи, — это мысль о том, что как же мне повезло, что я не ИТ-архитектор. А в самом конце захотелось сделать официальное заявление: "Никогда не буду ИТ-архитектором! Слышите? НИ-КОГ-ДА!"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что ловить в карьере ИТ-архитектора: ожидания VS реальность