Сегодня в сообществе ИТ архитекторов, поддерживающих подход “Архитектура как код”, все чаще появляются упоминания о его перспективах выйти на уровень нового индустриального стандарта. Можно было бы сказать, что любое общество должно быть амбициозным и видеть себя в “Центре Вселенной”. Поэтому, не стоит об этом раньше времени статьи написывать. Но важно заметить, что архитекторы облечены ролью и должностью существенно влиять на решения о выборе стека и подходов в крупных компаниях. Поэтому, кажется, важно уже сегодня рассказать, что лежит в основе таких предположений.
С чего все начиналось
Начну с того, что до, примерно, 2019г подход “Архитектура как код” был скорее симпатичной теорией, в которой виделись некие призрачные перспективы создать практики ArchOps. Т.е. встроить в производственный процесс, который сегодня имеет зрелую практику DevOps, новый виток - Анализ и дизайн решений. Фактически, это управление архитектурой. Этот “Прекрасный мир с розовыми пони” должен выглядеть примерно так.
Уверен, что визионерские идеи, а может даже и частные практики возникали и ранее. Но именно с 2019г. лично я начал замечать возникновения физической реализации такого подхода. Т.е. из очень нечеткой теории начали возникать гипотезы и проверяться на практике. Из публичных материалов, в Российском сегменте, я бы выделил эти:
Но, пожалуй, я говорю про 2019г, отсчитывая вот от этого случайно прочитанного материала “Архитектура как код”, который вовлек меня в эту тему.
Следующая большая вещь (next big thing) в ИТ-архитектуре, безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в CI/CD pipeline.
Идея, выраженная в этом весьма коротком предложении, меня заворожила. Мне показалось, что это некий ИТ Грааль, прикоснувшись к которому, я смогу приобнять весь мной горячо любимый ИТ! Ощутить его целиком через волшебный архитектурный код.
Первый подход к снаряду
Проведенный анализ показал, что ИТ индустрия содержит ассортимент инструментов, которые предлагают подход описания кодом архитектурных артефактов. И даже есть практики - “Документация как код”.
Из однозначно стоящих внимания, т.к. заслужили заметные места в индустрии, можно выделить:
MarkDown - облегчённый язык разметки, созданный с целью обозначения форматирования в простом тексте;
PlantUML - позволяет создавать диаграммы из обычного текстового языка;
Mermaid - аналогично PlantUML позволяет создавать диаграммы из текста;
Structurizer - язык описания диаграмм кодом;
OpenAPI (Swagger) - язык описания интерфейсов для описания RESTful API;
AsyncAPI - язык для описания событийно-ориентированных сервисов.
Казалось, что собрав эти языки в ансамбль, можно написать правильный сценарий с музыкальным оформлением и он взорвется прекрасным шоу с невероятными акробатическими этюдами в стиле цирка Дю Солей! Ведь все просто: достаточно рядом с кодом положить описанную документацию с использованием вышеприведенных инструментов и мир ИТ уже не будет прежним! Я так и сделал.
Но, нет. Первая же репетиция показала, что медведи едут не в ту сторону, акробаты соскальзывают с трапеций, а солист картавит и заикается. В целом было весело. Приглашенные зрители не были разочарованы. Но вот говорить о том, что теперь можно было бы организовывать чёс по Забайкалью не приходилось.
Всё дело в том, что код документации направлен на одну цель - генерация визуального представления информации для считывания человеком. Он попросту не предназначен для выполнения иной роли. И не годится для достижения выше обозначенной “Великой Цели”. Полученный ценный опыт и вектор решения выявленных проблем был изложен в статье - “Архитектура рядом с кодом”.
Но этот, первый подход, продемонстрировал состоятельность идеи:
Запрос на подход действительно был. Организованное сообщество начало набирать своих первых членов, многие из которых стали его визионерами;
Коллеги живо включились в развитие подхода, принося новые идеи;
Возникли первые, единичные, инициативные внедрения;
Появившийся инструмент, в ходе развития подхода, получил крупный ландшафт для проверки гипотезы. Да, что уж… гигантский!
Ах…, вот, как всё устроено…
Деятельность сообщества, развитие инструмента и опыт его внедрения в разнообразных ландшафтах позволил провести глубокий анализ потребностей участников производства цифровых продуктов. Для начала, мы определили ключевых стейкхолдеров и их потребности. “Внезапно”, их состав оказался дифференцирован по уровню зрелости компании и конкретного бизнес-юнита. Из этого сформировались паттерны ландшафта производства цифровых продуктов. Отражу, наиболее яркие.
Сразу говорю, ни один паттерн не соответствует конкретной компании, это вольные, собирательные представления.
Цель: Выжить.
Признаки:
Небольшая численность. Примерно до 10 человек;
На продакта возложены практически все административные задачи, он хорошо погружен в детали производства;
Информационное поле компактное, подвижное, мутабельное;
Роли в команде часто смешиваются и передаются;
Участники хорошо знают своего клиента и ценность продукта для него;
Имеют представление об инвесторе и его ожиданиях. Иногда он вовлечен в процесс;
Доступные ресурсы ясны, но ограничены.
Потребности:
С наименьшими затратами давать максимальный результат направленный на подтверждения гипотезы стартапа;
Как можно быстрее выявлять затраты ресурсов на неперспективный вектор и прерывать его;
Управлять командной деятельностью с минимальными затратами ресурсов.
Ключевые проблемы:
Практически полная зависимость от решений продакта. Его смена маловероятна с приемлемыми последствиями для продукта;
Крайне болезненные эффекты от смены участников команды. Приводит к потере части информационного поля и значительным затратам на онбординг нового участника.
Для инвестора непрозрачны затраты и их качество. Часто это выражается в его чрезмерных желаниях Demo или отчетах, что отвлекает продакта и команду от создания value. Команда может не получить очередной транш инвестиций при отсутствии ценного, с точки зрения инвестора, результата.
Цель: Захват доли рынка.
Признаки:
У продукта есть бюджет и стратегия;
Продукт разделен на вертикали. Каждая вертикаль имеет собственного владельца и команду;
Только CPO видит продукт целиком. Члены команд имеют фрагментарное представление о клиенте;
CPO чаще всего слабо погружен в детали производства и делегирует это продактам команд и СТО;
В наличии коммунальные сервисы, обеспечивающие функционирование команд трайба;
Имеется развитая административная структура и общие процессы.
Потребности:
Достижение целевых бизнес-показателей;
Обеспечение роста команд и растущих команд необходимым;
Оркестровка деятельности команд для оптимизации использования ресурсов и достижения стратегических целей;
Контроль бюджета и качества его использования;
Ограниченная унификация и стандартизация процессов в производстве для выполнения SLA продукта и планирования выпусков релизов.
Ключевые проблемы:
Команды не являются владельцами коммунальных ресурсов и часто вступают в конфликт с друг другом для их привлечения. Затруднено планирование реализации фич из-за неясности в доступных ресурсах;
Выпуск фич вертикалей может сковываться из-за зависимостей друг от друга, что приводит к негативным эффектам на частоту выпуска и качество продукта в целом;
Команды затрудняются в понимании актуального ИТ ландшафта и перспективного, что приводит к серьезной деградации в области планирования фич вертикалей;
Необходимо минимизировать время на онбординг специалистов для быстрого наращивания ресурсной базы;
Поддержка продукта сталкивается с трудностями в локализации причин возникающей проблемы и поиском исполнителей для ее устранения, что негативно сказывается на клиентском опыте и бренде продукта;
Зоопарк унаследованных технологий от этапа “Стартап” затрудняет технологическое развитие продукта, что приводит к открытию окна возможностей для конкурентов.
Обратите внимание на то, что экосистема эта штука очень сложная. Но у неё простая идея - нужно обеспечить “все” потребности клиента. Она бывает настолько масштабна, что не может рассматриваться в отрыве от государства и мировой экономики в целом, т.к. способна влиять на них.
Наверное, экосистему можно сравнить с галактикой, где есть некий центр и гало - компании экосистемы, которые рождаются, развиваются, бывает, что угасают или выталкиваются в “межэкосистемное пространство”. А вокруг этих “звезд” крутятся планеты, на которых развивается своя жизнь.
К сожалению, у меня не было возможности сесть и обстоятельно пообщаться с создателями и владельцами экосистем, поэтому, нижеприведенный профиль - синтез результата анализа публичных материалов и доступных мне для учета фактов.
Цель: Глобальное доминирование.
Признаки:
Группа компаний, которая объявляет себя экосистемой, развивает единый бренд и строго следит за его образом;
Есть выраженный центр управления, где разрабатывается стратегия развития и контролируется ее реализация;
Системно развивает меню клиентских сервисов;
Наличие объединяющих элементов. Т.е. таких сервисов, которые формируют базовый образ экосистемы и обеспечивают непрерывность пользовательского пути клиента в ней. Например, авторизация;
Стимулирует положительную синергию внутри группы компаний, стараясь предоставить своим участникам радикальные конкурентные преимущества на их целевом рынке.
Потребности:
Реализация стратегии экосистемы;
Наращивание клиентского меню сервисов для удержания клиента внутри экосистемы;
Наличие информации о доступных ресурсах экосистемы для их эффективной утилизации (capability);
Доступ к необходимым ресурсам для выполнения стратегии развития;
Поддержание целевого образа бренда.
Ключевые проблемы:
Возникший инцидент у одного участника экосистемы влияет на всех через единый бренд;
Слабая доступность информации для участников экосистемы о развитии сервисов, степени их готовности и спецификации по интеграции затрудняют положительные синергетические эффекты, более того, могут порождать негативные;
Трудновыявляемые каскадные цепочки зависимостей внутренних сервисов экосистемы, способные вывести кластера пользовательского меню и радикально сказаться на пользовательском опыте и бренде;
Труднополучаемая объективная и актуальная информация о текущем состоянии экосистемы, необходимая для принятия решений и контроля реализации стратегии;
Из-за слабой доступности качественной информации, затруднено исследование возможностей и точек роста (capability).
Как я уже сказал, это малая часть проведенного анализа. Выраженных паттернов в разы больше. Когда проводился этот анализ, в голове не раз возникала мысль - “Как же тебя обнять-то мой любимый ИТ?…”
Причем здесь архитектура?
Удивительным образом, ни один профиль не сообщает о потребностях в управлении архитектурой… Почему? Все дело в том, что в действительности бизнес, на каком бы этапе зрелости он не находился и какого бы масштаба он не был, всегда имеет архитектуру. Просто потому, что:
Архитектура бизнеса, это устройство бизнеса. (c)
Каждый раз, когда мы говорим о потребностях бизнеса, мы определяем требования к его устройству, а равно - архитектуре.
Когда мы говорим о проблемах, мы говорим о недостатках его устройства - проблемах архитектуры.
Признаки же - симптомы принятых архитектурных решений.
Выходит так, что код архитектуры должен уметь описывать устройство бизнеса в той степени детализации, в которой он испытывает необходимость. Если нужно, до уровня устройства приложения, реализующего его продукт.
Вероятно может возникнуть вопрос - если архитектура так важна, то почему нет архитектора на диаграммах стейкхолдеров? В этот раз я их намеренно туда не поместил. Да, случается, что бизнес есть, он обладает успешным продуктом, а архитектора нет. Но, на самом деле это, конечно, не так. Архитектор это лишь роль и выполнять ее могут люди на разных должностях.
Продакт-менеджер это архитектор продукта. CTO это архитектор производства. CEO это архитектор компании. Разработчик, вполне может быть архитектором приложения. Все они принимают архитектурные решения по устройству доверенной им зоны.
Выделение должности “Архитектор” часто связано с потребностью в выделении функции управления архитектурой, для установки над ней специального контроля вышестоящего руководителя.
Чем поможет код архитектуры бизнесу?
Ответ крайне простой - документированием своего устройства. Достоверным описанием “как есть” для осознания того, чем бизнес обладает, чтобы смоделировать состояние “как будет” и провести его тестирование и развертывание принятого решения. Помните?
…. безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в ...
Код архитектуры, должен быть способен донести до точки развертывания замысел его создателя без искажения и подготовить условия для контроля его исполнения. Всё как в CI/CD pipline. Только, вот CI/CD это технологическая частность.
В идеале, код должен уметь описать цифровой двойник бизнеса. Любой его части.
Архитектор (Предприниматель) - владеет замыслом. Сосредотачивается на представлении и создании будущего компании.
Интегратор - сосредотачивается на объединении людей и помощи в построении личных и функциональных мостов между всеми членами команды для реализации замысла.
Производитель - сосредотачивается на конечном результате и делает так, чтобы конечный продукт или услуга соответствовали всем ожиданиям клиента.
Администратор - сосредотачивается на том, как выполняются задачи и требует, чтобы все остальные сотрудники соответствовали текущей политике, процедурам, формальностям и философии компании.
Вероятно, кто-то уже заметил сходимость ролей, обозначенных на скетче с теорией PAEI. Честно говоря, проводя анализ и приходя к такой концепции я сам с удивлением начал обнаруживать сходство. Думаю, что это неспроста.
Data Lake архитектурного кода выполняет роль цифрового двойника бизнеса. Он наполняется объектами архитектурного учета в той мере и качестве, который требуется домену работающему с ним. Подробнее идея рассмотрена в статье “Код архитектуры — это жидкость”.
Обратите внимание на компьютер зависший в правом верхнем углу. У него важная роль - Администратор. Это комплекс автоматизированных средств, позволяющий контролировать сходимость замысла, решений, реализации и факта. Он обнаруживает отклонения и информирует об этом необходимый домен в адекватной для него форме. Роль администратора на первом скетче выполняет, в нагрузку, каждая роль. По этой причине функция администрирования становится фрагментарной и мало эффективной. В этой же концепции, администратор “видит” все картину целиком. А правила для него определенные, контролируются бесстрастно и в режиме 24/7.
Вся эта магия становится возможной при наличии универсального кода архитектуры, который поддается контролю консистентности, достаточности и измерению его качества.
Также, средства автоматизации могут помочь с осознанием реального мира через реверс-архитектуру. Когда архитектура получается из цифровых следов продукта. Например, мы можем восстановить ИТ ландшафт из средств мониторинга. Отследить взаимодействия систем, используя, например, Istio.
Эффекты от наличия архитектурного Data Lake будут тем заметнее, чем сложнее организация. В стартапе информационное поле настолько компактное, что производитель практически всегда знает замысел, а архитектор реализацию. О реальном мире также можно сложить достаточно достоверное мнение. Но, и здесь, есть куда кода архитектуры подналить. Об этом позже.
Если же мы возьмем экосистему, то подход “архитектура как код”, кажется становится отличным средством управления ею. Как подтверждение, можно смело говорить, что запросы на цифровые двойники крупными организациями высказываются регулярно. Достаточно поискать упоминания в Интернет.
Не похоже, что стартапу это нужно…
С этим утверждением приходится работать постоянно. Я уверен, что нужно. Давайте разбираться.
Цель стартапа - выжить. Выжить, чтобы стать успешным бизнесом. И перейти в фазу бурного роста. Именно эта проблема возникает при переходе от проверки гипотезы к росту. Стартап часто не может масштабироваться из-за того, что в нем выстраивается ландшафт костылей. Не только ИТ костылей, а в целом. Целая тайга костылей. И после подтверждения гипотезы, бывает так, что лучше все начать с нуля.
В таком случае, продакт может всё бросить и пойти в другой стартап с грузом ценного опыта с формулировкой “Я перерос эту компанию”. Такое же поведение не чуждо и остальным членам команды. Когда они понимают, что остаются один на один с горой легаси и не реализуемыми задачами по продукту. В проигрыше остается только… инвестор. Выглядит это примерно так:
Конечно, это вырожденный кейс. И, конечно, разработчик совершенно ни в чем не виноват. Причина гибели “Классненького стартапа” - непонимание степени влияния подобных решений продактом. Но как бы то ни было, все участники этого стартапа получат выгоду за исключением инвестора.
Для инвестора код архитектуры может стать универсальным средством контроля над его активом. Давать возможность проводить его оценку в реальном времени. Отслеживать рост его инвестиционной привлекательности.
Очень важно знать не только финансовые показатели, который отражают на этапе стартапа только затраты, но и характеристики той “машинки по печатанию денег”, которая создается за твой счет, для принятия адекватных инвестиционных решений.
Как конкретно может помочь код архитектуры?
Пришло время подробно разобрать вышеописанные паттерны ландшафтов производства цифровых продуктов для причинения им добра. Сегодня фокусироваться будем на проблемах.
Описанные проблемы напрямую влияют на цель стартапа “Выжить”. Их устранение может радикально повлиять на успех инвестиций. Более того, появляется такая скрытая возможность как тиражирование успешной модели стартапа.
У трайба цель - захват доли рынка. Его сопровождает бурный рост. Всё ему подчинено и из этого формируются его проблемы. Удержать управляемость в этот период очень важно для того, чтобы не обошли конкуренты. Идея продукта уже известна на рынке и важно оставаться ее лидером.
Для доминирования экосистеме нужно хорошо понимать свои возможности и проблемы. Для этого она должна иметь возможность собственного исследования.
Для нее очень важно эффективно утилизировать доступные ресурсы, т.к. их привлечение извне, для ее масштаба и технологической зрелости, является затруднительным. Стараться не допускать “сжигания” ресурсов и потери важных компетенций.
Во всех рассмотренных паттернах наличие архитектурного кода, кажется, значительно повышает шансы на успех.
Стоп, а как мне это все поможет?
Хм…, пожалуй это самый сложный вопрос. Потому что у каждого из нас очень разные драйверы. Кто-то стремится растить свой личный бренд, кто-то хорошо делать свою работу, а для кого-то заработок ключевой драйвер.
Вот, давайте пока эти три драйвера и рассмотрим.
Но, еще, код архитектуры это канал связи. Аналогично как код, скажем NPM пакета, канал связи с его разработчиком, так и код архитектуры это канал связи с компанией. Доступное средство ее осознания и воздействия на нее.
Допустим, у тебя есть идея. Как обычно предлагают с ней поступить? Поместить в “банк идей”. И что с ней обычно бывает? Чаще всего она улетает в трэш. Обычно для этого две причины:
Ты плохо осведомлен о ситуации и твоя идея неприемлема;
Просто все заняты и им не до твоей идеи.
Но с подходом “архитектура как код”, ты можешь получить нужные тебе знания и предложить адекватную модификацию, оформив ее как Pull Request (PR). Работа над твоей идеей становится столь же понятной как работа с PR в кодовую базу владельца “того самого” пакета NPM.
Компания в выигрыше, ты тоже.
Что это за код такой, магический?
Подробно идею кода архитектуры, который используется в инструменте управления DocHub я излагал здесь. Но, будет уместно отразить принципы, которым он должен соответствовать:
Быть доброжелательным для любых архитектурных нотаций и подходов к управлению архитектурой. Стимулировать развитие управление архитектурой;
Быть простым. В ядре только: сущность и связь. Все доменные сущности и связи должны быть производными от ядровых и оформляться как доменные расширения;
Иметь все признаки данных. Поддаваться анализу для получения ценной информации из него без потери данных и их качества;
Подразумевать версии (поколения), описываемых им архитектурных объектов;
Должен поддерживать доменное устройство и DDD в частности. Допускать техническое объединение кодовых баз доменов без негативных эффектов;
Стимулировать развитие метамоделей доменов для их нужд;
Встраиваться в DevOps процессы.
Есть ли проблемы у подхода?
Полно! Во-первых, это инструментализация. DocHub сделал серьезный шаг навстречу будущему этого подхода. Но утверждать, что он близок к идеалу самонадеянно. Впереди большой путь:
Создание инструментов для реверc-архитектуры;
Инструменты Event Storming для этапа командного скетчирования архитектуры;
Модуль презентаций для широкого спектра стейкхолдеров;
Адекватные интерфейсы ввода/вывода для специалистов различного профиля;
И многое, многое другое…
Подход неизвестен бизнесу. Предстоит пройти большой путь, чтобы донести его ценность.
Конечно, есть определенное сопротивление и в сообществе архитекторов. Подход, в прямом смысле, меняет концепцию управления архитектурой. Далеко не каждый готов отказаться от годами наработанного опыта в привычных инструментах управления архитектурой.
А есть примеры?
Да. И это, пожалуй, самое главное, что делает лично меня уверенным в будущем подхода. Есть примеры успешных внедрений, которые заметно повлияли на процессы компаний в лучшую сторону. Раскрыть их в этой статье не выйдет из-за объема. Я оформляю кейсы в отдельные статьи.
Но, и завешивать “интригу”, кажется, неуместно. 03.02.2023 в 15:00 у нас пройдет первый “Очень круглый стол” в online формате, посвященный подходу “Архитектура как код”. Там мы:
Обсудим текущее положение дел в отрасли с применением подхода “Архитектура как код”;
Познакомимся с экспертами-практиками и их опытом в применении подхода;
Попробуем спрогнозировать его развитие;
Поговорим о том, с чего начать и как избежать ошибок при старте.
Присоединяйтесь к сообществу и следите за анонсом.
Ресурсы:
Сообщество: https://t.me/archascode
Репозиторий проекта - https://github.com/RabotaRu/DocHub
Сайт-демонстратор: https://dochub.info/
Статьи на тему: https://habr.com/ru/users/rpiontik/posts/
