Коллеги, в подходящем к финалу 2023г. у меня случилось два инсайта. Первый тревожный и, кажется, весьма очевидный, а второй - ободряющий. Первый заключается в том, что функция архитектора в текущем виде перестает быть востребованной. Второй в том, что у всех нас есть очень хорошие шансы быть успешными в новой эре - в эре управления архитектурой v2.0.
Статья не маленькая, т.к. тема сложная. Если читать лень, но интерес есть, то листай сразу к разделу "Хорошая новость". Там есть видео.
Классификация архитекторов
Для того, чтобы продемонстрировать наличие проблемы в текущей деятельности архитектора, требуется для начала провести анализ того, кто это такой - классический архитектор или ИТ Архитектор 1.0 (далее Архитектор 1.0)?
Развивая инструмент управления архитектурой, я имел возможность пообщаться с широким кругом ИТ архитекторов, что позволило мне сформулировать свою классификацию, для работы с их потребностями.
Ее образы явно преувеличены, чтобы выделить главные черты каждого класса. Однако в реальной жизни я не встречал никого, кто бы полностью соответствовал только одному образу. Итак:
Фантазер
Это яркий человек. Он обожает придумывать “идеальные решения, которые опередили свое время”. Причем настолько, что, иногда, технологий для их идей еще даже нет в планах человечества.
У него уйма энергии. Его часто не понимают и пытаются предотвратить внедрение придуманных им решений. Но тщетно.
Он чаще других меняет работу, не добившись результата на текущем месте по “независимым от него обстоятельствам”.
Архитектор-фантазер яркий драйвер изменений в компании (шило в …).
Диктатор
Ставит свой опыт и стандарты превыше всего. Требует неукоснительно следовать плану в его голове и на бумаге.
Он не сомневается в верности своих решений. Он требует их выполнять. Если что-то не “взлетело”, значит обязательно что-то сделали не так как было в плане.
Когда нужно довести дело до конца, это самый лучший кандидат. Да, все будут стонать и страдать по пути выполнения плана, но в конце будет яркая победа.
Всем будет совершенно ясно, благодаря кому она достигнута.
Летописец
Фиксирует решения, принятые без него. Важность своей работы видит не в конечном продукте, а в его достаточной документированности.
Чтобы все по полочкам. Чтобы по алфавиту. Чтобы только нужным шрифтом и с нужными отступами.
Очень важен в сложных организационных системах, где бюрократия - очевидное благо. Он “клей” жизненно необходимый этим структурам, чтобы они не разваливались.
Творец
Живет своим детищем. Видит перед собой цель - причинить человечеству Великую Систему для Всеобщего Блага.
Человечество старательно уворачивается и периодически ему мстит за это “ментальными пробоинами” в его прекрасном “белом лайнере” концептуально стройных систем.
Но он не унывает. Старательно заделывая “пробоины в лайнере” он с каждым разом делает его все более совершенным.
Если нужно разобраться в чем-то суперсложном - это про него. Но не стоит ждать от него скорых решений. Все будет продумано, консистентно, надежно и великолепно! Но не быстро.
Архитектор 1.0
Как я уже упомянул, реальный архитектор - это собирательный образ и если попытаться визуализировать среднестатистический профиль, то по результатом моего опыта, будет такая картина:
В большей части Архитектор 1.0 придает значение управлению артефактами. Нередко я встречался с архитекторами, которые только фиксировали результаты архитектурных решений команд на “архитекторском языке” и выполняли скорее административные функции по их “легализации”.
Также, ярко выражается диктаторская роль. В моей практике подавляющее большинством архитекторов топит за стандартизацию. Все, что можно стандартизировать - нужно стандартизировать.
Внезапно для меня, реже всего, я вижу в глазах архитекторов яркий огонек “Фантазера”. Он, конечно, случается, но, относительно иных аспектов, он заметен только при большом желании. “Фантазии” чаще всего делегируются в команды и архитектор выполняет скорее роль наставника и “приземлятора”.
На образ “Творца”, к великому сожалению, практически у всех архитекторов, остается совсем мало времени. Чаще всего, они видят себя именно такими, но, на практике, время тотально пожирают процессы диктаторства и летописи.
Причины, определяющие образ Архитектора 1.0
Сделав анализ, как мне кажется, я обнаружил три фундаментальные причины:
Аналоговость
Хотя это может показаться неожиданным, но Архитектор 1.0 в основном аналоговый. Он оперирует диаграммами в различных нотациях. Получает информацию о реальности из них же. Передает информацию также в аналоге. Разъясняет свой замысел, применяя их. Фактически, он ими мыслит. Поэтому вынужден накапливать “макулатуру” и тянуть роль “Летописца”.
Хотя сами диаграммы и хранятся в неких цифровых форматах (png, pdf, xml и т.п.), поддаются каталогизации, иногда индексации, но данные этих форматов хранят лишь информацию об изображении. Т.е. их смысл в том, чтобы визуализировать изображение и это изображение “подать” в глаз архитектору для осмысления. Ярким примером является язык ArchiMate.
Правда, нужно отметить, что есть и исключения. Одним из самых ярких и известных является BPMN XML, описывающий процессы. Эти артефакты вполне годятся для автоматизированного анализа и даже исполнения, но, к сожалению, это лишь малая часть того, с чем работает архитектор.
Если покажется, что я забыл про PlantUML, Mermaid, Structurizr и т.п., то нет. Это языки, которые в итоге призваны выдать все ту же диаграмму в глаз архитектору. Они не описывают архитектуру, они описывают ее графические образы.
Кастовость
Эта причина, в определенной мере, следует из предыдущей. Т.к. основной язык общения архитектора это диаграммы, то возникает особый мир смыслов и особый архитекторский язык, который стимулирует выделение некой “касты архитекторов”.
Этот “языковой барьер” создает трудности в общении как с клиентами, так и с реализаторами архитектурного замысла. Парадоксально, что хотя графическое выражение информации наиболее удобно для передачи между двумя людьми, изобразить ее для эффективного восприятия очень сложно. И вот, наш Архитектор 1.0 уже должен быть художником…
Для облегчения создания диаграмм, придуманы нотации. Некие стандарты графического представления передаваемой информации. Они действительно значительно упрощают жизнь архитектору. Позволяют обмениваться артефактами и понимать их в масштабе индустрии. Но, беда в том, что их нужно знать, чтобы использовать.
Архитектурное решение должно быть консистентным, полным, отвечать требованиям клиента и т.д. Проще всего достичь этого, создав некие готовые шаблоны проектирования - фреймворки. И вот, у нас уже подъехали стандарты.
Вышеперечисленные особенности производственного процесса становятся частью образовательной программы архитекторов. Часто и ярко подчеркиваются как требования к профилю специалиста при найме.
Существует естественный соблазн следовать этим практикам, что неминуемо добавляет в профиль “Диктатора”.
Обособленность
Чаще всего на проекте/продукте я встречаю одного архитектора. Хотя в сложных организационных структурах существует разнообразие архитектурных ролей и иерархии. Но, в редких случаях я видел, когда несколько архитекторов, как одна команда, что-то разрабатывали. Тем более, были единичные случаи, когда этот процесс являлся стандартным в организации.
Обычно архитектор занимается обособленным процессом проектирования, результат которого потом обсуждается на архитектурном совете и/или в команде.
Также сложно обнаружить артефакты успешной совместной работы над каким-то проектом архитекторов в открытых сообществах. Чаще встречается паттерн: один проект - один архитектор.
Что не так?
Все выше написанное проблему как таковую не формулирует. Это лишь анализ текущего положения дел, основанный на доступной мне аналитической базе. Проблема кроется в нарастающем разрыве между миром Архитектора 1.0 и остальным ИТ…
Остальной мир ИТ
Для того, чтобы наглядно увидеть формирующийся разрыв, требуется посмотреть на другие производственные роли, с которыми архитекторы чаще всего взаимодействуют.
Разработчики
Сегодня уникальное приложение может содержать свыше 95% не уникального кода. Это код, который подключается как зависимости, зависимости зависимостей, зависимости зависимостей зависимостей… думаю, дальнейший ряд понятен.
Современному разработчику доступна огромная OpenSource кодовая база. Она позволяет использовать себя как большой склад полуфабрикатов.
Но, помимо простого использования доступных компонентов, что, несомненно ускоряет сам процесс разработки, разработчик имеет возможность разобраться с их кодом. Тем самым нарастить свои компетенции.
Вокруг успешных компонентов развиваются сообщества, которые поддерживают их актуальность и поставляют на рынок ИТ экспертов.
Таким образом, разработчики обладают прекрасной способностью тиражировать как результат своего труда, так и свои компетенции. Отвечая на современные вызовы растущего ИТ. Многие компании вкладываются в OpenSource и охотно его используют, находя в нем несомненный плюс для себя.
DevOps`ы
Когда-то я жил в мире, где не было DevOps инженеров. В том мире за все ИТ, что не про программирование, отвечал сисадмин. Он жил в мире волшебных комбинаций кнопочек при инсталляции очередной версии Windows или MS SQL Server. Опытный сисадмин имел RW CD для того, чтобы туда накидывать “заклинания” по установке и удачные конфиги.
Ближе всего к современному облику DevOps-инженера были Linux сисадмины. Они уже тогда имели волшебные скрипты, а не просто инструкции по установке ПО. Многие из них могли заглянуть в код приложения и “подшаманить” его, если это нужно было.
Но все же сисадмины не идентифицировали себя как часть производственного процесса. Тем более, не видели себя его владельцем. Их не по-детски бомбило, когда их просили посмотреть в код приложения. Уж тем более, написать код его развертывания. В те далекие времена это была задача разработчика.
Мне кажется, что радикально мир сисадминов изменился с появлением виртуализации. Им пришлось массово осваивать написание скриптов для автоматизации развертывания в масштабах, ранее недоступных им. К приложениям появились новые требования по развертыванию без прямого взаимодействия с человеком. Появились новые возможности по управлению производственными контурами.
Уверен, что не только этот технологический прорыв решил судьбу DevOps, но я считаю, что он создал фундаментальные предпосылки для развития данного направления. Мне кажется, что именно тогда сисадмин пошел в код и начал получать от этого удовольствие.
Когда же “родился” DevOps-инженер, за счет перехода к описанию своей предметной области кодом, он получил все те преимущества, которыми обладал разработчик: переиспользование кода; развитие кода в сообществах; тиражирование экспертизы через код и т.д. У него появился и свой, инфраструктурный код, например, Terraform.
Тестировщики
Ручное тестирование, хотя и остается востребованным на ранних этапах развития продуктов, но очевидно, что сложные, развивающиеся приложения с внятным релизным циклом покрываются автоматизированным тестированием.
Естественно, это тоже код и все те же профиты.
Аналитики
DocOps уверенно заявляет о себе. Об этом свидетельствуют растущие сообщества и встраивание языков документирования (Markdown, PlantUML, Mermaid и т.п.) в популярные инструменты производства, такие как Confluence, GitLab, GitHub, различные IDE.
Документы, за счет специального кода, приобретают свойства кода приложений. Получают исполняемому логику, умеют переиспользоваться. Создавая, например, библиотеки нотаций.
Тревожная новость для Архитектора 1.0
Таким образом, ключевые производственные роли сегодня используют код для организации своих процессов и их автоматизации. Они развивают и тиражируют в сообществах свои практики делясь кодом. Растят экспертизу через него. Код предоставляет им возможность глубокой интеграции друг с другом.
Фактически, код создает для них единый производственный континуум. Но Архитектор 1.0 существует вне его…
Проблема
Теперь уже наглядно видно, что Архитектор 1.0 дистанцирован от производства. Это приводит к тому, что необходимость самой роли часто ставится под сомнение. Ее эффективность взаимодействия низка.
Часто в командах нет выделенной роли архитектора. Ее выполняет ведущий специалист реального производства. Что в очередной раз, практически, подчеркивает актуальность проблемы - необходимо встраивать архитектора в производство.
Архитектор нового поколения должен интегрироваться в производственный процесс, чтобы остаться актуальным в современном мире растущего ИТ. И для этого ему потребуется - код.
План прост:
Изобрести код архитектуры;
Разработать новые принципы управления архитектурой кодом.
Вероятно, может показаться, что кодом архитектуры можно объявить зарекомендовавшие себя языки диаграмм, например, все тот же PlantUML. Но я напомню, что эти языки описывают диаграммы. Т.е., взгляд на архитектуру с определенного ракурса. Для полного описания архитектурного замысла потребуется неопределенное количество диаграмм.
Коду архитектуры необходимы практически противоположные свойства - он должен уметь описывать цифровую модель, из которой будут генерироваться необходимые ракурсы ее рассмотрения - диаграммы (viewpoints).
Код архитектуры
Для того, чтобы решить эту задачу, код архитектуры должен иметь определенные свойства:
Машиноанализируемость
Ключевым свойством кода архитектуры должна стать возможность его анализа автоматизированными средствами. Т.е. описанная кодом архитектура должна позволять выполнять к себе запросы с различными целями.
Например:
Построить диаграмму взаимодействия компонентов;
Выполнить контроль принятых стандартов проектирования;
Отобразить технологический радар;
Определить степень соответствия решения требованию;
И т.д.
Человеко и машиночитаемость
Код архитектуры должен легко воспринимать как человек, так и машина. Он должен предоставлять возможность своей оптимизации для машинного чтения и исполнения. В то же время он должен оптимизироваться под особенности человеческого восприятия информации.
Хорошим примером для этого являются языки программирования, которые взаимодействуют с человеком на уровне понятного синтаксиса языка, но в то же время, результат работы человека может быть приведен в оптимальный для машины код исполнения.
Человеко и машиногенерируемость
Помимо требования к читаемости должно обеспечиваться требование и к удобной генерации кода как машиной, так и человеком. Это требование обусловлено необходимостью совмещать концептуальный слой архитектуры с объективным.
Концептуальный слой архитектуры, это описанный человеком архитектурный ландшафт. При его описании оператор может применять абстракции очень высокого уровня. Например, описывать одним “квадратиком” целую автоматизированную систему, процесс, или бизнес-способность.
Объективный слой, это слой, сгенерированный на основании цифровых следов реального архитектурного ландшафта. Например, полученная конфигурация взаимодействий микросервисов из Service Mesh.
Эти, столь разные слои, должны уметь эффективно смешиваться. Позволять размечать объекты друг-друга для формирования общей, полной и детальной картины архитектурного ландшафта как “as-is”, так и “to-be”.
Модульность
Модульность в языках программирования позволяет разбивать программу на отдельные компоненты, которые могут быть разработаны и тестированы независимо друг от друга. Это упрощает процесс разработки и поддержки программного обеспечения, позволяет повторно использовать код и улучшает его читаемость и понятность. Модульность также позволяет разработчикам работать параллельно над различными частями программы, что ускоряет процесс разработки.
Очевидно, что если архкоду предстоит глубоко интегрироваться в производственный процесс, это свойство ему потребуется.
Будет здорово, если в репозитории GitHub появится OpenSource архитектура успешного сервиса, которую можно будет просто подключить как модуль архкода, адаптировать под свой ландшафт и получить готовый продукт с высокой надежностью и доступностью за очень ограниченное время.
Принципы управления архитектурой 2.0
Очевидным преимуществом использования архкода, становится применение успешных практик ролей, давно использующих код. Управление версиями, удобные IDE для редактирования, линтеры, процессы код-ревью и многое другое становятся доступны Архитектору 2.0
Но код приложения или инфраструктуры это код, который после сборки трансформируется в законченный продукт. Код приложение компилируется в приложение, код инфраструктуры выполняется один раз для развертывания.
У архкода рантайм иной. Напомню, в нем встречаются два мира: концептуальный и объективный. Архкод должен описывать цифровую модель, которая постоянно развивается и сверяется с реальностью для очередного инкремента развития. Т.е., он исполняется постоянно как людьми, так и машинами, которые его меняют по ходу исполнения.
Эти процессы могут быть различны в разных командах. Они напрямую зависят от этапа зрелости процессов управления, релизного цикла, особенностей среды проектирования, исполнения и иных факторов. Можно утверждать, что команда с уникальным набором процессов и практик формирует домен управления архитектурой.
Код архитектуры должен обеспечивать оркестрацию и хореографию доменов управления архитектурой. Создавать единое информационное пространство для команд, но предоставлять необходимую свободу для их функционирования с учетом особенностей предметной области.
Федеративное управление архитектурой
Федеративное управление архитектурой рассматривается как инструмент управления архитектурой в сложных, неоднородных системах и системах с динамической (нарастающей) сложностью.
Федерация это совокупность доменов с автономным управлением, связанная в систему контрактами.
Для разделения на домены управления требуется определить критерии. Для каждого случая они могут быть уникальными. Например:
Организационная единица (департамент, управление, команда и т.д);
Продуктовая единица (цифровой продукт, вертикаль и т.д.);
Сервисная единица (сервис авторизации, сервис оплаты и т.д.).
При выделении домена необходимо стремиться к однородности процесса управления архитектурой в нем. Признаками однородности могут стать единые стандарты для домена, технологический стек, единый релизный цикл и т.д.
Взаимодействие доменов в федерации осуществляется через контракты. Контракт подразумевает доступ домена к информации об архитектуре федерации в обмен на обязательства предоставлять информацию о себе.
Структура и состав информации поступающей из федерации и из домена декларируется специальный метамоделью. Таким образом поддерживается необходимое качество и актуальность информации на уровне федерации.
После определения рамок домена управления и контрактов с ним, управление архитектурой передается в домен. Контролируется функционирование домена исключительно по выполнению контракта.
Внутри себя домен волен создавать собственную федерацию на иных принципах деления на домены, с локальными контрактами.
Расширяемая метамодель
Признав неоднородность ландшафта управления архитектурой, необходимо обеспечить архкод способностью адаптироваться под потребности доменов. С одной стороны он должен удовлетворять нужды домена, с другой - гарантировать выполнение контрактов с другими доменами.
Помочь в этом может расширяемая метамодель. Это большая тема, в которую лучше погрузиться почитав статью Код архитектуры — это жидкость.
Развитие открытым сообществом
Архкод должен обеспечить Архитектора 2.0 способностью делиться практиками и развивать их в сообществах, переиспользовать готовые кодовые базы архитектурных решений.
Уверен архкод обеспечит интеграцию с уже существующими сообществами обладающими состоявшимися практиками развития через код. Дополнит их.
Архитектор 2.0
Так кто такой Архитектор 2.0? Думаю проще всего показать это через дифференциацию его с Архитектором 1.0.
Архитектор 1.0 | Архитектор 2.0 | |
Основные производимые артефакты | Визуальные схемы | Цифровая модель выраженная архкодом |
Вовлеченность в производство | Использование «особого языка архитекторов» для передачи информации | Использование «языка производства» для интеграции в него |
Использование инструментов | Тяготение к проприетарным инструментам с жесткой методологией | Развитие инструментария и методологии в открытом сообществе |
Архитектурный продукт | Архитектурные решения | Архитектурные решения и практики их создания |
Изменение парадигмы управления архитектурой приводит к изменению профиля архитектора. Наблюдаемые мной изменения при реальном применении подхода выглядят так:
Архитектор 2.0 заметно уходит в область творца в основном за счет высвобождения своих ресурсов от генерации диаграмм и регулярного обновления их.
За счет вовлечения всех участников архитектурных преобразований в процесс проектирования, возрастает осознанность принятия арх решений, что приводит к снижению роли диктатора.
У Архитектора 2.0 появляется креатив, который выражается в развитии автоматизации своих процессов и интеграции с производством.
Фреймворк для Архитектора 2.0
Выше описанные принципы были сформулированы по результатом успешного внедрения практик управления архитектурой кодом в сообществе DocHub. Около двух лет мы накапливали его и решили создать фреймворк, который позволит тиражировать наши практики для всех желающих начать управлять архитектурой как цифровой моделью.
Сейчас идет пилотное применение фреймворка - SEAF. Это сложная работа. Мы собираем в стройную методологию опыт очень разных компаний. Но мы надеемся, что с 01.01.2024, когда будет выпущен публичный релиз, мир архитекторов уже не будет прежним.
Нас объединяет манифест фреймворка, которым, думаю, стоит поделиться уже сейчас:
Вклад сообщества в развитие фреймворка является наивысшей ценностью для нас.
Миссия сообщества SEAF - создание технологии цифровой моделей предприятия. Мы считаем, что достичь ее можно описывая архитектуру специальным кодом, поддающимся автоматизированному анализу.
Мы не противопоставляем SEAF другим фреймворкам. Наш принцип – использовать лучшее из них.
Мы считаем, что SEAF должен удовлетворять потребностям предприятий любого масштаба. Обеспечивать их ценностью на всех этапах развития.
Мы признаем, что архитектурная функция распределена между всеми участниками трансформаций, поэтому он основан на простоте и низком пороге входа для любого участника изменений. Наш фреймворк не требует выделенной роли архитектора.
Мы поставляем метамодель и методологию, которые должны адаптироваться и развиваться под потребности конкретного предприятия, выявленные домены и слои архитектуры.
Эти принципы мы создали на основе нашего успешного опыта управления архитектурой. Мы верим, что они наделяют SEAF уникальными способностями:
Стимулировать инновации архитектурной функции;
Аккумулировать и распространять лучшие практики;
Создавать условия для коллаборации в сложных системах управления.
Co-pilot для Архитектора 2.0
ИИ активно ищет себя. Учитывая наличие критической массы производственных ролей связанных с кодом, одной из первых заметных реализаций стал GitHub co-pilot. Этот трудяга способен встраиваться в нативные средства разработки и помогать создавать код.
Можно долго спорить о том, насколько он эффективен сейчас. Пожалуй, будет сложно ошибиться сказав, что он обязательно будет развиваться и будет становиться только лучше. Даже если не он, конкретно, то ему на смену придут другие.
Его способности ограничены датасетами. Сегодня накоплена огромная масса кода на различных языках программирования позволяющая создать их. Конечно, GitHub здесь имеет все преимущества.
Получив в руки код, Архитектор 2.0 сможет стать частью этого, набирающего обороты, тренда. Более того, мне кажется, что высокая интеграция архкода с кодом программирования и развертывания выведет сам процесс разработки на новый уровень.
Хорошая новость
Думаю, из статьи уже стало понятно, что у Архитектора 1.0 не проглядывается счастливого будущего. Но у него есть возможность провести апгрейд до Архитектор 2.0 уже сегодня.
Да, еще далеко не все гладко. Но уже пройден большой путь для обеспечения этого перехода. Устранены стоп-факторы. Ключевые гипотезы подтверждены. Базовые инструменты разработаны и предоставлены сообществу.
Сообщество растет. За год оно увеличилось почти в десять раз. В промышленной эксплуатации подход используют уже около десятка компаний. В разы больше компаний проводят пилоты. Мы активно делимся опытом и развиваем практики. Инструмент становится востребованным на рынке специалистов.
Тренд объективно нарастает. На конференциях он все более заметен. В этом году на ArchDays как минимум три доклада касались архкода. Наше сообщество представлял ГК Самолет, который выступил с докладом “Опыт использования подхода «Архитектура как код» в ГК Самолет”
На конференции FlowConf 2023, основной темой которой является “Бизнес-анализ”, доклад про “Архитектура как код” вызвал живой интерес. После доклада еще около 40 минут зрители задавали вопросы по нему. Познакомиться с выступлением можно прямо сейчас:
Присоединяйтесь!
Репозиторий DocHub - https://github.com/DocHubTeam/DocHub
Сайт-демонстратор: https://dochub.info/
Telegram группа DocHubTeam - t.me/archascode
Репозиторий примеров использования архкода участниками сообщества - https://github.com/rpiontik/DocHubExamples
Историю развития подхода можно проследить тут же, на Хабре - https://habr.com/ru/users/rpiontik/publications/articles/
Видео-Kickoff по DocHub - https://www.youtube.com/watch?v=A7U4KiE5uhQ
Познакомьтесь с реальными практиками нашего сообщества в митапах:
Давайте развивать современные подходы управления архитектурой совместно!
