Меня зовут Анна Лисовская, я ИТ-архитектор департамента развития корпоративных продаж. Идею этого поста мне подсказал бывший сокурсник, которому внезапно стало скучно в разработке. В один прекрасный день он решил, что больше не хочет писать код, начал искать возможности для развития в смежных ИТ-областях и атаковал меня вопросами об особенностях работы ИТ-архитекторов. Из беседы стало ясно, что даже коллеги-айтишники слабо представляют себе сложности и особенности профессии ИТ-архитектора. Не исключено, что заблуждения, в которых пребывал мой бывший сокурсник, достаточно расхожи.
Я собрала свой опыт и опыт коллег в пост в формате «ожидание/реальность». Такой формат мне видится наиболее полезным с точки зрения работы с ожиданиями относительно профессии ИТ-архитектора – часто среди айтишников эти ожидания либо не совсем верны, либо завышены. Много тонких моментов становятся очевидны только при полном погружении в профессию. Лучше узнать о них «на берегу» и поразмышлять, сможете ли вы с ними мириться. Хочется думать, что мои заметки будут полезными для других айтишников, которые намереваются переквалифицироваться в ИТ-архитекторы.
Ожидание: чтобы стать успешным ИТ-архитектором, нужно хорошо знать «железо» и софт.
Реальность: работа ИТ-архитектора – это в основном people management.
За ИТ-архитекторами в головах представителей других айтишных профессий почему-то закрепился образ интровертов, которые легко цитируют документацию, досконально знают, как работает то или иное программное и аппаратное обеспечение, и целыми днями рисуют конфигурации ИТ-систем. Это верно лишь отчасти. ИТ-архитектор действительно обладает широчайшим кругозором, хорошо знает, как работают софт и оборудование, но главным скиллом в его профессии является people management. ИТ-архитектор должен иметь навыки или хотя бы задатки управления командой, поскольку именно он собирает на проект специалистов самых разных направлений. Держа в голове архитектуру проекта, он ставит задачи конкретным специалистам, следит за качеством и сроками исполнения тех или иных работ и в конечном счете отвечает за то, чтобы вся команда выполнила задачу, поставленную бизнес-заказчиком. При этом ИТ-архитектор должен очень хорошо уметь говорить с бизнесом на его языке. И при представлении своего видения той или иной ИТ-системы должен обращать внимание не только на технологическую красоту и изящество решения в целом, но и подчеркивать его экономическую целесообразность.
Ожидание: любого технического образования достаточно для работы ИТ-архитектором.
Реальность: базового образования, как правило, не хватает; учиться нужно постоянно.
Глупо отрицать, что техническое образование – это база практически для каждой ИТ-профессии. Но так же не слишком дальновидно утверждать, что диплома любого технического вуза хватит на освоение профессии ИТ-архитектора. Ни один российский вуз не выпускает готовых специалистов по данному профилю. Например, я училась в петербургском Политехе на радиофизическом факультете. Это здорово помогло на заре карьеры, когда я работала техническим ассистентом по продаже оборудования Cisco. Бэкграунд инженера-физика помог понимать процессы, на основе которых работает современное коммуникационное «железо». Благодаря этой форе в виде знаний по предметной области мне было легче, чем коллегам-новичкам. Вместе с тем, я достаточно быстро поняла, что даже фундаментального образования радиофизика мне мало, и приняла решение получить второе высшее по своему тогдашнему профилю – по сетям. Меня повысили до системного инженера, допустили к оборудованию и стали привлекать на встречи с вендорами и клиентами. Собственно, с того момента и началось самое интересное. Я много работала непосредственно с «железками», настраивала сетевое и серверное оборудование, привыкала общаться с заказчиками, постепенно понимала, как устроен ИТ-бизнес, как строится взаимодействие с вендорами и дистрибьюторами.
Не берусь утверждать, что мой вариант восхождения по «лестнице знаний» единственно верный. Среди коллег из числа ИТ-архитекторов есть специалисты, которые начинали вчерашними выпускниками университетов, а затем всё глубже погружались в предметную область. Узнать больше им помогали вендорские курсы и сертификации, курсы учебных центров, семинары и другие образовательные мероприятия. Но вне зависимости от того, какой способ развития выбран, ИТ-архитектор учится практически постоянно. Нужно быть готовым инвестировать в это обучение как минимум свое время, как максимум – и время, и деньги. Например, среди моих знакомых есть человек, который в прошлом был прожженным гуманитарием — он выпускник философского факультета СПбГУ. В свое время поставил себе цель стать ИТ-архитектором. На это он потратил несколько лет своей жизни — получил высшее техническое образование, дополнительно «прокачал» свои навыки на вендорских курсах и сейчас работает на позиции ИТ-архитектора в крупном центре обработки данных.
Ожидание: необходимые знания можно добрать самостоятельно – все есть в интернете.
Реальность: нужно знать, какие знания добирать; самых ценных знаний в открытом доступе нет.
Фактор самообразования в профессии ИТ-архитектора начинает работать, когда ты сталкиваешься с конкретной проблемой в рамках конкретного проекта. Даже в рамках одной информационной системы конкретную проблему можно решить по-разному. Поэтому даже если кто-то аналогичную проблему уже решал, совсем не факт, что это решение окажется подходящим для проекта, которым занимаетесь вы. По этому принципу строится общение на тематических площадках в Интернете. Специалисты сначала сталкиваются с проблемами, пишут о них на форуме. А их коллеги уже рекомендуют возможные решения исходя из конкретных условий: посмотри это, подкрути то, почитай здесь и т.д. «Волшебных таблеток», подходящих для каждой системы, просто нет.
Также у некоторых вендоров невозможно получить техническую информацию по другим каналам, кроме официального обучения. Такой информации нет в интернете. Ее нельзя где-либо купить.
Ожидание: быть архитектором в компании-вендоре лучше, чем работать с заказчиками.
Реальность: развитие идет быстрее, если работаешь на разноплановых проектах.
Конечно, трудиться ИТ-архитектором в вендоре престижно. Мощный соцпакет, размеренный рабочий график и отсутствие постоянной «гонки» способствуют погружению в особенности конкретного решения. Для этого требуются вполне конкретные качества — здоровая дотошность, усидчивость, умение правильно преподнести лучшие качества решения конкретному клиенту в формате презентации или публичного выступления. Да, эти качества сделают из вас профессионала, но, на мой взгляд, работа ИТ-архитектором в провайдере или интеграторе существенно быстрее повысит вашу экспертизу и профессиональный уровень в целом. Работа на разных проектах расширяет технический кругозор, приучает к общению с самыми разными людьми и учит искать решения, оптимальные для всех сторон, задействованных в процессе.
Если мы говорим про архитектора в заказчике, то от него в значительной степени требуется умение убеждать в необходимости преобразований ИТ-инфраструктуры таких «сложных» людей, как генеральный и финансовый директора. В их картине мира ИТ – это служба, которая тратит деньги. Часто, чтобы объяснить необходимость финансирования проекта, ИТ-архитекторы со стороны заказчика, вендора и интегратора объединяют усилия и продумывают аргументацию вплоть до конкретных формулировок. По своему опыту могу сказать, что пара таких совместных мозговых штурмов помогла намного лучше понять основные закономерности, по которым функционируют механизмы принятия решений в российских компаниях.
Ожидание: программист легко может переквалифицироваться в ИТ-архитектора.
Реальность: у системного инженера больше шансов начать новую карьеру.
На мой взгляд, более благоприятные начальные условия построить карьеру ИТ-архитектора у системных инженеров. Они лучше представляют, как работает оборудование, они сами все настраивали, у них есть опыт ликвидации всевозможных сбоев. У инженеров не всегда может хватать теоретической базы, но благодаря опыту они быстрее эту базу нагонят. На втором месте – разработчики. Толковый программист действительно может стать архитектором по ПО – особенно если такой программист принимал участие в создании больших информационных систем и понимает их логику. А дальше он просто берет навыки построения ЛВС, вычислительной инфраструктуры, систем хранения данных и пр. Еще сложнее переквалифицироваться в ИТ-архитекторы из пресейлов. Пресейл более-менее знает теорию, но с оборудованием он знаком по верхам, поскольку не «крутил» его настройки руками и не устранял причины сбоев и не пытался понять природу их возникновения.
Ожидание: труд ИТ-архитектора – это постоянный креатив.
Реальность: рутины хватает, особенно бумажной работы.
Часто будущие архитекторы думают, что их работа состоит исключительно из проработки решений и построений систем, но это не так. Рутины более чем достаточно, и связана она не в последнюю очередь с подготовкой документации по проектам. Впрочем, основную часть такой работы можно поручить команде, а самому проконтролировать ее качество документов и свести их воедино. Как видим, people management всплывает и здесь.
Ожидание: ИТ-архитектор может развиваться только как эксперт в технологиях.
Реальность: все зависит только от вас. Вырасти можно в абсолютно любом качестве.
ИТ-архитектор – универсальный специалист, который хорошо знает ИТ-оборудование и программное обеспечение, и наряду с этих обладает компетенциями менеджера. Это дает, пожалуй, самые широкие возможности для карьерного роста среди всех ИТ-специальностей. Ты можешь расти как технический эксперт, нарабатывать специализацию и в конечном итоге стать одним из лучших специалистов в своей предметной области. Либо ты можешь развиваться как управленец – как минимум стать менеджером проектов, а как максимум — директором по ИТ в заказчике. Особенно если заказчик как раз в данный момент подыскивает ИТ-директора под стратегическую задачу модернизации инфраструктуры. Словом, даже если в один прекрасный день вы поймете, что не хотите быть ИТ-архитектором, ваш многогранный опыт с одинаковым успехом позволит стать и крутым экспертом в технологиях, и выполнять административные функции.
Ожидание: ИТ-архитектор – профессия, где удачно балансируются работа и время для жизни.
Реальность: рабочий день с 9 до 18 – не про системного архитектора; работа достаточно стрессовая.
ИТ-архитектор – это центральный персонаж при создании информационных систем. Именно от архитектора зависит, состоится ли проект, заработает ли на этом проекте компания. В этом смысле груз ответственности нередко давит – особенно когда заказчик ставит сжатые сроки, и ты просто не имеешь права подвести проектную команду. Пример из жизни: на часах 10 утра, рабочий день только начался. Звонит представитель заказчика и просит коммерческое предложение к полудню. Или аналогичное обращение прибывает в 21:00, и уже к утру клиент просит прикинуть, сколько будет стоить оборудование для развертывания ИТ-системы. Я выкручиваюсь – звоню своим людям в дистрибьюторах и вендорах, прошу быстро выдать мне стоимость решения. Многое, если не всё, помогают решить нормально выстроенные отношения. Коллеги не подводят, но жесткие рамки, в которые часто ставят заказчики, — дополнительный источник стресса.
Заключение
Интерес к профессии ИТ-архитектора со стороны разработчиков и представителей других айтишных специальностей подкрепляется неплохой зарплатой. Но эта работа подойдет не всем. Она не для вас, если:
- Вам не очень нравится нести ответственность не только за себя, но и за того парня.
- Вы считаете, что ваша доступность по телефону или по электронной почте должна быть ограничена рамками рабочего дня.
- Вы не слишком любите людей и не хотите искать к ним подход, чтобы достигать своих целей.
- Перспектива готовить или проверять проектную документацию вызывает у вас зевоту.
- Вы с трудом ладите с «Пауэр Поинтом» и не слишком в восторге от того, что вам нужно выступать перед клиентами.
- Вы считаете себя самым компетентным специалистом и не считаете нужным объяснять что-либо тому, кто с вами не согласен.
Если у вас нет вышеперечисленных особенностей характера, но при этом есть желание развиваться, становиться лучше и осваивать новые предметные области, то добро пожаловать в ряды ИТ-архитекторов. Возможно, кое-какие детали остались за рамками поста. Пишите вопросы в комментариях, я постараюсь ответить.
Анна Лисовская, ИТ-архитектор департамента развития корпоративных продаж группы компаний Softline.
Комментарии (52)
deathwalker
20.01.2017 11:54+4На лицо незнание матчасти, где-то в статье речь идет про СТИ, а где-то про архитектуру приложений:
«Ожидание: программист легко может переквалифицироваться в ИТ-архитектора.
Реальность: у системного инженера больше шансов начать новую карьеру.»
Архитектор например Java и Архитектор по инфраструктруе (СТИ) — две совершенно разные области в IT. И если Java программист захочет стать архитектором по инфраструктуре, ему придется изучать и сети и серверное оборудование и СХД и тд. и не важно какие информационные системы он «писал» — учить все равно придется.
Softliner
20.01.2017 12:32+1Архитектура приложений и архитектура информационных систем – это разные вещи. Архитектура информационной системы — это совокупность софтверной и железячной архитектур. Именно поэтому я подчеркиваю: чтобы стать архитектором информационных систем, программисту (который наверняка имеет представление об архитектуре приложений) нужно получить знания по закономерностям построения архитектуры в «железной» части информационных систем. Сюда входит изучение процессов построения вычислительных сетей, сетей передачи данных и архитектуре инфраструктурного ПО — такого, как виртуализация, системы резервного копирования, системы мониторинга и др.
SkiBY
20.01.2017 17:17+1Ну тогда давайте же отмечать четко IT-архитектор информационных систем.
Пока то, что я увидел в статье, как-то больше похоже для меня на проект-менеджера, выросшего из хорошего бизнес-аналитика.
uniqm
20.01.2017 12:45+6У меня сложилось впечатление, что в статье описана специальность ИТ-архитектора не в широком смысле, а в конкретной компании/команде. В одном человеке, Анне, была замешана не только роль архитектора, но и тимлида, менеджера продукта, проекта, бизнес/системного аналитика и тд. И история получилась соответствующая.
ggrnd0
20.01.2017 13:55Потому что такова реальность.
Это конечно не входит в прямые обязанности архитектора.
Но очень часто бывает, что проекты периодически вешают на того кто достаточно компетентен и относительно свободен в данный момент.
А не на того, у кого это прописано в должностных инструкциях.
Архитектор в этом плане почти универсален.
Чудо конечно не сотворит, но какое-то время подменить тимлида, РП и прочих сможет.
Пока это ему позволяет собственная нагрузка.uniqm
20.01.2017 14:26А я ничего не имею против. Сам по табелю системный аналитик, а ролей выполняю вокруг огого ;)
Просто зайдет в статью человек «далекий» от ИТ и кааак прочитает, что оказывается ИТ-Архитектор должен с бизнесом на его языке говорить.ggrnd0
20.01.2017 14:36Вообще архитектор с бизнесом должны говорить на одном языке.
Чей язык неважно, но если бизнес и архитектор не понимают друг друга ничего хорошего они не заархитектят и не забизнесуют...uniqm
20.01.2017 15:35+1По мне не надо «травмировать» архитектора общением с бизнесом (как и программиста, тестировщика и ряд других «внутренних» специалистов). Для этого есть закаленные аналитики/менеджера, они узнают и спокойно донесут концентрат знаний до архитектора. А архитектор в случае чего попросит уточнений у аналитика, который снова спокойно выудит их у бизнеса/его окружения/других источников. Случай, когда архитектор не смог получить от аналитика ответы или сомневается в них, да так, что пошел сам к бизнесу — по мне не нормальный.
ggrnd0
20.01.2017 15:45Ну с бешенным эффективным подменеджером он общаться конечно не будет.
А вот с советом директоров, гендиром, прочими директорами он должен и будет общаться лично.
cclvi
21.01.2017 14:32Интересно. А вот как по мне — так это абсолютно нормальный случай. Архитектор и аналитик находятся на одном уровне коммуникаций, просто аналитик выясняет функциональные требования системы, а архитектор — нефункциональные.
Конечно в какой-то конкретной команде всю коммуникацию можно держать через аналитиков. Но с таким же успехом тогда её можно построить и через архитектора. Это порочная практика в обоих случаях.
Ещё один момент, почему архитектор должен понимать язык бизнеса — архитектор участвует в пресейлах. А это значит, что надо уметь хорошо молоть языком и диаграммы рисовать не только в UML и с представителями заказчика говорить на одном языке.VolCh
21.01.2017 15:38Аналитик должен выяснить и функциональные, и нефункциональные требования. Грубо, аналитик формирует все требования к системе (тактико-техническое задание), на основании которого архитектор формирует один или несколько вариантов технического задания, возможно через стадию разработки одной или нескольких концепций.
Архитектор иногда участвует в пресейлах, если заказчик или собственные сейлзы на этом настаивают. Например, если заказчик хочет непосредственно с технарем поговорить, или если сейлзы сыпятся на технических деталях.
apelserg
20.01.2017 13:06+1ИТ-архитектор департамента развития корпоративных продаж.
Другое название — консультант/менеджер по продажам, скорее всего продукции определённого вендора.
Держа в голове архитектуру проекта, он ставит задачи конкретным специалистам, следит за качеством и сроками исполнения тех или иных работ и в конечном счете отвечает за то, чтобы вся команда выполнила задачу, поставленную бизнес-заказчиком.
Это функции менеджера проекта (ПМ). ПМ работает на основании «рабочего плана-графика», в котором описана последовательность конкретных задач. Список задач формируется на основании требований заказчика. Для каждой задачи определяются сроки и необходимые ресурсы. В разработке технической части «рабочего плана-графика» обычно принимает участие ИТ-архитектор.
При этом ИТ-архитектор должен очень хорошо уметь говорить с бизнесом на его языке.
Жаль что вы обходитесь ещё и без бизнес-аналитика.
ИМХО: функцию ИТ-архитектора кратко можно сформулировать примерно так: На основании существующей инфраструктуры и требований заказчика, разработать технологический стек проекта(проектов). Иногда это ещё назывется — разработать ТЗ.Softliner
20.01.2017 17:04Другое название — консультант/менеджер по продажам, скорее всего продукции определённого вендора.
Нет. Я работаю со всеми вендорами. Выбор вендора зависит от определенных условий. В одном заказчике это корпоративный стандарт, в другом важную роль играет цена, и т.д. Консультант и менеджер по продажам выполняет совершенно другие функции, нежели ИТ-архитектор.
Это функции менеджера проекта (ПМ). ПМ работает на основании «рабочего плана-графика», в котором описана последовательность конкретных задач. Список задач формируется на основании требований заказчика. Для каждой задачи определяются сроки и необходимые ресурсы. В разработке технической части «рабочего плана-графика» обычно принимает участие ИТ-архитектор.
Не соглашусь. По-вашему, менеджер проекта может оценить качество выполненной задачи? Он может оценить, насколько корректно составлена спецификация оборудования? Или, например, понять, все ли лицензии учтены и все ли трансиверы добавлены?
ИТ-архитектор не должен выполнять роль ПМ, но он должен обладать навыками и умениями этой должности.
ИМХО: функцию ИТ-архитектора кратко можно сформулировать примерно так: На основании существующей инфраструктуры и требований заказчика, разработать технологический стек проекта(проектов). Иногда это ещё называется — разработать ТЗ.
В качестве ответа приведу пример. Заказчик решил построить отказоустойчивый ЦОД. Архитектор собирает список сервисов, под эти сервисы пишутся требования к серверам, СХД и другому оборудованию. Далее проектируется сеть и способы обеспечения отказоустойчивости для каждого сервиса. После согласования с заказчиком архитектуры архитектор передает требования пресейлам по каждому направлению и получает от них спецификации. И только потом пишется ТЗ. Все зависит от масштабов проекта. Вы описали частный случай.apelserg
20.01.2017 18:56ИТ-архитектора, работу которого вы описали в статье, по-другому можно назвать «эникейщиком».
В организации должны быть (крайне желательно) должностные инструкции, в которых описываются функции и обязанности, которые должен выполнять человек, назначенный на определённую должность или проектную роль.
Конечно, в реальном проекте, ИТ-архитектор может выполнять много несвойственных ему задач. Но, при этом, он должен хорошо понимать, что относится к его прямым обязанностям, а что к функциям тех проектных ролей, которые он замещает.
Зачем это надо (это же так формально и скучно)? Хотя-бы для того, чтобы аргументированно ставить впрос об открытии новых вакансий и оптимизации своего рабочего времени.
Вопрос — должностная инструкция ИТ-архитектора в вашей организации — она вообще есть (в виде утверждённого документа)? вы с ней ознакомлены?
Vinchi
21.01.2017 20:18+1Я сам работал ИТ-архитектором и как ни странно все именно так — надо знать ИТ технологии, чтобы разговаривать с инженерами на их языке, а иногда и руками, надо знать людей и технологии менежмента, чтобы убеждать людей и учитывать требования бизнеса, надо много заниматься документацией. Можно конечно распределить обязанности, но в итоге за все вместе несет ответственность именно ИТ-архитектор, именно он делает сборку и ведет все это вместе. Конечно если проект большой, может быть более четкое распределение ролей, а может и быть несколько архитекторов. Еще прекрасно известно что в теории и на западе например именно так и происходит, но в реалиях нашей страны, приходится делать все. И кстати так даже интересней так как одно и то же занятие надоедает. Особенно например только пилить документацию :)
KorP
20.01.2017 13:46Меня зовут Анна Лисовская, я ИТ-архитектор
Требую фото! :)GreenStore
20.01.2017 17:21> Требую фото! :)
Softliner
20.01.2017 17:22+1GreenStore, это здорово, что Вы зашли на наш сайт и разместили тут фото наших сотрудниц, но среди них нет фото Анны :)
Fortop
20.01.2017 16:11-1Вы с трудом ладите с «Пауэр Поинтом» и не слишком в восторге от того, что вам нужно выступать перед клиентами.
Кто-то из специалистов разъяснит мне, в чем сакральная сущность навыков PowerPoint и презентаций для архитектора?
ggo
21.01.2017 16:19Если архитектор не может доходчиво и понятно объяснить сложное, не важно кому, СД или разрабам/админам, то его карьера будет, возможно, яркой, но не долгой.
Представьте строительного архитектора, которые заикаясь рассказывает про свою задумку строительства условного моста или высотки.Fortop
22.01.2017 01:16Судя по попыткам объяснить мне нечто странное ни у кого из поясняющих не возникло критического осмысления того самого «списка необходимых навыков».
Презентации, умение подать себя и свою мысль, умение отвечать за других это отлично…
Но разве это ключевые навыки без которых ИТ-архитектор немыслим?
Есть условия необходимые и достаточные.
Так вот как минимум половина из того списка не относится ни к необходимым, ни к достаточным.ggo
22.01.2017 12:39Забудьте про ИТ. Представьте, вы градоначальник. Вам нужно построить стадион, или нетривиальную развязку. И вот вам представляют проект, и Архитектор что-то бубнит себе под нос, показывает разные умные, но совершенно непонятные схемы.
Может он и хороший Архитектор чисто с технической стороны, но вы то не строитель, и вам умные схемы и бубнеж не нужны.
Да, умение понятно объяснять сложные вещи, возможно не самое ключевое свойство архитектора. Но точно не последнее.VolCh
22.01.2017 16:57Варианты:
— попрошу дать переводчика с «архитекторского» на русский
— попрошу своих спецов сделать оценку проекта с резюме на русском.
Понятно объяснить сложные вещи архитектор должен уметь, но не бизнесу, а технарям, которые будут его архитектуру реализовывать. Это необходимое условие. А вот бизнесу — так, при прочих равных будет плюсом. А для самого архитектора может оказаться и минусов — вместо работы по презентациям таскать будут.
jetcar
20.01.2017 16:49+2тут неправильно определили требования к архитектору, у него есть конкретные задачи за рамки которых можно выходить если есть время и умения, но они вовсе не обязательны да и платят не за это, больше похоже на то что основная работа архитектора у вас уже зделана и больше эта позиция не нужна, потому и занимаетесь всякими не архитекторскими задачами.
Cryvage
20.01.2017 19:03В любой профессии могут быть различные отклонения в ту или иную сторону. Уверен, где-то есть примерно такие архитекторы, которые у вас представлены в секции «ожидание». Просто они работают не в одиночку, а в связке с разного рода менеджерами. Где-то делают ставку на универсалов, а где-то задачи разделяют между узкими специалистами.
Что касается знаний по железу, большинство программистов, как мне кажется, когда думают о профессии архитектора, представляют себе именно архитектора программного обеспечения. Разумеется, если проект не чисто софтварный, но включает в себя и построение аппаратной архитектуры, то в железе разбираться придётся. Ну или понадобятся два архитектора: один по софту, другой — по железу.
VolCh
20.01.2017 22:17Если бы не знал работу других архитекторов, то после такой статьи задумался бы об уходе из ИТ. Да, иногда им приходится представлять архитектуры бизнесу, но особых навыков продаж от них не ждут — для этого другие люди есть. И сами презентации они готовят. А уж заниматься менеджментом задач персоналу гораздо дешевле поручить ПМу. В общем и в целом за 20+ лет в индустрии, понимание роли архитектора у меня сводится к разработке технических решений и их технико-экономических обоснований.
zenkz
21.01.2017 01:59+1По поводу отсутствия важного пласта информации в интернете — чистая правда.
К примеру недавно хотел найти рекомандации по организации структуры проектов для ASP.Net WebAPI + HTML & JS, но так ничего и не нашёл. Примеры — это либо Hello World, либо пространные рассуждения об архитектуре веб-приложений, а меня интересуют удачные примеры разделения проектов на части, структура и именование папок, организация взаимодействия между слоями, вопросы конфигурации, масштабирования и стратегий кэширования. Вообщем хотелось бы увидеть разбор архитектуры больших проектов с их плюсами и минусами.
Но такого найти не удалось…
Если у кого есть полезные ссылки — пожалуйста поделитесь в личку или тут.
PavelSandovin
21.01.2017 12:03+1Мартин Фаулер «Архитектура корпоративных программных приложений» — не то?
Cryvage
21.01.2017 23:57+1На случай если кто-то будет искать, новые издания этой книги носят название «Шаблоны корпоративных приложений».
sven47
21.01.2017 14:34Думаю что вашей статье не хватает более четкого определия предметной области и чуть большего описания типа систем которые вы разрабатываете.
Это примерно как пытаться описать чем занимается программист, не уточняя область в которой он работает.
Согласитесь, описание фронтенд разработчика и разработчика прошивок для роутера будут очень разными.
Как дополнение к вашему расказу, предлагаю глянуть эту статью:
https://dou.ua/lenta/articles/software-architect-position/
В ней описывается роль IT Архитектора в которой уклон делается в сторону разработки програмного обечпечения а не железа.
arielf
22.01.2017 06:20'ИТ-архитектор департамента развития корпоративных продаж' — вы продавец или в лучшем случае менеджер, а не архитектор.
ggo
22.01.2017 12:28Не скажу конкретно про автора, но в каком-нибудь немаленьком интеграторе вполне может быть департамент развития корпоративных продаж, и там может быть архитектор, основная функция которого проектировать за заказ ИТ архитектуры, безо всяких продаж.
VolCh
22.01.2017 17:03Сомневаюсь, что безо всяких продаж. Как раз в маленьком такое может быть, где, грубо говоря, два департамента — обслуживания и развития продаж, а если в большом и у развития продаж есть свой архитектор, то его основная функция создавать архитектуры, которые будут развивать продажи. Ну или представлять уже разработанные так, чтобы они развивали продажи. В любом случае внутренним заказчиком прежде всего будут маркетологи, которые знают (или считают, что знают) какие архитектуры разовьют продажи.
Shamov
23.01.2017 12:13Напоминает разговор двух подружек, одна из которых недавно родила, а вторая ещё нет. Первая в красках расписывает свой опыт, раскладывая всё по пунктам, начиная от вынужденного изменения образа жизни во время беременности и заканчивая уровнем сервиса в обычной российской больнице. В итоге она заканчивает свой монолог фразой: "Никогда больше не буду рожать!" На что вторая подружка ей отвечает: "Я тоже!"
Единственная мысль, которая крутилась у меня во время чтения статьи, — это мысль о том, что как же мне повезло, что я не ИТ-архитектор. А в самом конце захотелось сделать официальное заявление: "Никогда не буду ИТ-архитектором! Слышите? НИ-КОГ-ДА!"
ggrnd0
Следует ли ждать цикл ценных статей?
Softliner
Цикл статей — хорошая идея. Напишите подробнее о чем бы Вы хотели бы услышать?
ggrnd0
А напишите, с какими трудностями столкнулись сами, и какие ценные знания где получали?
Сам стремлюсь к архитектору, но пока лишь прицениваюсь. Сам с трудностями пока не столкнулся...
Softliner
Самые ценные знания – это знания, которые ты получаешь на практике. В теории все хорошо работает, а на практике все далеко не так. Практический опыт дает незаменимые знания.
Основная сложность состоит в том, что нужно предвидеть, с какими трудностями можно столкнуться на всех этапах выполнения проекта. Причем не только в своей области, но и смежных с ней.
Например при построении ЦОД такими областями являются строительство и инженерные системы.
Эти навыки приходят только со временем и не существует универсальной литературы.
На каждом этапе свои нюансы. На начальном этапе сложность в получении информации и ее обработке. Полное понимание приходит только со временем. Это касается не только технической информации, но знаний об устройстве бизнеса.
ggrnd0
Отборнейшая вода.
И все же начните с рассказа собственного опыта.
А там уже и уточняющие вопросы пойдут.
Vjatcheslav3345
Существуют типовые инженерные и строительные проекты (с богатой историей), на которые можно опираться в процессе обучения и некоторого планирования.
Кроме того, не стоит без острой необходимости работать с теми строительными компаниями, которые ранее никогда не строили ЦОД-ы — у строивших и портфолио есть и опыт прогулок по граблям и понимание, что такое ЦОД, который хотят от них получить.
KorP
А огласите весь список ценных знаний в закрытом доступе. Мы то о них, видимо, не в знаем :)