Код архитектуры — это жидкость

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Более года развивается инструмент управления архитектурой DocHub. За это время он “повзрослел”. Изначальная, ключевая идея “Архитектора как код”, значительно обогатилась новой - “Архитектура как данные”. 

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

Предпосылки

В ходе внедрения DocHub, которое на данный момент насчитывает более десятка компаний разного масштаба и зрелости, были выявлены две фундаментальные закономерности:

1. Архитектуры нужно столько, сколько нужно, тогда, когда нужно

Думаю, не открою тайны, сказав, что мало кто управляет архитектурой в компании тотально, закрывая все слои (по TOGAF): Бизнес-архитектура; Архитектура данных; Архитектура приложений; Технологическая архитектура. 

Очевидно, что управлять нужно тем, что тебе помогает достичь твоей цели. Например, если нет цели создать ЦОД, кажется, не стоит фокусироваться на технологическом слое архитектуры.

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

И уж совсем вырожденный пример - стартап, где из архитектурных артефактов можно встретить чаще всего только контракты, которыми как-то управляют.

Но это все статика. Срез на конкретный момент времени. Все становится сильно сложнее, если посмотреть на проблему в динамике. Любая из таких компаний может изменить свои аппетиты в будущем. Причем как в большую, так и в меньшую сторону. Или вообще сместить фокус управления.

Наглядно раскрыта эволюция потребностей организаций в теории Ицхака Адизеса - Жизненный цикл организации.

В целом можно сказать, что качество управления архитектурой органически растет вместе с организацией. И где-то на уровне этапа “Стабильность” приобретает законченную форму.

Стоит выделить переход в этап “Юность”, как точку во времени, где кажется, возникает осознание необходимости управлять архитектурой системно. А также переход от “Расцвет” в “Стабильность”. В этот период компания меняет стратегию развития на минимизацию издержек. И управление архитектурой приобретает выраженный бюрократический характер. 

Но это лирическое отступление. Сутью закономерности же является то, что  архитектурная функция эволюционирует / приспосабливается к потребностям организации. Она не статична.

2. Архитектура нужна такая, какая нужна, какая не нужна - не нужна

Эволюция архитектурной функции сопровождается трансформацией ее артефактов. Казавшиеся вчера достаточными схемы, сегодня не обладают необходимой информативностью.

Число артефактов растет. Они устаревают. Формируется некое цифровое наследие, которое как чемодан без ручки. Нести тяжело, но выбросить очень жалко. Часто эти обстоятельства являются ключевым фактором соблюдения сегодня уже бессмысленных традиций в управлении архитектурой, возникших на заре формирования архитектурной функции в организации.

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

Порой некоторые организации осмысленно отказываются от управления архитектурой, чтобы не утонуть в бюрократии. Другие, внедряют инструмент управления архитектурой и проходят очень болезненный и долгий путь переноса содержимого своего “чемодана” на “антресоль” EAM Tool.

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

Эти, теперь уже кажущиеся очевидными закономерности, сформулировали новое требование к инструменту - поддержание эволюции архитектурной функции в организации. Инструмент должен не просто уметь масштабироваться, он должен эволюционировать вместе с организацией. Обеспечивать развивающуюся архитектурную функцию ценностью на каждом этапе ее развития. Взрослеть вместе с организацией.

Идея: признать свое несовершенство

Вышеописанные закономерности были выявлены в результате анализа весьма противоречивых требований разных организаций к инструменту при внедрении. Сначала эти требования казались простыми “хотелками”, которые можно “подружить”, реализовав совершенную метамодель и методологию. Просто нашей команде нужно потрудиться и их “родить”. Но все оказалось сложнее при детальном рассмотрении. 

Практика показывает, что при достаточно богатом зоопарке предлагаемых фреймворков, методологий и метамоделей уважаемых экспертов и экспертных сообществ, встретить идеальную имплементацию заложенных в них идей невозможно. 

