Архитектура архитектуры архитектора

    Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

    А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.

    Появляется, кстати, не всегда и не везде. Ведь не в каждой луже можно встретить кораблик. В самых больших - есть шанс. В такие лужи обычно и заплывают корабли из стартрека. Enterprise. Что же ищут эти корабли в корпоративных болотах? Чтоб вода не иссыхала, ветер только попутный и кругом гавани с блекджеком… Проще говоря им нужен сервис на много лет и так, чтоб исполнялись все их капризы за обещанные деньги.

    Чтоб избежать проверенного классического сценария «много, дорого, бестолково» нужны ориентиры. Пунктир намеченного пути на карте требований и функционала. Это не красота и элегантность рисунков Леонардо, и не лабиринты цвета Поллока. Архитектура вообще не про искусство. Нет, все любят, когда красиво. Вот я бы строил дом, тоже бы хотел не бетонную коробку, а чтоб в вечность. Но у вечности, однако свои расценки. Так что даже Джи-мэн с кейсом полным золота хочет хайп и тренды, но строго в бюджет. Архитектура даёт парадигму.

    Собственно, без архитектуры любое решение отдельной задачи правильное. Если работает. Как только появилась на графике тонкая красная линия – уже можно оценить то или иное решение. Чем дальше оно от этой линии, тем хуже. Задача же самой архитектуры – дать решение как можно большему количеству задач без дополнительной разработки. Счастья всем даром, и пусть никто не уйдёт обиженным!

    От теории к практике. Линия на картинке – плевое дело. А как насчет реальной архитектуры то? Вот тут бы хотелось немного поподробней. Тем более, что картинка глупая. Если фича нужна, то её запилят. Как и положено, зеленой пересекающей параллельной линией прозрачного цвета. Поэтому и архитектуру нужно гибкую и разноцветную. Но сначала – прямые линии на голубом листе и ярылчки с брендами. Blueprint и tech. stack. И это вообще не архитектура, а дизайн. Набросок.

    Как это в Agile устроено при построении задания, так и здесь: цель, средства, что дано. Для этого шага есть много сапог. Померяв несколько, я решил быть в тренде. На одной ноге IDesign, на другой DDD. Вот только не надо мне тут про микросервисы, клиент-сервер и всякие распределенки. Мы не на этом этапе. Нас интересует то, «что» нужно клиенту, а не «как». В старом добром UML мы бы сейчас построили use-case и block диаграммы. Нам нужно определить основных игроков и функции - расставить точки на карте. Я обычно не углубляюсь пытаюсь рисовать человечков – пользователи разные, но система одна. Так что я просто отрезаю интерфейс от сценариев. Грубый план обычно - такой синий пирог с разноцветными цукатами.

    Набросок для внутреннего обсуждения
    Набросок для внутреннего обсуждения

    Опытный инженер сразу заметит, что как-то попахивает заданием для продуктового отдела нашего супермаркета. Все вот эти Product Owner и Business Analyst должны дать те самые юзкейсы и фитчи. Хотя нет, опытный инженер вообще это читать не будет. И уж тем более кто как не он, должен знать, что архитектуру сначала надо продать своим. Начальству, инженерам, поддержке и тд. Поэтому и диаграмма должна говорить на их языке. Что же важно мне на данном этапе – определить блоки, которые будут служить основой. Те, что ближе к константам, чем к переменным. Несущие конструкции. Количество стен, не углубляясь из чего они сделаны.

    Продали колонны? Что теперь интересно вашим клиентам? Цвет труб! То что они увидят, только в случае серьёзного чп. Логично же. Большой и неповоротливый энтерпрайз любит, чтоб о нём говорили как о динамичном и энергичном. Так чтоб в тренде, вон с тем стратапом. Но только, чтоб надёжно. Вам нужны жужалки и стразики - buzz words.  Вот тут уже надо начать набрасывать распределенные микросервисы на облако. После первого этапа все должны в курсе будет ли эта закрытая ли система, с доступом в сеть или нет, количество пользователей и срок жизни, дискретность окружения и всё такое. Это, однако, не помешает клиентам требовать cloud для системы в offline. Нет, я не преувеличиваю. И вот чтоб были автономные микромодули, но только монолитом. Актуальные и верные данные в любое время в постоянно доступной, разрозненной системе. Привет кэп! Можно обнаружить (в копилке личного опыта), что клиент в северной Африке на диалапе, лучший пинг в ближайшее облако больше 300, а хотят они реалтайм для управления дронами по видео с бортовой камеры. Инженеры, работающие с клиентами напрямую, в цирке не смеются.

    Значит теперь задача набросать много звучных и цветных иконок трендовых технологий. Универсального рецепта нет, так как готовить всё равно придётся из того, что есть в холодильнике. Вряд ли вам дадут нанять новую команду специалистов. Энтерпрайз проекты живут десяток лет и года 2-3 в разработке. Так что в одну клавиатуру такое не поднимешь. Необходимы готовые команды, а у них уже есть какой-то опыт и знания. Если у вас 5 команд бэкенда пишет на Java, то переводить их Python нет не времени не смысла. Играете с теми кубиками что есть, и будьте любезны собрать слово «счастье». Однако стоит всё-таки делать выбор и не пускать на самотёк. Если у вас есть клиент (UI/UX), и он не слишком мудрёный и жирный, то тут можно вставить свежачок. Лицо системы долго без изменений не живёт, да и фронтэнд технологии тоже. Так что, если актуален сейчас React – бери его и найдите одного специалиста. Бэкхэнд на 10 лет вперёд требует и технологию, которая не исчезнет. Поэтому то и популярны .NET и Java. Если есть место микросервисам, то каждая команда может взять свою технологию. Но они же в том же холодильнике, так что сюрпризов не будет. Только помните, что микросервисы не всегда уместны. А иногда и совсем не уместны. Нет у вас центра и не нужно динамическое масштабирование, то может и не надо городить огород? Люди десятки лет, работавшие на поддержке монолита, не обрадуются тому, что им придётся содержать зоопарк. Они даже не понимают, что это надо выкатывать и содержать вручную в случае частного закрытого решения (on-premises project). Нельзя поехать и поменять или подключиться по RDP и залезть ручками в базу данных. А потом они всё равно это сделают через какой-нибудь джампер бастион и поменяют что-то, «как-то не догадавшись», что это лишь одна из 12 баз и теперь данные всей системы не стыкуются - прощай выходные!

    Немного оффтопа. Клиент как кит в океане, только старый, не грациозный, с тремя головами и вяло текущей деменцией. Но и корпорации, которые его обслуживают не лучше. У них старые связи с клиентом. Они когда-то поставляли/производили железо и пытаются видеть в софте всё те же станки. Сделали рабочий прототип – фигачим еще миллион и поставляем. Долгая проектирование, потом немного допилим, в производство и на моментально на полки/клиентам. Они же всегда так делали. Как это roll-out – это долгий процесс? Ведь copy-paste и в продакшн! В общем, как много нам открытий чудных… Поэтому решение надо не только продать и утвердить внутри своей компании, нужно еще удостовериться, что сама компания будет соответствовать решению.

    И так наша следующая диаграмма будет всё еще аморфной, но уже на технологиях. Точность компонентов и связей здесь не столь важна, а вот обоснование выбора картинок необходима. Именно здесь впервые затронут бюджет. Лицензии, специалисты, обучение, поддержка, система. Много иконок – клиент радуется, большие траты – клиент дуется. Есть, конечно, горячие пирожки. Не важно куда и как, но нужен Kubernetes. Даже если и нет масштабирования – засуньте в автоматическое тестирование как часть CI-CD. Но иконка должна быть. Бесплатные пирожки ещё вкусней. Вам понятно, что Kubernetes будет с контейнерами Docker, но заказчик будет брызгать деньгами, если вы добавите и этот образок. И безопасность туда же – прилепите https.

    Технологии
    Технологии

    Ну и конечно, как только нам удаётся найти и протолкнуть решение – мы идём по пути наименьшего сопротивления. Повторяющиеся паттерны во всё меньшем масштабе. Архитектура Мандельброта.

    Монотонное множество архитектуры
    Монотонное множество архитектуры

    Вот где то тут я чувствую, что текста уже слишком много. Стоп. Остальные дальше просто не пройдут. Если зайдёт - буду продолжать.


    UPD: Если б вместо простыни была презентация...

    Мы на первом этапе построения архитектуры - призрачная идея проекта. Пока нет технических деталей и задание не оформлено. Необходимо помочь всем вовлечённым сторонам оценить риск и стоимость потенциального проекта. Технические детали не важны. Важно говорить с отделом продаж на языке инновации (buzz words). С отделом разработки об тех, кто есть и кого не хватает в стеке технологий. С менеджментом о рисках. С финансами о ресурсах (найм специалистов, devops, железо и софт разработки). Тезисно:

    a. Нет проекта – нет архитектуры (и не надо её придумывать – пеки пирог)
    b. Холодильник технологии (уголок почти трендовых технологии - иконостас)
    c. Cutting Edge (лучшая инновация – то, что уже много раз делали - Мандельброт)

    Комментарии 26

      0

      Про machine learning забыли. Вот туда, к kubernetes надо докинуть

        0
        А основываюсь на личном опыте и за 10 лет ни разу не довелось делать что-то большое да еще и с мыашинным обучением. Очень большие компаний очень любят аналитику. Так что все с кем пришлось работать и даже просто подавать RFP уже имели что то своё. Тяжелое и заоблачное. Требуют всегда интеграцию, а не реализацию.
        Что нужно докидывать, так это то, что и так есть. Допустим добавить безопасности иконкой JWT и SSO. Сказать, что у нас не просто репозиторий, а big data. Если вставить AI, то сразу насторожите заказчика. Он уверен, что это дорого и долго — он ведь уже строил себе аналитические машины.
        +3

        Какой стиль! Браво!
        Вам, батенька, надобно писать!
        Читается на одном дыхании.

          +4
          У автора видно много лично пережитой боли.
            +1
            Следуя описанный путём, вполне можно сделать классическое «много, дорого, бестолково».
            Архитектура Мандельброта — красиво, иконок просто море. Не бестолково ли? Особенно для управления дроном по диалапу.
            Где то тут Дао есть, но не вижу.
              0
              Дао в том, что путь архитектора — это продавать. Решение надо продать себе, начальству, клиенту. Разработчику нужно объяснить — он поймёт. Остальные не на том техническом уровне. Они хотят иконки и чтоб «бохато».
                0

                Если ваше "продавать" повернуть из негативного ключа и немного гарнировать, то получается общение/убеждение на различных уровнях организации (и владение их языком). То что Грегор Хоппе называет The Architect Elevator
                https://www.youtube.com/watch?v=Zq2VcRZmz78

                  +1
                  Ну это не негативный, а скорее ироничный ключ. Продавать — это именно продавать. Можете назвать убеждать. Но смысл тот же. Вы убеждаете всех расстаться с конкретными деньгами в обмен на потенциальный, но не гарантированный успех.
                  Архитектор в энтерпрайзе зачастую в очень странном положении врача, который не только должен опеределить болезнь, подобрать лекарство, но еще и убедить больных купить его и применять. Это многолетний опыт в разных компаниях и сотня интервью (с обеих сторон). Я и слушал и рассказывал, что же такое работа архитектора много раз. Картина всегда была похожа. Поэтому и решил частично опубликовать опыт.
                    0

                    Я вас понимаяю думаю, и имею похожий опыт наверно прост в другой не русскоязычной стране, с соотвествующим менталлитетом и ситуацией в IT.
                    Всегда хорошо свой опыт и терминилогию сравнить с тем что делают другие, вот я вам и привел Герегора, мне его точка зрение импонирует. Если незнакомы посмотрите, может понравится ;)

                      0
                      Посмотрел, понравилось. В наше время подкасты и ютуб — намного информативней и актуальней книг.
                      Но… Это архитектор в сферическом вакууме. Вы не будете руководить процессом. Сломать нельзя, жить с ней тоже. Поэтому надо её менять. Об этом говорят, все. Но никто не говорит как. Как он и сказал — вы будете всем мешать. Я как раз хочу немного рассказать как делать то, о чём он говорит. Не нужно начинать архитектуру с архитектуры. Вот прям как он сказал: «без стрелочек — не считается» — это то, что вам нужно. Первый шаг! Иконки, кубики и без стрелочек. Об этом пост. Начни разговор с системой на её языке. То, что у Грегора заняло один слайд «от CFO до CEO» занимает годы в реальности.
                      Кстати, в русскоязычной стране и вообще с/на постсоветском пространстве я никогда не работал.
                        0
                        Кстати, в русскоязычной стране и вообще с/на постсоветском пространстве я никогда не работал.

                        я тоже ;) Атак уже 15 лет в IT.

              0
              Так что, если актуален сейчас React – бери его и найдите одного специалиста.
              За Реакт в энтерпрайзе уже перестали бить ногами? Мой коллега как раз пару недель назад был сослан разбираться в том что понаписала команда, где он и был этим «одним специалистом» — после его перехода в архитекторы.
              Если есть место микросервисам, то каждая команда может взять свою технологию
              Популярное заблуждение. На втором десятке микросервисов вас начинают подкарауливать в темных углах офиса измученные DevOps. А после выкатывания всего этого добра в реальный продакшен оказывается что «что-то идет не так» довольно часто, но понять причины очень трудно из-за несовместимого формата логов — если их вообще пишут.
                0
                За Реакт не бьют, если всё работает. Это для энтерпрайза «cutting edge». Нужен кто то, кто будет вести за руку команду фронтэнда. А вот убрать специалиста из этой команды — большая ошибка.
                А насчёт микросервисов, то там важно не пропустить следующее предложение. Вы все команды знаете, тех.стек их известен, и все они будут писать на том же и так же. Но на ковре из желтых листьев в кабинете генерального, вы будете говорить, что у них полная свобода, и мы прям хайтек из силиконовой долины. И не вздумайте ляпнуть, что кремневой. На неизвестные дали он не купиться — это риск.
                  0
                  Дело в том, что мы действительно «хайтек из силиконовой долины». И на следующей неделе с компанией окончательно попрощаются несколько менеджеров, купившихся на сказки про «cutting edge» и поддержавших переписывание ключевого приложения на Реакт с бэкендом на NodeJS (вся остальная инфраструктура — на Java). И погнали их не за «не работает» — а за «не работает и не ясно почему». А авторы сей гениальной идеи, первыми учуяв запах жареного — сбежали еще под Новый Год.
                –1
                хорошо написано. по факту
                  +1

                  Может стоит почитать профильную литературу, чем через собственный, негативный опыт пытаться изобретать велосипед который не поедет?

                    +1
                    Профильной литературы на самом деле нет. Архитектура идёт неразрывно с бизнес домейном. Есть книги и курсы о том, как строить и чего избегать. Но почти никто не рассказывает, что техническая часть архитектуры — самая маленькая и простая. Я не хочу сказать «как нужно делать», а хочу указать «что нужно помнить». Ездить на велосипеде не научишься читая книги.
                    0

                    Я разделяю ключевую мысль статьи — архитектура это проекция продукта (бизнеса) в технический ландшафт.


                    Также поддерживаю мысль, что архитектуру нужно продавать. Но не с целью ее навязать, а с целью убедить и убедиться, что архитектура соответствует ожиданию бизнеса. Более того, его стратегии.


                    Чтобы предлагать адекватные архитектурные решения я даже пошел учиться на EMBA. И очень доволен этим решением. Развивается стратегический взгляд на архитектуру в контексте целей бизнеса, а не требований.


                    Требования это мгновенное фото текущих потребностей. Но не планов. Да и их качество, зачастую, ну такие себе… Их "тупое" исполнение ведет к существенной нагрузке по управлению изменениями. И неудовлетворенности бизнеса.

                      0
                      Для каждой цели своя картинка и пояснительная записка к ней. Представление может быть в виде как разбить проект на куски с точки зрения выбора партнеров, с точки зрения разбития на этапы, с точки зрения поступающих денежных потоков, организационной структуры…
                      Картинка с красной линией должна быть четырехмерной (ну или в матричном представлении) — помимо времени есть деньги и качество (отсутствие брака), а требования создаются с учетом этих трёх измерений.
                        0
                        Есть много разных архитекторов. Видение и размерность красной линии будут разными у Program Architect и Solution Architect. Извините не знаю как по-русски. Этот пост введение в процесс архитектуры. Первый шаг — наброски. Простые, понятные, не технические. Это флаер.
                        0
                        Очень похожая картина :) продолжай.
                          +1
                          Архитектор (в рамках поста) — мостик связывающий фундаментальные знания (в том числе существующие технологии и решения) и прикладные знания (предметная область для которой проектируется продукт).
                          Литературы и информации по первому пункту — пруд пруди, по второму либо личный опыт, либо заказчик.
                          ИМХО пост написан менеджером по продажам
                            0

                            А на каком языке и с какими фактами защищать архитектуру перед безопасностью компании?
                            Как правило тут то все новое и технологичное может не пройти

                              +1
                              На их языке. С моделью угроз, средствами защиты информации, организационно-распорядительными документами.
                                0
                                Это пост планировался как первый в серии, так что на этом этапе всё сводится к иконостасу. Нужны стандарты, сертификаты, методологии. Допустим PCI DSS, GDPR, ISO 9K, ISO 27K. К ним неплохо добавить NIST, OWASP, TLS и тд. На первичном этапе вы пытаетесь установить что необходимо, но не раскрывая подробности. Клиенты в энтерпрайзе ставят вам минимальную планку ниже которой опускаться нельзя. Вы просто не пройдёте тендер. Можно больше, но обычно это и намного дороже. Если вы, как архитектор, видите критическую необходимость, то вы ставите подходящий значёк. Необходимо шифрование данных в базе — ставте какой-нибудь GDPR.
                                Менеджеры увидят сертификацию — это престиж, продажа — необходимый уровень для тендера и расширение рынка, финансы — понижения риска. Никто из них не знает, что для какого-нибудь PCI нужно будет реализовывать политики безопасности, разделение ролей, стойкую криптографию при передаче данных. Это должны знать вы (хотя бы тезисно). Так что если вы на этом этапе протащили нужную иконку — это как бы становится базовым требованием, и как бы даже исходит не от вас, а от клиента и от продакт менеджера и т.д.
                                Более подробно о безопасности я постораюсь рассказать, когда дойду до части про Due Diligence.
                                  0
                                  А если вам нужно защитить архитектуру перед отделом безопасности клиента, то вам нужны будут сами сертификаты о которых заявили значками на этапе дизайна. Они ваш проездной. Показали сертификат и все вопросы отпадают. Потому чтоб получить этот сертификат нужны концепции и политики безопасности, регламенты и мониторинг, аудиты и всё такое.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое