Корпоративная архитектура. Что важнее фреймворк или здравый смысл?
Всем привет, снова на связи Онто, и я, CEO этого проекта - Артём Варкулевич. Последние 10 лет я (в том числе) руковожу архитекторами в проектах для различных банков. Могу посмотреть на одну и ту же ситуацию и с точки зрения бизнеса, и с точки зрения архитектуры решений.
Очень частый вопрос, который задают нам начинающие ( и не очень ) архитекторы это: “А где у вас тут поддержка Archimate и/или TOGAF”
Ну и естественный ответ: Онто представляет собой мощную платформу, которая способствует совместному мышлению, упрощает моделирование и обеспечивает гибкость в работе с данными. Вы можете сделать из нее любой нужный вам инструмент. А вот про использование корпоративных фреймворков среди незрелых команд у меня есть некоторое сомнение. И вот почему.
Для начала нужно определиться с тем, какую ценность для бизнеса могут принести активности, направленные на формирование пула знаний корпоративной архитектуры. И это вопрос, представляющий наибольшую сложность. С моей точки зрения, как предпринимателя, знакомого с закулисьем ИТ архитектуры, правильный ответ такой: большая часть из этих инициатив не представляет ценности для бизнеса.
За 20 лет моей практики я работал с разными командами, которые можно разделить на несколько типов.
В случае незрелой архитектурной функции:
- Фантазеры. Фантазеры считают что функция корпоративной архитектуры в их лице принесет бизнесу существенную пользу. При этом у них:
- нет архитектурного репозитория. ( они не смогут направить вас в хранилище содержащее информацию например о реестре информационных систем компании );
- нет общего словаря с бизнесом, нет понимания бизнеса и связанных с ним общих принципов;
- занимаются исследованием бизнеса при помощи различных методик, подменяя функции подразделений бизнес- и системного анализа. Они называют этот процесс “восстановление архитектурной информации”;
- нет процесса поддержки модели, команды разработки решений не разделяют ценность или разделяют, но только на словах;
2. Художники. Ценность, которую выдают художники - это большое число малоактуальных диаграмм, так как разрабатываются они в основном на этапе проектирования решений, при этом обратная связь от команд развития не учитывается.
конечно же у них архитектурный репозиторий ориентирован на схемы не связанных между собой элементов;
нет общего словаря с бизнесом, нет понимания бизнеса и связанных с ним общих принципов;
- нет процесса поддержки модели, команды разработки решений не разделяют ценность или разделяют, но только на словах.
Зрелая же команда управления архитектурой гарантированно имеет:
- согласованные ресурсы компонентов архитектуры для референсов из различных источников;
- регламент для команд развития, направленный на поддержку общей модели (неважно чего, архитектуры решения или корпоративной);
- Есть явная зависимость бизнеса от ИТ и архитектуры, в которой бизнес определяет, что ему нужно, а архитектура определяет, где и как это должно быть реализовано.
- Есть различные архитектурные органы, деятельность которых направлена на решение рабочих разногласий.
Ну и так как я в основном работаю с финтехом, то яркие представители последней группы в целом на слуху. В принципе, только на этом уровне архитектурная функция имеет возможность поднимать вопросы использования подходов “Архитектура как код” и подобные.
Итак, зачем такое длинное вступление? Представителям первых двух групп архитекторов до начала какого-либо проектирования я обычно рекомендую оглядеться вокруг себя ( например, присмотреться к совещаниям, в которых они участвуют ). Если у встреч отсутствует единый базис в виде объектных репозиториев, на которые ссылаются все участники процесса, чтобы разговаривать на одном языке, то в первую очередь надо выбирать не фреймворк, а строить этот общий базис.
Общий базис у незрелой группы, недавно сформировавшейся из некоторого числа солюшнов, может быть только в виде тех сущностей, которыми они реально оперируют. В их классификации в целом, конечно, им может помочь тот или иной фреймворк. Но так как, число сущностей достаточно ограничено, то любой здравомыслящий архитектор может построить классификацию, не прибегая к услугам рекомендаций фреймворков. Фреймворки же можно будет начать использовать на более поздних этапах зрелости, но и тогда ваша модель наверняка будет значительно шире рекомендованной.
Уточним немного первоначальный вопрос: “Возможно ли в Онто описать модель предприятия в терминах Archimate?”
Ответ: Можно, но если вы оперируете реальными классами объектов вашего мира, то вы и сами не захотите жить в усредненном мире модели предназначенной для расширения.
Далее я не буду проводить соотнесение модели Archimate с собственной моделью проекта Онто, возникшей в результате эволюционного развития, потому что это в итоге оказалось бессмысленным для меня и как для руководителя компании, так и как для генерального конструктора платформы. Но попробуем все же вынести хоть какую-то пользу от применения модели ArchiMate Core Framework на модели нашего проекта.
Ключевым ограничением языка ArchiMate для меня является: “The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances.” Я это воспринимаю, как противоречие ключевой деятельности, во время которой при моделировании реальной системы вы будете чаще использовать реальные сущности ( модули, очереди, события ) нежели абстрактные типы.
Нарезаем архитектуру платформы Онто на слои, при необходимости сверяемся с GPT о назначении слоя.
Основной слой позволяет быстро обратиться к диаграммам, содержащим описания взаимодействий артефактов слоя. В случае со слоем бизнес-логики имеет следующие диаграммы:
Карта пользовательских историй;
Структура фич;
Архитектура Презентационного слоя (Presentation Layer)
На уровне архитектуры презентационного слоя мы ведем реестры сущностей из списка относящегося к этому слою:
Angular Компонент;
Компонент из библиотеки Онто;
- Использующий сервис;
- Множественный Сторедж Сервис;
- Примитивный Сторедж сервис;
- Страница;
- Фасад-сервис;
- Элемент интерфейса;
- Эмиттер сервис;
- Эмиттер события.
Таблицы позволяют быстро систематизировать большое число артефактов, добавить им свойства, создать, переименовать, посмотреть зависимости. Собственно, все то, из чего состоит управление архитектурным репозиторием.
Диаграммы позволяют в простой форме предоставить визуальную информацию о зависимостях между артефактами.
Ценность, обеспечиваемая нами слоем в передаче знаний внутри команды между UI/UX и фронтовыми разработчиками
Бизнес-логика (Business Logic Layer)
Слой-бизнес логики представлен дополнительными слоями:
- Реестр фич;
- Реестр эпиков;
- Реестр пользовательских историй.
Для каждого артефакта организуем поддержку жизненного цикла управления структурой данных на каждом этапе.
Поддержка жизненных циклов артефактов на Онто обеспечивает нам:
- Ускорение Разработки: Понимание текущего состояния артефактов и их истории изменений позволяет ускорить процесс разработки и сократить время на доработку продукта.
- Непрерывное Улучшение: Жизненные циклы артефактов в Онто поддерживают принципы непрерывного улучшения, позволяя командам анализировать прошлые решения и результаты для оптимизации будущих действий.
- Управление Знаниями: Жизненные циклы артефактов создают богатую базу знаний, которая может быть использована для обучения новых сотрудников и передачи ценных знаний внутри компании.
- Поддержка Масштабируемости: Способность управлять жизненными циклами артефактов делает масштабирование процессов разработки более управляемым и предсказуемым.
Ключевая ценность, обеспечиваемая для нас этим слоем - это планомерное развитие платформы. Этот слой позволяет формировать дорожную карту развития, собирать и выращивать идеи, а также планировать их реализацию О том, как мы воплощаем идеи в жизнь я писал в предыдущей статье. На этом слое мы декомпозируем идеи на пользовательские истории, собираем из них эпики и фичи, контролируем взаимозависимости. Это дает нам возможность быстро решать конфликты планирования за счет прозрачного определения зависимостей. Также этот слой предоставляет нам основу для разработки архитектурных скетчей и дальнейшей реализации. На этом же слое ведем и тезаурус проекта.
Слой сервисов (Service Layer)
На этом слое мы ведем реестры артефактов:
- Приложения;
- Программное обеспечение;
- Репозитории кода;
- Сервисы платформы;
- API ( rest, сокеты, очереди ).
Ценность слоя в том, что он обеспечивает меня, как архитектора сервиса, инструментарием для построения основных элементов нашей ценности.
Это - архитектурные скетчи. Ранее я уже писал, что именно скетч - ключевой поставщик ценности синхронизации знания внутри команды. При проработке скетча мы получаем на 90% готовое решение, которое в таком же виде и пойдет на прод. Оставшиеся 10% добираются на этапе разработки и тестирования. Ключевая ценность для команды - это обеспечение прозрачности в разработке. Взаимоблокирующие доработки фактически невозможны, и мы не тратим время на решение конфликтов. Только чистое кодирование. Кроме того, на этом слое мы замыкаем зависимости бизнес-архитектуры до уровня API, где мы можем отслеживать причины появления конкретных артефактов и влияния на них задач из спринтов.
Слой инфраструктуры (Infrastructure Layer)
На этом слое мы ведем реестры артефактов:
Окружения;
Контейнеры;
- Развертывания ( версия ПО );
- Базы данных;
- Брокеры сообщений;
- Группы безопасности;
- Домены;
- Подсети;
- Виртуальные машины;
- Сервисы поставщиков;
- Поставщики.
Ценность, предоставляемая слоем, состоит в возможностях оптимизации расходов, связанных с затратами на оборудование и услуги, которые мы закупаем у внешних поставщиков.
Например, после того, как мы с нашим девопс свели все данные о контейнерах в едином реестре у меня возникла - , что надо продолжать инвестировать в развитие инфраструктуры и планировать переезд на среду контейнеризации. Этот слой напрямую на разработку не влияет, зато дает возможность быстро находить дополнительную информацию о зависимостях сервисов.
Слои из списка пока нами не поддерживаются в описаниях:
- Слой управления (Management Layer);
- Слой безопасности (Security Layer);
- Слой доступа к данным (Data Access Layer);
- Слой интеграции (Integration Layer).
Вывод:
Как документ еще не является знанием об устройстве какого-то процесса, так и мегабайты данных в корпоративных СУЗах не представляют собой ценности без грамотного переводчика. То же самое касается и архитектурных репозиториев, которые используются как хранилище картинок для согласования с ИБ.
Моделирование в Онто демонстрирует свою эффективность и превосходство перед ArchiMate в нескольких ключевых областях. Во-первых, Онто позволяет пользователям мыслить и моделировать в реальных терминах, что сокращает когнитивный разрыв между концепциями предметной области и их представлением в модели. Это означает, что модели в Онто являются интуитивно понятными и ближе к естественному пониманию командой реальных бизнес-процессов и IT-структур.
Во-вторых, Онто избавляет от необходимости тратить время на мапинг сущностей. Это - важное преимущество. В ArchiMate новые проекты часто начинаются с определения и связывания типовых элементов модели, что требует дополнительных усилий для корректного отображения реальных объектов и их отношений. Онто же позволяет быстрее переходить к сути задачи, поскольку предоставляет готовые к использованию конструкции, которые легко адаптировать под конкретные нужды проекта.
Третий момент - экономия времени на обучение. ArchiMate требует погружения в специфику языка и его нотации, что может стать препятствием для новых пользователей. Онто, напротив, позволяет быстрее приступить к работе, минимизируя кривую обучения благодаря более простому и понятному подходу. Пользователи могут концентрироваться на моделировании, не тратя время на освоение сложных архитектурных языков.
Эти ключевые аспекты объясняют, почему начало работы с моделированием в Онто может быть предпочтительнее, особенно когда цель заключается в быстром переходе к практическому моделированию без глубокого изучения специализированных нотаций. Моделирование на Онто предлагает гибкий и эффективный способ создания архитектурных моделей, что делает его ценным инструментом для команд любого уровня зрелости в области архитектуры предприятий.
Моделирование в Онто представляет собой переворот в управлении корпоративными системами управления знаниями (СУЗ), вдыхая жизнь в аккумулированные данные и информацию. В отличие от традиционных подходов, которые часто приводят к статичным, неактивным наборам данных, Онто активизирует знания, превращая их в динамичные, интерактивные модели, которые отражают реальные процессы и связи внутри компании. Это не только облегчает понимание сложных систем, но и способствует их непрерывному улучшению и адаптации к меняющимся условиям.
Архитектурные репозитории, наполненные данными из Онто, приобретают новое измерение смысла, становясь более чем просто хранилищами информации. Они превращаются в живые экосистемы, где каждый артефакт и связь имеют четко определенное значение и взаимосвязь, способствующие более глубокому анализу и обоснованному принятию решений. Таким образом, Онто стимулирует активное использование корпоративных знаний, делая архитектурные репозитории истинно функциональными инструментами стратегического управления и инноваций.
Артём, спасибо за статью!
Всегда рад поделиться болью 😂