Я использовал слово “невозможно” осознанно. Конечно, я отдаю себе отчет в том, что наша команда не может проанализировать весь мировой опыт. Но все же на этой формулировке настаиваю. Дело в том, что анализ стал базой для теории, которая стала подтверждаться раз за разом. Ее корень лежит в постулате: Идея полностью осознается только ее автором, а ее масштаб напрямую зависит от масштаба личности автора. Он ее доносит “миру” в той форме, которая для этого самого “мира” актуальна и приемлема. А “мир” склонен в ней видеть только то, что нужно ему через призму потребностей. Брать только то, что ему “под силу”. В итоге гарантированно возникает разрыв между генерацией идеи, ее передачей и имплементацией.

Графически это можно представить так:

Можно смело утверждать, что компетенция индивидуума или группы естественный образом ограничена, следовательно, происходит ограничение и самой идеи. Ведь изобрести можно что-то на базе чего-то. Будь ты хоть супер-гений, или вас десять таких, знать всего не выйдет. Просто потому, что пока идет постижение предметных областей, они продолжают расти и меняться. Причем, для “молодых” предметных областей рост может быть взрывной.

Созданная методология, а уж тем более метамодель, в итоге, всегда будет “ущербной”. Ее имплементация скорее компромисс с действительностью. Ее берут за основу просто потому, что ничего лучше нет.

Исторический пример: пока развивались “классические” методы проектного управления RUP, где архитектурная функция была доведена чуть не до совершенства, “внезапно”, подкрался VUCA мир… И казалось бы идеальные методологии управления архитектурой в Agile командах начали сыпаться как карточные домики.

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

В какой-то степени, огорченный этими выводами, я решил признать этот факт и посмотреть, что из этого выйдет…

Когда ты на дне, остается только всплыть

Пребывание в интеллектуальном тупике было недолгим. Опыт подсказал, что нужно искать идеи в существующих решениях. Если один человек не может закрыть потребности человечества, значит нужно причинить ему добро создав самоорганизующуюся систему, способную на это.

И такие системы прямо сейчас есть. Например, github. В нем человечество уже сейчас накапливает опыт и знания, умеет их адаптировать и применять. Также, яркими примерами могут быть пакетные менеджеры, которые помогают нам подключать заранее кем-то созданные компоненты в наше приложение.

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

Идея сформировалась простая - дать возможность расширять метамодель по воле пользователя DocHub. Сделать его инструментом не просто описания архитектуры, а инструментом развития методологий и метамоделей. Инструментом эволюции архитектурной функции.

Должно получиться как-то так:

Т.е. развитие метамодели и методологий не должно ограничиваться. Необходимо узаконить право на их адаптацию для конкретных предметных областей. Создать условия, когда они будут дополнять друг друга. Фактически, научить код архитектуры тому, что уже умеют “взрослые” фреймворки - переиспользовать мировой опыт.

Дело техники

Наконец можно закончить думать и начать кодить. Ура!

Как есть

Метамодель DocHub зашита в его код. В ней живут сущности:

  • docs - Документы поддерживают форматы: PlantUML; Mermaid; OpenAPI; AsyncAPI; Markdown; Table и Network. Это разнообразие позволяет покрыть, пожалуй, все потребности архитекторов и аналитиков в необходимых артефактах.

  • components - Компоненты - это базовые сущности. На их основе автоматически генерируются диаграммы связей.

  • aspects - Аспекты позволяют выделить архитектурные компоненты, реализующие определенный архитектурный аспект. Например, бизнес-функцию. Проще всего их воспринять как тэги, которым можно разметить архитектуру.

  • contexts - Контексты аграгируют архитектурные компоненты и представляют их в виде диаграммы.

  • datasets - Источники данных позволяют получить доступ к внешним или внутренним данным архитектуры.

  • rules - Правила умеют контролировать структуру и состав архитектурного кода. Этим достигается контроль целостности архитектурного репозитория.

