Предпосылки
Ограничения бывают разные. Например, компания со своими процессами. Вы генерируете идею, и она тонет в бюрократии. Идея рассматривается долгими днями, неделями, месяцами…
К счастью, это ограничение можно снять:
Можно сменить среду. Уйти туда, где вы можете реализоваться;
Затеять свой интересный проект и пилить его запоями по ночам.
Есть еще путь - изменить саму среду. Но что-то мне подсказывает, что это путь “в один конец”. Проходя его, идеи и цели трансформируются.
Но есть и более глобальные ограничения. Можно сказать - фундаментальные. К таким ограничениям я отношу память, опыт, знания и время. Рамки некоторых ограничений можно раздвигать. Обучаясь, тренируясь, накапливая опыт. Но они будут оставаться с тобой всегда. А вот время...
Работа архитектором в Работа.ру я, непосредственно, проектирую две крупные системы. Также я выполняю роль корпоративного архитектора. Как вы думаете, меня хватает на все? Конечно нет.
У нас много команд. Они каждый день что-то пилят. Что-то катят. Описать происходящие можно вариацией известного анекдота: пока архитектор изучает наш ИТ ландшафт, мы его меняем.
Если задуматься, больше сотни людей, каждый день прокачивают свои навыки. Накапливают опыт. Пытаются затащить новые технологии. И если я буду пытаться все это возглавить, я автоматически стану “узким местом” для развития компании.
Больше архитекторов? Решение интересное, но бесперспективное. Дело в том, что нарушается Agile Manifesto. Команда теряет автономность. Возникают ограничения ее эффективности.
Пожалуй, идеальным решением может быть внедрение в каждую команду по одному архитектору. Но что он там будет делать 8 часов 5 дней в неделю? Для команды выделенная роль архитектора в подавляющем большинстве случаев избыточна. И архитектора обязательно чем-то донагрузят.
Но, стоп! Ведь команды прямо сейчас что-то пилят. Т.е. прямо сейчас они реализуют архитектурные решения. Получается, незримый архитектор есть в каждой команде. Он может концентрироваться в лиде или быть размазанным по всей команде. Он может быть плохим или хорошим. Но главное - он есть.
И мы задумались… а можно ли как-то использовать интеллектуальный потенциал команд консолидированно? Создать не просто успешные команды, а развить положительную синергию их деятельности. Первым шагом для нас стала версия DocHub, пропагандирующая принцип contract-first.
Настроив процессы развития контрактов через GitFlow, мы заметно расширили свои возможности. Теперь, каждая команда, не ожидая архитектора, может развивать контракты. При этом управляемость не ухудшилась, а улучшилась. Я стал выполнять роль ревьювера контрактов. Архитектора стало “больше”.
Вдохновленные этой историей, мы пошли дальше. DocHub позволил решить ряд проблем. Но далеко не все. Осталась главная проблема - целевое развитие архитектуры. Т.е. достижение командами состояния, отраженного в архитектуре - как будет.
Была проделана работа по анализу существующих инструментов, которые могли бы подойти нам. Ключевой идеей сразу стало развитии архитектуры через код. На горизонте забрезжил PlantUML.
Но есть проблема. Каждый раз, когда мы рассматриваем язык описания архитектуры, мы тут же упираемся в необходимость его знать. И, автоматически, поднимаем требования к нашим разработчикам. В воображении рисуется Уроборос (змея, кусающая себя за хвост).
Как известно, проблемы не приходят поодиночке. Допустим, мы заставим разработчиков выучить PlantUML. И даже заставим их вносить изменения в файлы, описывающие архитектуру. Но как это все собирать в кучу со всех команд? Как рендерить? В конфлюенсе?
И вот, наш бедный разработчик теперь должен писать что-то на PlantUML, в конфлюенсе. Пришли к тому, что было. Даже хуже. Нарастили ограничения.
Думаю, интригу я нагнал достаточно. Пора познакомить вас с новым DocHub. Теперь это инструмент управления архитектурой через код. Он должен значительно снизить наши ограничения. Позволить командам видеть весь актуальный ландшафт. А это, в свою очередь, приведет к той заветной положительной синергии.
Управление версиями архитектуры
В развивающихся проектах архитектура мутабельна. Стандартной ситуацией является одновременная проработка нескольких архитектурных решений, которые должны стать единым целым. Особенно явно эта проблема выражается при наличии нескольких автономных команд, создающих единую систему.
Для монокомандых систем проблема остается актуальной. Внезапное изменение приоритетов и требований приводит к накоплению противоречивых архитектурных решений. Формируется технический долг.
Аналогичные проблемы свойственны кодовой базе систем. В процессе параллельной разработки фич, разработчики сталкиваются с задачей объединения результата в релизы. Решается она через инкрементальное развитие кода. Популярным инструментом является git.
Если внезапно забыл как работать с гитом.
Практикуются различные методологии управления кодом. Из популярных можно выделить GitFlow и GitHub flow.
Идея заключается в том, что разработчик при создании новой фичи клонирует ветку (branch) общей кодовой базы в отдельную. В ней он ведет разработку. По завершению работы создается Pull request / Merge request. Это специальный, формализованный запрос в рамках системы управления версиями на объединение веток. Он оценивается (Code review) другими разработчиками. В случае положительного решения, изменения внедряются в общий код.
Решать запросы на объединение помогают инструменты сравнения, встроенные в системы управления версиями. Они наглядно отражают изменения в коде. Выявляют конфликты. Позволяют их устранять.
В отличие от процесса разработки, где все построено на коде, архитектура требует создания графических артефактов. Для этого используются визуальные редакторы. Объединение версий диаграмм является проблемой. Тратятся значительные ресурсы на механическую деятельность. А если вы ещё и дома, на диване, на ноутбуке с тачпадом, без мышки… Впрочем, что-то я отвлекся.
DocHub предлагает отказаться от использования визуальных редакторов в пользу описания архитектуры кодом. Использовать принципы управления архитектурой аналогично принципам управления кодовой базой. Для этого предоставляются четыре языка описания архитектуры:
PlantUML - позволяет создавать диаграммы из обычного текстового языка;
Markdown - язык разметки, созданный с целью обозначения форматирования в тексте;
Swagger - язык описания интерфейсов для описания RESTful API;
Манифесты - структурированные файлы в формате YAML/JSON для описания архитектурных объектов.
Таким образом, процесс развития архитектуры становится максимально близким к разработке систем. Это дает возможность, помимо решения основной проблемы (управление версиями), получить дополнительные преимущества:
Унифицировать процессы развития архитектуры и разработки;
Архитектурные артефакты могут быть размещены непосредственно в репозитории кодовой базы и развиваться одновременно с кодовой базой системы;
Возникает возможность управления архитектурными идеями через Pull request;
Создается база для взаимного проникновения экспертиз разработки и проектирования.
Одному из главных преимуществ мне хотелось бы посвятить отдельный раздел.
Управление децентрализованной архитектурой
Под “децентрализованной” понимается сложная, многокомпонентная архитектура системы, части которой распределены по командам разработки. Каждая команда развивает свой сегмент параллельно и независимо, но должна учитывать общую концепцию. Ярким примером является микросервисная архитектура.
На первый план здесь выходит синхронизация решений команд, влияющих на общий архитектурный ландшафт. Остро стоит вопрос управления технологическим стеком и переиспользования имеющихся в компании наработок.
Управление “архитектурой как код”, позволяет применить опыт Open Source сообществ. В этом случае существует центральный репозиторий с концептуальной архитектурой (как будет). Все имеют доступ к нему, получая необходимые сведения о планах развития. Изменения в репозиторий попадают через Pull requests. Ревьюверами являются техлидеры команд.
Таким образом достигается информирование об архитектурных решениях. Возникает консенсус. Происходит обмен опытом.
Описание архитектуры “как есть” остается в командах. Т.е., несмотря на то, что имеется централизованный репозиторий "как будет", у команд остается право на автономное принятие быстрых решений. Этот подход реализует Agile манифест. Если необходимо срочно внести обоснованные изменения в продукт, должна быть возможность это сделать. Такая ситуация считается инцидентом.
Противоречие с центральным репозиторием устраняется путем сверки “как есть” с “как будет”. Отклонения обосновываются и, с отставанием, вносятся. Таким образом, инцидентные решения остаются в поле управления.
Управление архитектурой холдинга (экосистем)
Под холдингом понимается группа компаний, развивающих цифровые продукты, имеющие потребность в интеграции с выраженным центром стратегического управления.
Холдинги имеют проблемы координации развития архитектуры экосистемы. Контроль достижения стратегических целей является ключевым для них.
Компании холдинга имеют разную степень автономности. Часто находятся на различных этапах развития. Это выражается в неоднородности процессов управления.
Таким образом, управление архитектурой экосистемы является нетривиальной задачей. DocHub предлагает и тут использовать принципы развития кодовой базы Open Source сообществами.
Центр в этом случае выступает майнтейнером (Maintainer) архитектурного кода. Он является владельцем центрального репозитория архитектуры. Устанавливает стандарты работы с ним.
Компании выступают в роли контрибьюторов (Contributors). У них есть собственный форк или ветка в центральном репозитории. Развитие архитектуры экосистемы ведется через Pull requests.
DocHub используется как универсальное средство представления артефактов экосистемы.
Архитектурные фасады
Под архитектурным фасадом понимается публичная часть архитектуры. Распространенным примером являются API-контракты сервиса.
Фасады могут иметь различную степень детализации и состав. В некоторых случаях для клиента достаточно только публикации контрактов. Но зачастую, у него возникает ряд вопросов по сценариям использования. Также может оказаться полезным отразить верхнеуровневую архитектуру внешних сервисов. Для решения этой задачи необходим комплект публичных артефактов.
DocHub с этой задачей хорошо справляется. Он может быть развернут в качестве архитектурного фасада. Внешние пользователи получают удобный интерфейс для изучения публичной архитектуры.
Посмотреть, потрогать
В отличии от первой версии DocHub, эта версия публикуется в альфе. Это обусловлено тем, что мы хотим получить как внутренние, так и внешние мнения об инструменте. Учесть их.
В настоящее время в нашей компании идет пилотное внедрение инструмента. О его результатах выйдет отдельная статья.
Живое демо можно посмотреть тут https://dochub.info/. Это развернутый DocHub, описывающий архитектуру самого себя.
Вы можете развернуть DocHub у себя. Но учтите, что он интенсивно допиливается. Ветка концепта - https://github.com/RabotaRu/DocHub/tree/archops-conception-v2 (readme устарело и будет обновлено. Честно-честно). Развертывание такое:
git clone https://github.com/RabotaRu/DocHub.git
cd DocHub
git checkout archops-conception-v2
npm install
npm run serveDocHub будет доступен по адресу: http://localhost:8080/
Планы
Мы надеемся привлечь комьюнити к развитию инструмента. Просим открыто выражать свои мнения о нем. Предлагаем генерировать идеи.
Ближайшие цели: внедрение инструмента и подведение итогов.
Ближайшие фичи:
Доработка механизма контроля консистентности архитектуры;
Сравнение версий;
Пользовательские запросы к манифестам на языке JSONata.
