DocHub создан в ответ на актуальные вызовы в управлении архитектурой предприятий и ИТ систем. В его основе лежит концепция "Архитектура как код", что позволяет использовать лучшие практики ИТ-индустрии в управлении архитектурой. Код архитектуры легко интегрируется с кодом инфраструктуры, приложений и т.д.
Параллельно с использованием архитектурного кода, DocHub предлагает традиционные инструменты для развития архитектурного репозитория:
- Визуальные редакторы диаграмм;
- Редакторы документов;
- Пользовательские формы.
Это становится возможным благодаря уникальной концепции метамодели DocHub. В нем метамодель представляет собой базовый кодовый слой, который по своим характеристикам аналогичен модулям приложений. Эти модули в DocHub называются "мета-пакетами". Они подключаются по мере необходимости для достижения конкретных целей, что позволяет добиваться оптимальных результатов в кратчайшие сроки. Большинство пользовательских сценариев можно реализовать, развивая метамодель.
Сам DocHub также основан на модульной архитектуре, что дает возможность легко расширять его функционал путем создания дополнительных модулей на JavaScript. Базовый функционал DocHub доступен в формате OpenSource и активно развивается организованным сообществом "Архитекторы 2.0", объединенным концепцией "Архитектура как код".
Миссией сообщества является создание и развитие технологии "цифрового тела организации" для вовлечения технологий ИИ в управление ей.
Для быстрого пользовательского погружения приглашаем в виртуальный тур по порталу "Добро пожаловать в DocHub".
Для архитекторов и аналитиков будет полезным курс "Погружение в технологию "Архитектура как код"".
Если вы хотите открыть для себя всю мощь подхода "Архитектура как код", то воспользуйтесь специальным электронным курсом "Создание цифровой модели", где вы сможете создать свою первую цифровую модель.
Примеры использования реальными пользователями вы найдете в GitHub репозитории. OpenSource версия DocHub также доступна в GitHub репозитории.
В основе DocHub лежит подход "Архитектура как код" (Architecture as a code), что наделяет его уникальными свойствами:
- Версионирование и контроль изменений: Архитектура как код позволяет использовать системы контроля версий (например, Git), что обеспечивает более эффективное управление изменениями и отслеживание истории архитектуры.
- Автоматизация: Возможность автоматизации процессов, таких как генерация документации, проверка соответствия стандартам и интеграция с CI/CD пайплайнами, делает управление архитектурой более гибким и быстрым.
- Модульность и повторное использование: Код можно разбивать на модули, что упрощает повторное использование архитектурных компонентов и их адаптацию к новым проектам.
- Интеграция с другими инструментами разработки: Архитектура как код легко интегрируется с инструментами разработки, что позволяет разработчикам и архитекторам работать в едином производственном континууме.
- Улучшенная коллаборация: Использование кода для описания архитектуры способствует лучшему взаимодействию между командами разработчиков и архитекторами, так как все участники могут работать с одним и тем же артефактом.
- Динамическое обновление: Архитектура может быть легко обновлена и изменена в ответ на изменения в требованиях или технологии, что делает ее более адаптивной.
- Тестируемость: Архитектурные решения можно тестировать так же, как и программный код, что позволяет выявлять проблемы на ранних стадиях.
- Документирование в процессе разработки: Документация создается автоматически на основе кода, что снижает вероятность устаревания документации и улучшает ее актуальность.
- Снижение барьера входа: Разработчики могут легче участвовать в развитии архитектуры, поскольку они уже знакомы с языками программирования и концепциями разработки.
Эти свойства делают DocHub более современным и подходящим для динамичной среды разработки (Agile ready) по сравнению с традиционными инструментами управления архитектурой.
DocHub является не просто средой управления артефактами. Его архитектурный код способен описывать цифровые модели, которые могут исполняться, что значительно расширяет полезные свойства DocHub:
- Визуализация и анализ: Цифровые модели позволяют визуализировать сложные системы и процессы, что помогает лучше понять их структуру и функционирование.
- Симуляция: Модели могут использоваться для симуляции различных сценариев и условий, что помогает предсказать поведение системы в реальном времени.
- Оптимизация: С помощью цифровых моделей можно анализировать и оптимизировать процессы, находя наиболее эффективные решения.
- Экономия ресурсов: Моделирование позволяет тестировать идеи и концепции без необходимости создания физических прототипов, что экономит время и деньги.
- Улучшение коммуникации: Цифровые модели служат общим и наглядным языком для различных специалистов, облегчая сотрудничество между командами.
- Принятия решений: Модели помогают в принятии обоснованных решений опираясь на данные и анализ.
- Анализ рисков: Позволяют оценить потенциальные риски и последствия, что важно для планирования и управления проектами.
- Инновации: Цифровые модели способствуют исследованию новых идей и технологий, позволяя быстро тестировать и внедрять инновации.
Таким образом, цифровые модели являются мощным инструментом для повышения эффективности, снижения затрат и улучшения качества продуктов и услуг.
Федеративное управление архитектурой организации имеет несколько ключевых преимуществ по сравнению с классическим методом единого репозитория:
-
Гибкость: Федеративный подход позволяет различным подразделениям или командам адаптировать архитектуру под свои уникальные потребности, что способствует более быстрой реакции на изменения в бизнесе.
-
Децентрализованное принятие решений: Команды могут принимать решения на уровне, близком к их работе, что ускоряет процесс разработки и внедрения новых решений.
-
Устойчивость к изменениям: В федеративной модели изменения в одной части системы не обязательно влияют на другие части, что снижает риск возникновения проблем при обновлениях или изменениях.
-
Повышенная вовлеченность: Подразделения имеют большую степень ответственности за свою часть архитектуры, что может повысить мотивацию и вовлеченность сотрудников.
-
Лучшая адаптация к локальным условиям: Федеративный подход позволяет учитывать специфические требования и контексты различных подразделений или регионов.
-
Снижение нагрузки на центральные команды: Централизованные команды могут сосредоточиться на стратегических инициативах, в то время как операционные задачи распределяются между различными подразделениями.
-
Инновации и эксперименты: Команды могут быстрее тестировать новые идеи и технологии без необходимости согласования со всеми уровнями управления.
-
Упрощение интеграции: Федеративная архитектура может облегчить интеграцию различных систем и технологий, так как каждая команда может выбирать наиболее подходящие решения для своих нужд.
-
Улучшение управления рисками: Разделение ответственности и децентрализация позволяют быстрее выявлять и реагировать на риски в конкретных областях.
-
Поддержка разнообразия технологий: Федеративный подход допускает использование различных технологий и платформ, что позволяет организациям оставаться конкурентоспособными и адаптивными.
Таким образом, федеративное управление архитектурой организации обеспечивает большую гибкость, адаптивность и скорость реагирования, что особенно важно в условиях быстро меняющегося бизнес-окружения.
Код архитектуры - ансамбль файлов на языках, решающих задачу описания архитектуры.
Решаемые проблемы:
- Управление версиями архитектуры;
- Управление децентрализованной архитектурой в Agile-ориентированных компаниях;
- Управление архитектурой холдинга (экосистем);
- Создание архитектурных фасадов.
В развивающихся проектах архитектура мутабельна. Стандартной ситуацией является одновременная проработка нескольких архитектурных решений, которые должны стать единым целым. Особенно выражена данная проблема при наличии нескольких автономных команд создающих единую систему.
Для монокомандых систем проблема остается актуальной. Внезапное изменение приоритетов и требований приводит к накапливанию противоречивых архитектурных решений. Формируется технический долг.
Аналогичные проблемы свойственны кодовой базе систем. В процессе параллельной разработки фич, разработчики сталкиваются с задачей объединения результата в релизы. Решается она через инкрементальное развитие кода. Популярным инструментом является - 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 можно представить Mind Map:
DocHub поставляется в составе двух компонентов в открытых исходных кодах:
- WEB портал - https://github.com/RabotaRu/DocHub
- Плагин для IDE JetBrains - https://github.com/RabotaRu/DocHubIdeaPlugin
Лицензия использования Apache-2.0 License