Как видите метамодель невелика. Это неслучайно. Каждая из этих сущностей прошла жесткий отбор. Все, что можно было упростить - упрощалось. В целом, она успешно используется для описания архитектуры приложений.

Проблема в том, что это только один слой. Предстоит создать метамодели для: 

  • бизнес-архитектуры;

  • информационной архитектуры;

  • технической архитектуры.

Но… есть ненулевая вероятность, что эти слои распадутся на субслои, которыми захочется управлять отдельно. Например, архитектура данных, сетевая архитектура, архитектура ИБ и т.д. и т.п. Да, это не по феншую TOGAF, но так и не тогафом единым…

Еще интересней будет то, что каждая имплементация совершенно точно получит свои особенности. Например, бизнес-архитектура может иметь шаблон описания процессов, который утвержден приказом ГД в 1997г. Или техническая архитектура должна “собираться” из CMDB связывая объекты архитектурного учета с объектами в  ней по некому UUID. Вероятно, на каждую систему в арх репозитории может быть назначен курирующий архитектор и это очень важно знать. А в этой организации проходят архсоветы и управляют ADR. Вариантов очень много.

Выходит, что в инструменте сделано крайне мало. Впереди его ждет океан приключений с идеальным штормом.

Как будет

Ядровая метамодель DocHub должна кардинально “похудеть”. В коде останутся только сущности datasets и rules. Но появится новая - entities. Именно она станет прародителем всех иных сущностей, которые будут жить в специальных пакетах-расширениях метамодели.  В том числе, docs, components, aspects и contexts будут в основании иметь entities и переедут в базовый пакет-расширение.

Идею трансформации графически можно представить так: 

Целевая картина выглядит такая:

В этом новом “прекрасном мире” каждый может создать собственное расширение метамодели. При желании автора расширения он сможет поделиться им с сообществом, например, выложив его код в github.

Что уже есть

Уже создана сущность enities и даже успешно эксплуатируются. Есть пример применения реализующий нотацию C4 Model.

Прямо сегодня вы можете начать применять вышеописанные идеи на практике.

Что еще предстоит сделать

  • Определиться с описанием зависимостей пакетов расширений;

  • Создать пакетный менеджер;

  • Создать публичный реестр пакетов;

  • Доработать управление зависимостями в самих entities;

  • Мигрировать встроенные сущности в базовый пакет расширения.

Но самое главное, что предстоит сделать - набрать команду, которая доведет продукт до совершенства. Людей, которые обретут в продукте самореализацию. Примут непосредственное участие в формирование образа продукта. 

Это настоящий вызов в “новой” реальности. И все же я уверен, что такие люди есть и они также ищут проект, где смогут самореализоваться.

Послесловие

Я несколько раз переписывал статью. Перечитывая результат, мне казалось, что я построил слишком сложную повествовательную конструкцию. Или я пытаюсь передать свои переживания вместо сути идеи. Но раз за разом я так или иначе возвращался к необходимости широкого обоснования “очевидных” решений.

Хотя этой версией я все также недоволен, но надеюсь, что смог оставить главный смысл фокусом статьи.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Считаете ли вы полезной идею развития архитектурной функции сообществом?
100% Да 2
0% Нет 0
0% Идея красивая, но кажется не взлетит 0
0% Не понял идею 0
0% The Open Group наше все! 0
Проголосовали 2 пользователя. Воздержавшихся нет.
Источник: https://habr.com/ru/post/701050/


Интересные статьи

Интересные статьи

Продолжение. К предыдущим постам и карте цикла. Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы ул...
Все «за» и «против» 1С-Битрикс, какие есть альтернативы и что выгоднее знать разработчику? Читать далее
Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 ...
Каждый лишний элемент на сайте — это кнопка «Не купить», каждая непонятность или трудность, с которой сталкивается клиент — это крестик, закрывающий в браузере вкладку с вашим интернет-магазином.