Comments 26
Про machine learning забыли. Вот туда, к kubernetes надо докинуть
А основываюсь на личном опыте и за 10 лет ни разу не довелось делать что-то большое да еще и с мыашинным обучением. Очень большие компаний очень любят аналитику. Так что все с кем пришлось работать и даже просто подавать RFP уже имели что то своё. Тяжелое и заоблачное. Требуют всегда интеграцию, а не реализацию.
Что нужно докидывать, так это то, что и так есть. Допустим добавить безопасности иконкой JWT и SSO. Сказать, что у нас не просто репозиторий, а big data. Если вставить AI, то сразу насторожите заказчика. Он уверен, что это дорого и долго — он ведь уже строил себе аналитические машины.
Что нужно докидывать, так это то, что и так есть. Допустим добавить безопасности иконкой JWT и SSO. Сказать, что у нас не просто репозиторий, а big data. Если вставить AI, то сразу насторожите заказчика. Он уверен, что это дорого и долго — он ведь уже строил себе аналитические машины.
Какой стиль! Браво!
Вам, батенька, надобно писать!
Читается на одном дыхании.
У автора видно много лично пережитой боли.
Следуя описанный путём, вполне можно сделать классическое «много, дорого, бестолково».
Архитектура Мандельброта — красиво, иконок просто море. Не бестолково ли? Особенно для управления дроном по диалапу.
Где то тут Дао есть, но не вижу.
Архитектура Мандельброта — красиво, иконок просто море. Не бестолково ли? Особенно для управления дроном по диалапу.
Где то тут Дао есть, но не вижу.
Дао в том, что путь архитектора — это продавать. Решение надо продать себе, начальству, клиенту. Разработчику нужно объяснить — он поймёт. Остальные не на том техническом уровне. Они хотят иконки и чтоб «бохато».
Если ваше "продавать" повернуть из негативного ключа и немного гарнировать, то получается общение/убеждение на различных уровнях организации (и владение их языком). То что Грегор Хоппе называет The Architect Elevator
https://www.youtube.com/watch?v=Zq2VcRZmz78
Ну это не негативный, а скорее ироничный ключ. Продавать — это именно продавать. Можете назвать убеждать. Но смысл тот же. Вы убеждаете всех расстаться с конкретными деньгами в обмен на потенциальный, но не гарантированный успех.
Архитектор в энтерпрайзе зачастую в очень странном положении врача, который не только должен опеределить болезнь, подобрать лекарство, но еще и убедить больных купить его и применять. Это многолетний опыт в разных компаниях и сотня интервью (с обеих сторон). Я и слушал и рассказывал, что же такое работа архитектора много раз. Картина всегда была похожа. Поэтому и решил частично опубликовать опыт.
Архитектор в энтерпрайзе зачастую в очень странном положении врача, который не только должен опеределить болезнь, подобрать лекарство, но еще и убедить больных купить его и применять. Это многолетний опыт в разных компаниях и сотня интервью (с обеих сторон). Я и слушал и рассказывал, что же такое работа архитектора много раз. Картина всегда была похожа. Поэтому и решил частично опубликовать опыт.
Я вас понимаяю думаю, и имею похожий опыт наверно прост в другой не русскоязычной стране, с соотвествующим менталлитетом и ситуацией в IT.
Всегда хорошо свой опыт и терминилогию сравнить с тем что делают другие, вот я вам и привел Герегора, мне его точка зрение импонирует. Если незнакомы посмотрите, может понравится ;)
Посмотрел, понравилось. В наше время подкасты и ютуб — намного информативней и актуальней книг.
Но… Это архитектор в сферическом вакууме. Вы не будете руководить процессом. Сломать нельзя, жить с ней тоже. Поэтому надо её менять. Об этом говорят, все. Но никто не говорит как. Как он и сказал — вы будете всем мешать. Я как раз хочу немного рассказать как делать то, о чём он говорит. Не нужно начинать архитектуру с архитектуры. Вот прям как он сказал: «без стрелочек — не считается» — это то, что вам нужно. Первый шаг! Иконки, кубики и без стрелочек. Об этом пост. Начни разговор с системой на её языке. То, что у Грегора заняло один слайд «от CFO до CEO» занимает годы в реальности.
Кстати, в русскоязычной стране и вообще с/на постсоветском пространстве я никогда не работал.
Но… Это архитектор в сферическом вакууме. Вы не будете руководить процессом. Сломать нельзя, жить с ней тоже. Поэтому надо её менять. Об этом говорят, все. Но никто не говорит как. Как он и сказал — вы будете всем мешать. Я как раз хочу немного рассказать как делать то, о чём он говорит. Не нужно начинать архитектуру с архитектуры. Вот прям как он сказал: «без стрелочек — не считается» — это то, что вам нужно. Первый шаг! Иконки, кубики и без стрелочек. Об этом пост. Начни разговор с системой на её языке. То, что у Грегора заняло один слайд «от CFO до CEO» занимает годы в реальности.
Кстати, в русскоязычной стране и вообще с/на постсоветском пространстве я никогда не работал.
Так что, если актуален сейчас React – бери его и найдите одного специалиста.За Реакт в энтерпрайзе уже перестали бить ногами? Мой коллега как раз пару недель назад был сослан разбираться в том что понаписала команда, где он и был этим «одним специалистом» — после его перехода в архитекторы.
Если есть место микросервисам, то каждая команда может взять свою технологиюПопулярное заблуждение. На втором десятке микросервисов вас начинают подкарауливать в темных углах офиса измученные DevOps. А после выкатывания всего этого добра в реальный продакшен оказывается что «что-то идет не так» довольно часто, но понять причины очень трудно из-за несовместимого формата логов — если их вообще пишут.
За Реакт не бьют, если всё работает. Это для энтерпрайза «cutting edge». Нужен кто то, кто будет вести за руку команду фронтэнда. А вот убрать специалиста из этой команды — большая ошибка.
А насчёт микросервисов, то там важно не пропустить следующее предложение. Вы все команды знаете, тех.стек их известен, и все они будут писать на том же и так же. Но на ковре из желтых листьев в кабинете генерального, вы будете говорить, что у них полная свобода, и мы прям хайтек из силиконовой долины. И не вздумайте ляпнуть, что кремневой. На неизвестные дали он не купиться — это риск.
А насчёт микросервисов, то там важно не пропустить следующее предложение. Вы все команды знаете, тех.стек их известен, и все они будут писать на том же и так же. Но на ковре из желтых листьев в кабинете генерального, вы будете говорить, что у них полная свобода, и мы прям хайтек из силиконовой долины. И не вздумайте ляпнуть, что кремневой. На неизвестные дали он не купиться — это риск.
Дело в том, что мы действительно «хайтек из силиконовой долины». И на следующей неделе с компанией окончательно попрощаются несколько менеджеров, купившихся на сказки про «cutting edge» и поддержавших переписывание ключевого приложения на Реакт с бэкендом на NodeJS (вся остальная инфраструктура — на Java). И погнали их не за «не работает» — а за «не работает и не ясно почему». А авторы сей гениальной идеи, первыми учуяв запах жареного — сбежали еще под Новый Год.
хорошо написано. по факту
Может стоит почитать профильную литературу, чем через собственный, негативный опыт пытаться изобретать велосипед который не поедет?
Профильной литературы на самом деле нет. Архитектура идёт неразрывно с бизнес домейном. Есть книги и курсы о том, как строить и чего избегать. Но почти никто не рассказывает, что техническая часть архитектуры — самая маленькая и простая. Я не хочу сказать «как нужно делать», а хочу указать «что нужно помнить». Ездить на велосипеде не научишься читая книги.
Я разделяю ключевую мысль статьи — архитектура это проекция продукта (бизнеса) в технический ландшафт.
Также поддерживаю мысль, что архитектуру нужно продавать. Но не с целью ее навязать, а с целью убедить и убедиться, что архитектура соответствует ожиданию бизнеса. Более того, его стратегии.
Чтобы предлагать адекватные архитектурные решения я даже пошел учиться на EMBA. И очень доволен этим решением. Развивается стратегический взгляд на архитектуру в контексте целей бизнеса, а не требований.
Требования это мгновенное фото текущих потребностей. Но не планов. Да и их качество, зачастую, ну такие себе… Их "тупое" исполнение ведет к существенной нагрузке по управлению изменениями. И неудовлетворенности бизнеса.
Для каждой цели своя картинка и пояснительная записка к ней. Представление может быть в виде как разбить проект на куски с точки зрения выбора партнеров, с точки зрения разбития на этапы, с точки зрения поступающих денежных потоков, организационной структуры…
Картинка с красной линией должна быть четырехмерной (ну или в матричном представлении) — помимо времени есть деньги и качество (отсутствие брака), а требования создаются с учетом этих трёх измерений.
Картинка с красной линией должна быть четырехмерной (ну или в матричном представлении) — помимо времени есть деньги и качество (отсутствие брака), а требования создаются с учетом этих трёх измерений.
Очень похожая картина :) продолжай.
Архитектор (в рамках поста) — мостик связывающий фундаментальные знания (в том числе существующие технологии и решения) и прикладные знания (предметная область для которой проектируется продукт).
Литературы и информации по первому пункту — пруд пруди, по второму либо личный опыт, либо заказчик.
ИМХО пост написан менеджером по продажам
Литературы и информации по первому пункту — пруд пруди, по второму либо личный опыт, либо заказчик.
ИМХО пост написан менеджером по продажам
А на каком языке и с какими фактами защищать архитектуру перед безопасностью компании?
Как правило тут то все новое и технологичное может не пройти
На их языке. С моделью угроз, средствами защиты информации, организационно-распорядительными документами.
Это пост планировался как первый в серии, так что на этом этапе всё сводится к иконостасу. Нужны стандарты, сертификаты, методологии. Допустим PCI DSS, GDPR, ISO 9K, ISO 27K. К ним неплохо добавить NIST, OWASP, TLS и тд. На первичном этапе вы пытаетесь установить что необходимо, но не раскрывая подробности. Клиенты в энтерпрайзе ставят вам минимальную планку ниже которой опускаться нельзя. Вы просто не пройдёте тендер. Можно больше, но обычно это и намного дороже. Если вы, как архитектор, видите критическую необходимость, то вы ставите подходящий значёк. Необходимо шифрование данных в базе — ставте какой-нибудь GDPR.
Менеджеры увидят сертификацию — это престиж, продажа — необходимый уровень для тендера и расширение рынка, финансы — понижения риска. Никто из них не знает, что для какого-нибудь PCI нужно будет реализовывать политики безопасности, разделение ролей, стойкую криптографию при передаче данных. Это должны знать вы (хотя бы тезисно). Так что если вы на этом этапе протащили нужную иконку — это как бы становится базовым требованием, и как бы даже исходит не от вас, а от клиента и от продакт менеджера и т.д.
Более подробно о безопасности я постораюсь рассказать, когда дойду до части про Due Diligence.
Менеджеры увидят сертификацию — это престиж, продажа — необходимый уровень для тендера и расширение рынка, финансы — понижения риска. Никто из них не знает, что для какого-нибудь PCI нужно будет реализовывать политики безопасности, разделение ролей, стойкую криптографию при передаче данных. Это должны знать вы (хотя бы тезисно). Так что если вы на этом этапе протащили нужную иконку — это как бы становится базовым требованием, и как бы даже исходит не от вас, а от клиента и от продакт менеджера и т.д.
Более подробно о безопасности я постораюсь рассказать, когда дойду до части про Due Diligence.
А если вам нужно защитить архитектуру перед отделом безопасности клиента, то вам нужны будут сами сертификаты о которых заявили значками на этапе дизайна. Они ваш проездной. Показали сертификат и все вопросы отпадают. Потому чтоб получить этот сертификат нужны концепции и политики безопасности, регламенты и мониторинг, аудиты и всё такое.
Sign up to leave a comment.
Архитектура архитектуры архитектора