Comments 29
Со многим в статье не согласен, но не хочется цеплятся - написано весело и задорно. Основной посыл мне тоже очень близок, роль архитекторов ослабляется в небольших и шустрых компаниях.
Когда-то аппаратная часть не была отделена от программной и были конструкторы, которые занимались созданием больших ЭВМ. Потом аппаратную часть отделили от программной. Конструкторы так и продолжили заниматься аппаратной, а под программную нужен был новый тип координатора-управленца: архитектор.
Заимствовали эту роль из строительной отрасли, применять его хотели для создания завершенных систем, которые мы знаем сейчас как операционные системы. С тех времен много что поменялось и расплодилось разных типов архитекторов. Для этих изменений были причины.
И вот мы в настоящем. У нас Интернет, стартапы, быстро-меняющийся бизнес, у которого нет конечной цели, так как никто до нас не строил тот Интернет, который мы сейчас строим. И вот в условиях неопределенности, вы точно хотите это сопровождать и строить архитекторами? В семантику которого изначально заложено, что будет построено законченно здание, причем именно такое, которое было задумано заранее. У нас точно везде на горизонте просматриваются законченные здания? И есть понимание, куда нужно всем придти в бизнесе, IT, Интернете?
Нужно ли роль, которую вы называете "Архитектор 2.0" вообще называть "Архитектором"?
были конструкторы, которые занимались созданием больших ЭВМ.
Конструкторы скорее занимались физической реализацией архитектуры. И раньше и сейчас.
Мне кажется, что вы очень точно сформулировали суть, что Архитектор 2.0 это не то, что думают об архитекторе обычно. Этот термин я использую как раз для того, чтобы ясно отделить смысл этой роли от "старого" смысла.
Допускаю, что эту роль можно было бы назвать как-то иначе. Типа ArchOps-инженер. Или что-то в этом духе. Но тогда целевая аудитория была бы не ясна.
В моей практике, переход происходит именно в среде действующих архитекторов. Лично я стремлюсь сохранить преемственность действующий практик, при четком формулировании вектора развития.
Оказывается, я уже много лет как "Архитектор 2.0". В резюме, что ли, вписать? Хотя не, лучше не надо, только дурацких вопросов на собеседованиях добавится.
А как работают архитекторы в крупных компаниях?
Они так же смотрят каждый мердж реквест и чинят сами тех.долг?
с удовольствием бы, но на это нет времени. Тут бы успеть хотелки бизнеса в чувство привести и фантазии команд приземлить :)
Зависит от того, что вы подразумеваете под крупной компанией. И да, архитекторы тоже люди и бывают разными :)
У нас (компания в 7к голов), например, есть архитекторы которые не умеют водить и есть те, кто сами пишут ядро самых критичных компонент, а также проводят ревью.
Первый заключается в том, что функция архитектора в текущем виде перестает быть востребованной. Второй, в том, что у всех нас есть очень хорошие шансы быть успешными в новой эре - в эре управления архитектурой v2.0.
Удивился первому тезису(только за эту неделю около 5 HR постучало в линкедин), не понял второй.
Дальше внимательно читал, местами удивлялся, местами улыбался, очень редко соглашался.
Дочитал до
Репозиторий DocHub - https://github.com/RabotaRu/DocHub
и все понял. Респект автору за энергию и потраченное время для такой обстоятельной рекламы своего продукта.
функция архитектора в текущем виде перестает быть востребованной
я отношусь к той части архитекторов, которые скажут что архитектура в ее классическом виде еще долго будет востребованной - стоит лишь посмотреть на темы докладов последних конференций.
При этом Архитектор 2.0 выглядит как персонаж Ван Дамма из фильма Универсальный солдат: не потому что он умеет все, а потому что это технологический прорыв. Только я надеюсь что Архитектору 2.0 придется делать это все не самому, а ему поможет армия DevOps.
Архитектор, этот такой человек, который должен обеспечивать качество ИТ-инфраструктуры. Правильно?
Теперь обратим внимание на картинку для привлечения внимания - данный персонаж, очевидно, сгенерённый нейросетью, явно страдает косоглазием. Поставим рядом слова "качество" и "косоглазие". Совместимы ли они? Учтём, что у автора была возможность сгенерировать другую картинку, в отличии от реально обладающих подобным недугом людей.
К чему это я? Ну как бы эмоционально напрягает в очередной раз видеть архитектора, который по факту свободный фантазёр (в его собственных терминах), но считающий себя творцом, и при первой возможности наверняка становящийся диктатором, принуждающим остальных реализовывать неэффективные фантазии. Хотя если диктатору бьют по шаловливым ручкам, ему приходится прикидываться "летописцем", мол я весь в трудах про мега-архитектуру, но вот не дают птице расправить крылья...
Это не личный выпад в адрес автора. Мне действительно неприятно видеть массовое пришествие "цифровых моделистов", снижающих эффективность ПО на порядки (в буквальном смысле - вместо мегабайт программы съедают гигабайты, а то и десятки гигабайт).
Почему я считаю, что данная статья показывает пример именно неэффективного архитектора? Очень просто, вот что говорит автор:
Миссия сообщества SEAF - создание технологии цифровой моделей предприятия
Даже в описании миссии мы видим ошибки в падежных формах. Я понимаю, что автор знает, что это такое и быстро исправит после показа пальцем, но тем не менее - здесь мы видим ярчайший пример пренебрежения деталями, то есть в целеполагающем и очень коротком программном заявлении автор не пожелал просто перечитать текст. Повторная перечитка практически гарантировано выявила бы проблему. Но нет, фантазии же уносят в даль, нам некогда думать о мелочах.
Теперь про бизнес. Архитектор нанимается для обеспечения качества ИТ-инфраструктуры. Технологии цифровых фантазий, наверняка, очень важны, но не в бизнесе. Ну или не в большинстве бизнесов. Ставим рядом две цели - эффективность и цифровые модели. Как минимум - эти цели не равны. Как максимум, учитывая способность многих архитекторов ярко и образно уводить от сути дела к очень красивым фантазиям, эти цели просто не совместимы друг с другом. Хотя последнее - продукт лишь отдельных архитекторов, за всех говорить не буду. Но, к сожалению, именно уводящих от целей бизнеса архитекторов мы видим довольно часто.
И очень характерным для них является примерно такой стиль изложения:
мир архитекторов уже не будет прежним
Как вы понимаете, мир не будет прежним именно после вмешательства архитектора. В принципе да, мир точно изменится. Вопрос лишь - в какую сторону?
Подсказка - миру не нужно вот это:
домены, федерации и практики архкодирования
Ему нужна эффективность. Где связь между текстом статьи и эффективностью? Я не нашёл. Поэтому мир, как всегда, ждёт новый виток эффектных речей, сопровождаемый показом занимательных слайдов, но вот повышение эффективности мир точно пока что не ждёт.
Спасибо за комментарии и замечания к тексту! Конечно, я буду исправлять все выявленные недостатки. Как в тексте, так в подходе и коде.
Крайне важно для развития учитывать конструктивную обратную связь. По этой причине я публикую статью и веду постоянную работу с сообществом.
Мне кажется, что я смогу исправить очевидные ошибки замеченные вами. Но вероятно, не все смыслы я уловлю из-за обилия антуражного текста. Если вас не затруднит, можете выразить конструктивные предложения для развития тезисно? Я бы с удовольствием вынес их на рассмотрение сообществом.
Уважаю столь изысканно поданную критику про отсутствие конструктива :)
Конструктив - эффективность.
Например - засилье микросервисов очень хорошо обосновывается именно в терминах множества диаграмм и прочих артефактов, описывающих некие кубики. Но посмотрим на детали. В деталях все эти микросервисы представляют из себя шаблоны, наполняемые простейшим кодом. В результате имеем толстый-толстый слой шаблонизации, за которым где-то в неведомых глубинах скрывается что-то вроде "дай мне имя клиента с номером ХХХ". Внимание, вопрос - если при выполнении каждой операцию основные усилия тратятся на работу шаблонизатора (а ля "фреймворк"), то во сколько раз мы увеличим производительность, если шаблоны внезапно исчезнут?
Стандартное возражение - всё сложно. Шаблоны не убрать, потому что они как-то хитро уменьшают сложность. Ну и что, если тысячами шаблонных вызовов тоже нужно как-то управлять, зато теперь мы их все можем нарисовать в виде кубиков. Правда непонятно, почему не могли раньше сделать то же самое с компонентами (без микросервисов).
Ещё возражение - у нас отказоустойчивая система! Но опять непонятно, а если микросервис упал, то кто же будет решать задачу вместо него? Ответ простой - а давайте сделаем кластер! То есть ещё один толстый уровень шаблонизации над и так уже жирным куском всяческих прослоек. Но может кластер можно сделать и с подходом по типу компонентов?
Но это, на самом-то деле, второстепенная риторика, ибо важнее всех искусств для нас является... Правильно - взаимодействие с бизнесом.
К сожалению, пока бизнес сам не умеет проектировать самоё себя, то как ему может помочь информационная технология? Ответ "одна большая кнопка 'Сделать всё'" не предлагать.
Отсюда мораль - пока бизнес про самого себя мало что понимает, наступает время очень заманчивых перспектив по должностям и зарплатам для всех тех, кто смело называет себя Архитекторами. Плюс перспектива бесконечного и интересного квеста "создание технологии цифровой моделей предприятия". Ну действительно - твори сколько душе угодно, всё равно бизнес не поймёт, что с него берут на порядок (а то и два) больше денег, чем практически доступно. Прекрасная возможность почувствовать себя творцом.
Но вопрос был про конструктив.
Ну так конструктив всё тот же - эффективность. Она есть в выше нарисованной картине?
Хотя я понимаю, что менять бизнес, означает менять общество. Да, это не входит в компетенцию Архитектора. Но что тогда остаётся? Остаются красивые фантазии, реализуемые за счёт неэффективного бизнеса. Хотя можно сказать, что неконструктивно уводить разговор в материи, не поддающиеся "технологии цифрового моделирования", а потому проблемы нет, ну и говорить, соответственно, не о чем.
Комментарий мне напомнил стиль из одного очень старого баяна:
Тогда, я надеваю свой плащ и волшебную шляпу …. ?
Остальные комментарии думаю излишни, кроме вопрос где продаётся такая забористая дурь.
Расскажу личный опыт. Так получилось, что я Solution Architect и именно во многом творец. Как минимум большое число внедрений :) Хотя конечно люблю и доку держать в порядке, и правила иногда установить.
Статья хорошая, прочитал с удовольствием, но не могу согласиться с направлением развития. А именно - давайте все писать код.
Поясню.
----------------------
Начнем с цели. Наша цель - это код в продуктиве, который работает согласно функциональных требований и нефункциональных (выделил сейчас, но вернусь потом) требований. Этот код пишет разработчик и он, и только он является необходимым success factor. Все остальное уже достаточные факторы. Это важно. Я всегда для себя стараюсь помнить, что в конечно итоге продукт физически реализует разработчик и все для него.
Теперь о других.
Аналитик - скажу честно (даже если кто-то и обидится), писать код, псевдо-код, low-code - это для тех, кто умеет писать код. 99% аналитиков в лучшем случае напишут некоторое подобие чего-то рабочего. Если в формате user story допускается куча ошибок, пропусков исключительных ситуаций - то с чего ситуация улучшиться, если дать в руки инструмент. Все равно, почти никогда аналитик не может адекватно запустить свой код, а значит лишен важной capability, доступной разработчику: отладка. Конечно есть исключения из правила, но в реале, даже имея опыт с BPM-платформами, которые таки и "продаются" (вводится понятие citizen-developer, он же бизнес, и пусть он пишет), в реале - в лучшем случае настройка бизнес логики в строго ограниченных пределах. И самое главное (что применимо к архитектору), если аналитик производит говно-код, зачем мучать разработчика, заставляя его брать его за стартовую точку?
DevOps - тут да, но это отдельное ответвление. Кто помнит, есть такая утилита make, которой сто лет в обед. Поєтому ничего нового, просто в какой-то момент скоуп применения расширился. Но в реале я честно не вижу связи с ролью архитектора, точнее принципиального изменения
QA - опять же, ну чего-то автоматизируют. Из опыта, далеко не всегда работает, так как если погнаться за автоматизацией, часто QA забывают найти баг размером з 15ти килограмовый арбуз. Конечно это ускорение, но опять же - это шаг в сторону, который мало влияет на архитектора
-----------------
Теперь чуть-чуть о Творце.
Напомню, архитектор отвечает за реализацию нефункциональных требований. Т.е. уже с этого места становится понятно, что роль (как минимум в части творца) никуда не идет. Конечно, на простых проектах ее можно отдать лиду/DevOps, но на сложных - у вас одих лидов может быть 5 штук.
Поэтому уже в этой части есть чем заниматься:
собираем требования (кто скажет, что это может аналитик, плюньте в него) :)
ищем решения
согласовываем
контролируем
Надо ли осваивать для этого псевдо-код над терра-формом? Нет. Это серьезная аналитическая работа, где вам надо думать, анализировать, проигрывать разные варианты и все это доносить/пояснять/советоваться
Правильный архитектор - самый коммуникабельный член команды. Не ПМ, не :) Именно он. Потому что задача сложить вместе все и всех, и все время контролировать что
никто не разбегается
нет ошибок в изначальном плане
нет технических затыков
Также архитектор - тот, кто всем поможет и заткнет любую "дырку" если она имеет отношение к технике. Наверное ждругим везет и всегда команда набрана из элитного спецназа в третьем поколении, которые умеют все. Но в реале надо:
присматривать за требованиями, чтобы они писались вменяемо и раскладывать их по компонентам. Я в целом практикую архитектурное описание фич, так как часто не всегда очевидно, как это делать, даже если сторька выглядить предельно понятной заказчику
помочь тестировщикам с автоматизацией или специализированными видами тестирования (особенно отказоустойчивость и нагрузка)
выработка с командой лучшего технического решения, часто через PoC, иногда, если есть возможность, можно чего-то проверить самому. Понятно разраб из меня никакой на длинной дистанции, но если задача собрать и проверить что "штука" рулит и будет фурычить - это очень полезно
Ну и наконец, а кто отменял написание Solution Design? Тут есть секрет, его надо писать сразу и быстро. В иделае раньше требований. Тогда все будут читать именно его :) На самом деле, это полезная вещь. не схемы или псевдо код. А именно вменяемое описание. Иногда через полгода реально сложно понять, почему, мля, мы так решили делать. А тут рррраз, все описано. И не надо заново изобретать велосипед. Но понятно, это более актуально там, где много "связей" (интеграций). Потому что чем больше команд, тем нужнее связующий документ
А да, контрактинг. Интересно, кто же:
напишет список работ
даст предварительную оценку
расскажет клиенту, почему все будет работать
защитит наше решение
вычитает технические статьи контракта
Так вот, архитектор. Ну а кто? ПМ? Ну как ПМ, не имея архитетуры, напишет хотя бы список работ. Чисто по фичам стремно. Для маленького приложения пойдет. Условно мы пишем 150е приложение, все понятно. А для интгерационного проекта решения, которого еще нет? Ню-ню. Ну и понятно, архитектор - неотемлимая часть пресейла, где есть существенная тех. составляющая
----------------------------
Вывод
Архитектор - это не про схемы и нотации. Это та часть работы, которая позволяет другим увидеть ее результаты, когда его нет. Как возможность прочитать книжку без автора :) Но это лишь оформление результатов работы. И, мне кажется - именно из-за этого сместился фокус в статье.
Но я могу ошибать, зато пока пишешь - можно порефлексировать и найти в себе что-то новое :)
Спасибо! Отличный комментарий. Много важных аспектов затронуто. Считаю необходимым для себя на него обстоятельно ответить. Но мне для этого потребуется время.
не повезло вам с командой, бывает. У нас аналитики прекрасные, требования собирают хорошо.
Всё так, но есть нюанс. Автор пишет больше про трансформацию роли корпоративного архитектора, что видно из его отсылок к "цифровой модели предприятия", а вы - о хороших практиках архитектора решений. И, ЧСХ, правы вы оба. Ибо когда построенная вами, как солюшеном, система выкатывается в прод со всеми её интеграциями, взаимосвязями данных и участием в сложных бизнес-процессах, то именно у корпарха начинает болеть голова, как вот это всё учесть, чтобы не забыть и не допустить, например, выкатывания другой системы с аналогичным сервисом, например. И архитектура-как-код, правильно приготовленная, понятная и на уровне команды и на уровне инфры и на уровне корпарха, может быть очень полезной.
Ну, я за автора говорить не могу, но мне так не показалось. Как минимум классификация выглядит такой, которая пытается покрыть все виды архитекторов. Да и связи з DevOps, QA явно имееют смысл для того, кто работает в "полях". Ну и опять же, проблемой по мнению автора являеться "Фактически, код создает для них единый производственный континуум. Но Архитектор 1.0 существует вне его… ", что тоже говорит о архитекторе, как об участнике производственного процесса
Давайте по вашему примеру. Ограничимся ролью Enterprise Architect, напишу именно английский вариант термина, на случай если мы о разных ролям. Давайте к практике.
К примеру, в телекоме существуют нишевые решения, которые позволяют вести inventory того, что есть, проектировать изменения и все это внедрять по начертанным заповядм твердой рукой архитектора. Эти нишевые решения отлично вписываются в ИТ окружение как со стороны "давайте распознаем новый девайсик и впишем его в нашу базу со всеми интересующими нас даеталями", так и например в сторону ERP для того, чтобы выписать наряды на специалистов, которые поедут на месте. Но это очень специфическая и технологичная отрасль, с кучей стандартов, где вполне реально это реализовать. Ну а большой рынок (как с точки зрения клиентов, так и денег) оправдывает вложения в такие продукты.
С general software все сложнее. Стандарты, которые позволяют легко распознавать всю инфу с новых компонетов как бы отсутствуют (fixMe), технологический зоопарк в масштабе всего мира просто впечатляет своим размером. В отличии от телекома нет задачи, чтобы Вася из Простоквашино звонил Джону из нью-васюки, при этом из провайдеры тоже ничего не знают друг от друге.
Есть решения, которые:
дают инструменты для того, чтобы это все описывать (к примеру Archimate)
есть минимальное автораспознование
Но то что я видел, и в чем участовал (хотя мое участие в таком закончилось не начавшись, так как я сразу сказал, что это идея плохая и она не взлетит, что и случилось), выглядит как превращение архитекторов в писателей доки. Это конечно вопрос к СТО, зачем тратить на эту активность много денег, но называть это "архитектура-как-код" - очень преувеличено.
Я лично, как Solution, использовал Enterprise Architect от Sparx. Очень сильный тул, поддерживает 100500, генерацию кода и не только. У именя было полуавтоматическая генерации wiki-pages со всеми перекрастными ссылками, которые все описывали, DDL для изменений в базе с полупрямым влетом в CI/CD. Но это все такое и весьма условно. Плюс порог вхождения в тул довольно таки большой, и если человек не тянет - сразу концепция идет лесом и очень жестко.
-------------
Я думаю, ключ к этому нотации, за которыми последуют решения и автоматизация в обе стороны. Но, как по мне, зоопарк этого всего пока что делает такие решения относительно слабыми, так как критична полнота. Если вы что-то упустили - считайте все. К примеру, Archimate стартует с требований/функций, которые есть только в голове у людей. Все, вам нужно кропотливо вносить это все вручную, и очень внимательно это все описывать. А автораспознавания нет, и ошибки приводят к тому, что зависимости и влияние технических фия лучше перепроверять.
Думал что прочитаю что-то полезное для роста, по ходу чтения всё больше походило на водопад графомании про "домены, федерации и практики архкодирования" и... реклама в конце, классика. Вы хоть ставьте тег #ЯПиарюсь, мне претензий и ожиданий
На подготовку этой статьи было потрачено около месяца. Отчасти она написана по материалам для выступлений. Но в большей части, мне потребовалось полностью переосмыслить ее изложение. Обеспечить достоверными ссылками на источники. Перепроверить себя.
Изначально мне казалось, что я просто возьму презентацию, напишу те слова, что говорю по ходу выступления и все получится. Но нет. Так не сработало. Презентация имеет смысловые фрагменты, которые легко разделяются. Статья - нет. При проведении презентации я имею обратную связь от аудитории и могу подстроиться. В статье от читателя многое что зависит. От того, что он сам хочет найти.
Я не считаю свое изложение мысли сильным. Но в чем я не сомневаюсь, это в тех смыслах, которые стараюсь донести.
Чтобы не огорчать читателя тратой времени, я проставил маркер сложности на максимум. В начале статьи предоставил ему выбор читать или смотреть видео. Чтобы это стало возможно, убедил организаторов конференции FlowConf опубликовать мое выступление раньше, вне принятых правил.
Я не ставил тег "я пиарюсь" потому, что не считаю так. Хотя, если это чему-то поможет, не вижу в этом проблемы. Я продвигаю подход и сообщество разделяющее его. Оно открыто. Каждый может повлиять на его развитие или продвигать так, как сам посчитает нужным.
Мне жаль, что вы не обнаружили чего-то полезного для своего роста в моей статье. Я старался. Обязательно учту свой опыт. Надеюсь, будущие статьи окажутся более понятными и ценными для вас.
Хотел улучшить картинку автора из статьи, так как у него какая то беда со стрелками была ?А в итоге вот что получилось. И даже как будто на цикл Дейминга легло.
Вот тут https://excalidraw.com/#json=JF6UybvPV7oYShcuV1pin,eKM4BbKt9Y5YFH6wu6ykDA исходник.
Если вдруг кому-то тоже захочется привнести своего Творца)
Цель встраивать архитектора в производственный континуум представляется несколько однобокой. Управление архитектурой - это свой уровень абстракции. В различных документах встречал два понятия - Architecture continuum и Solution Continuum. Соответственно строятся из achitecture building blocks и solution building blocks. Это как два кольца (процесса) управления, взаимодействующие друг с другом через контроли, чтобы решения, принятые в архитектурном континууме были корректно имплементированы в ландшафте. Если архитектурная функция выстроена правильно (что редкость), то разрыва не происходит. Цель "встроить архитектуру в производственный процесс" - кажется несколько однобокой, так как, с другой стороны, ее нужно встроить в системы управления, где решения на самом деле готовятся и принимаются, с последующими механизмами реализации принятых решений / инкрементов через контроли в цифровой архитектуре. Надеюсь в SEAF будет ответ в том числе на вопросы по тому, как интегрировать архитектурную функцию именно в системы управления)
@rpiontik,
У меня простой вопрос, почему у Вас в github-репозитории 48 открытых ишаков, причём многим из них 2 года? Вы релизы отгружаете без исправлений или исправления не закрываете?
Архитектор 2.0