Fundamentals

Цели SEAF  #

Цели SEAF подробно раскрыты на странице Цели SEAF.

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

Цели второго уровня:

  • G1. Предоставить конкурентные преимущества компании при достижении ею ее бизнес-целей. Позволить устанавливать новые цели, которые были недостижимы раньше.

  • G2. Организовать и повысить качество архитектурной функции в ДКА ДЗО, ДЗО/ГПГ Группы (в "экосистеме").

  • G3. Достичь успеха на профессиональном пути развития человека через применение архитектурных компетенций, полученных из SEAF. Найти и вовлечь "кадры" для развития свода знаний SEAF

В рамках достижения указанных целей последующие стримы разделяются на три ключевых направления (группы)

  1. Управление архитектурой компании

  2. Управление архитектурой Группы компаний

  3. Консалтинг на основе SEAF

Цели публикации SEAF #

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

SEAF (в открытой части) публикуется для следующих практических целей:

  1. Привлечения экспертов из компаний Группы «Сбер» к улучшению, совместной разработке и использованию методологии и программного обеспечения SEAF (Продукта SEAF).

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

  3. Распространения и продвижения SEAF в различных сообществах (ИТ-специалистов, аналитиков, системных и/или корпоративных архитекторов и т.п.).

  4. Привлечения квалифицированных кадров для ПАО Сбербанк (далее - Банк) и развития SEAF (посредством сообществ).

Процесс публикации SEAF в той части, которая поддерживает заявленные цели со стороны Сбера, является частью производственного процесса SEAF в ДКА ДЗО.

Публикация SEAF не является "самоцелью".

Выгоды (ценности) для Банка от публикации SEAF #

Выгодами для Банка от публикации SEAF являются:

  1. Повышение уровня доверия среди партнеров к методологии и программному обеспечению, разрабатываемому и распространяемому Банком.

  2. Повышение узнаваемости бренда Банка в ИТ-сообществе и в целом - развития сообществ на базе продукта SEAF.

  3. Привлечение лучших экспертов как из Группы "Сбер", так и внешнего рынка, к улучшению продуктов Банка.

  4. Возможность привлечения (хантинга) любых внешних экспертов в целевых предметных областях через механизмы работы профессиональных сообществ через SEAF как один из каналов (одну из площадок).

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

  6. SEAF замещает в России другие фреймворки ввиду введенного санкционного режима, ограничивающего участие граждан РФ в их освоении, применении и развитии (блокировка учетных записей, невозможность подтвердить имеющиеся сертификаты и пр.). Сбер использует сложившуся ситуацию для создания открытого конкурентного отечественного фреймворка с потенциалом международного признания. (Ценность "ввод санкций приводит к созданию новых перспективных продуктов").

Правовые основания разработки SEAF #

SEAF разрабатывается и публикуется на основании Распоряжения по Департаменту корпоративной архитектуры (далее - ДКА) от **.**.2024 № **-***/**-*  "О публикации репозиториев SEAF на внешних облачных сервисах GitVerse, GitHub" (далее - Распоряжение). 

Структурным подразделением - владельцем SEAF внутри Сбера является ДКА.  Решение о публикации  материалов (репозиториев) SEAF принимает подразделение-владелец SEAF, что отражается в выпуске организационно-распорядительного документа (распоряжения) по подразделению ДКА о публикации SEAF на внешних сервисах GitHub, GitVerse.

Подразделением - разработчиком и центром разработки SEAF внутри ДКА является ДКА ДЗО (отв. - М. Григорян), в чью сферу ответственности входит управление ИТ-архитектурой Группы Сбер.

Источники требований к процессу разработки SEAF в Сбер #

Ключевыми группами/источниками требований для разработки SEAF являются:

  1. Цели создания SEAF как продукта

  2. Требования производственного процесса публикации и стандарта FOSS Сбера (в первую очередь в части референсного инструмента SEAF, разрабатываемого с привлечением ресурсов Сбера)

  3. Критерии и процедуры ("механики") отнесения материалов к публикуемым в соответствии с ВНД Банка и целями публикации SEAF. В соответствии с требованиями Стандарта №4727, ч. 4, ДКА как владелец вправе принять решение о его признании соответствующим категории К-4 и публикации.

  4. Требования кибербезопасности (безопасности информации) и ВНД Сбера

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

Сервисы для распределенной разработки SEAF и управления версионированием #

Распоряжением устанавливаются публичные сервисы, в которые возможна публикация материалов сотрудниками Сбера:

  1. В пространстве seafteam* на публичном сервисе GitHub**

  2. В пространстве seafteam* на публичном сервисе** GitVerse**

Для внутренней (в Сбер) разработки элементов SEAF, не являющихся публичными (или в отношении которых не принято решение о возможности публикации), используется bitbacket.

*В соответствии с процессом разработки (производственным процессом SEAF), возможна работа с личными форками целевых репозиториев и создание через них PR, MR в целевые репозитории SEAF.

**Работа в публичном репозитории GitHub ведется с помощью личных учетных записей сотрудников, ввиду чего возможны блокировки УЗ со стороны сервиса GitHub в случае работы с территории Крыма или других территорий РФ. В таких случаях рекомендуется работать с базовым репозиторием GitVerse

<Возможно перенести ниже, где раскрывается процесс разработки>.

<Взаимно подменяются понятия публикации и публичной разработки>

<вводится понятие производственноно процесса, но оно не раскрыто. >

Обязательные требования для оценки возможности публикации информации #

Любой контрибьютор SEAF из числа сотрудников Сбера должен руководствоваться требованиями безопасности публикуемой информации в соответствии с ВНД, которые включают, но не ограничиваются следующими требованиями:

  1. Публикуемая информация не должна содержать информацию категории конфиденциальности К1/К2. Например, публикуемая информация не должна содержать наименования и реквизиты внутренних нормативных документов Банка, персональные данные (в том числе сотрудников Сбера, за исключением случаев, когда сотрудник дает разрешение на публикацию таких данных) и т.д. 

  2. Публикуемая информация (в первую очередь в инструменте) не должна содержать в коде известные уязвимости. Исходный код должен быть проверен на известные уязвимости с помощью Security Quality Gate.

  3. Публикуемая информация не должна приводить к возникновению или реализации рисков безопасности. Например, в публичной части SEAF публикуются отдельные примеры архитектурных требований Сборника стандартов ДЗО и ДБ для целей демонстрации методологии, валидации, проектирования сервисов. Однако н в публичной части SEAF не публикуется полный перечень требований Сборника стандартов ДЗО и ДБ. Требования Сборника в составе SEAF предоставляются в качестве отдельного продукта только для дочерних и зависимых обществ, дочерних банков и Генеральных партнеров Группы по закрытым каналам передачи информации.

<если это требования для сотрудников Сбера, то по идее это можно оставить только в версии для Сбера>

<процессы разработки и контрибьютинга в СЕАФ будут и для Сбера, и для внешних участников. Их можно разделять и детально описывать. Для внешних участников. Нужно провексти границы в парадигме "свое-общее". Нужно чтобы это было разъяснено в начале документа видимо>

 SEAF CORE CONCEPTS #

Манифест SEAF. Ценности и намерения #

  1. SEAF - это open-source продукт. Сбер (и организации Группы) являются первыми организациями, сделавшими вклад в SEAF. Любая организация может применять и развивать SEAF.

  2. Использование SEAF любой организацией для управления своими продуктами является наивысшей ценностью для контрибьюторов.

  3. SEAF использует подход "архитектура как код" (Architecture as Code, или AaC).

  4. Архитектура и архитектурная функция есть предмет и инструмент управления организацией. Архитектурная функция распределена между всеми участниками организации.

  5. SEAF применяется и адаптируется под специфические потребности организации самой организацией, в том числе с использованием услуг консалтинга.

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

  7. Внедрение SEAF в организации позволяет:

    • Cтимулировать инновации и создание коммерчески успешных продуктов;

    • Аккумулировать и применять лучшие практики и знания;

    • Создавать условия для сотрудничества в сложных системах управления.

  8. SEAF служит для преодоления сложности управления системами, построения и переиспользования архитектурных абстракций.

Открытый исходный код (Open Source): Мы, сообщество разработчиков и пользователей SEAF, объединяемся для создания открытого архитектурного фреймворка, способного помочь организациям эффективно управлять сложными системами. SEAF является проектом с открытым исходным кодом (Open Source), доступным для всех. Мы верим, что совместное использование знаний способствует развитию лучших архитектурных практик, инновациям и качеству.

Высшая ценность — использование SEAF организациями: Это подтверждает для создателей полезность и актуальность нашего фреймворка. Sber — первый контрибьютор SEAF, заложивший основу фреймворка на фундаменте накопленных знаний об управлении архитектурой в Группе и лучших практиках управления в ДЗО Группы. Sber вдохновляет другие организации и практиков присоединиться к развитию фреймворка. Наш успех измеряется реальным влиянием на улучшение архитектурных процессов и предоставляет организациям конкурентные преимущества.

Доступность для вклада каждого: Мы приветствуем участие всех заинтересованныех сторон. Любой может внести свой вклад в развитие SEAF, независимо от опыта и положения. Мы поощряем участие и ценим разнообразие идей и опыта. 

Подход "Architecture as Code": SEAF использует принцип "Архитектура как код", обеспечивая прозрачность, воспроизводимость и автоматизацию архитектурных решений.

Архитектура и архитектурная функция как управленческий инструмент: Мы рассматриваем архитектуру не только как объект или набор технических решений, но и как инструмент управления организации на всех уровнях принятия решений, способствующий согласованности и эффективности.

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

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

Преодоление сложности систем: Основная цель SEAF — помочь организациям справиться со сложностью современных систем, фокусируясь на создании и развитии продуктов организации и предоставлении для этого структурированного подхода в современных условиях.

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

Целевая аудитория SEAF #

  • Бизнес-аналитики

  • Системные аналитики

  • Любые продуктовые команды, начинающие создавать и развивающие свои цифровые продукты на базе open-source решений

  • Системные и корпоративные архитекторы

  • Владельцы, архитекторы и менеджеры продуктов

  • Разработчики продуктов

  • Любые участники архитектурной функции организации, в том числе ответственные за организацию и результаты архитектурной функции

  • Руководители, в чьей зоне ответственности находится создание продуктов организации

SEAF развивается, и мы изобретаем и описываем полезные сценарии использования SEAF, изучая потребности нашей целевой аудитории.

Ценности SEAF для целевой аудитории #

Ценностное предложение для системных и бизнес-аналитиков #

В состав целевой аудиторией SEAF входят бизнес- и системные аналитики (потенциальные бизнес- и системные/корпоративные архитекторы) различных уровней подготовки. 

Сферой интересов аналитиков обычно является проектирование информационных систем, своды знаний (например, BABOK), процессные фреймворки (например, BPM CBOK - свод знаний по управлению бизнес-процессами), eTOM, нотации EPC, BPMN, UML и другие.

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

Ценности SEAF для бизнес- и системных аналитиков:

  1. Архитектурный код и данные, которые аналитики напишут при проектировании в своей части (на своем уровне), - станет "скелетом" для дальнейшей разработки ИТ-систем, которые они проектировали. Код аналитика продолжает жить в кодовой базе продукта или проекта и далее "обрастает" кодом системы. Это единый язык описания. Аналитики чаще всего боятся писать код, однако SEAF объясняет, почему бояться в данном контексте написания кода не нужно. В рамках работы в SEAF предлагается использовать и в коллаборации создавать методики написания полезного для проектирования системы кода. В "идеальной картине мира SEAF", разработчики не боятся пускать аналитика в код.… Условно можно считать, что у программиста - исполняемый код, а у аналитика, проектирующего систему в парадигме SEAF, - это код, относительно которого должен верифицироваться или наполняться исполняемый код. Аналитик и архитектор создают архитектурные метаданные и код, являющиеся частью создаваемых продуктов или систем. У аналитика имеется свое пространство для написания кода, описывающего метаструктуру программы или системы.

  2. Использование в работе между аналитиками, архитекторами, владельцами продукта (или системы) Digital ADR - исходно интегрированных с кодовой базой продукта записей развития его архитектуры.  Digital ADR являются частью метаданных, которые ведут аналитики.

  3. "Документация рядом с кодом" и "Требования рядом с кодом"- ценности, являющиеся частью SEAF. В парадигме SEAF имеется четкая связь между требованиями и компонентами создаваемой системы с кодом. Проектная документация становится частью исходного кода (кодовой базы продукта) и живет (развивается) вместе с кодом. Большой ценностью является прозрачная для аналитика трассировка требований до реальных компонентов систем, сервисов, продуктов.

  4. Результат работы бизнес-аналитика в парадигме SEAF - то, с чем работает непосредственно разработчик, что приводит к повышению востребованности аналитика в сквозном процессе производства информационных систем или цифровых продуктов. Имя аналитика остается остается в аннотациях к коду (коммитах) создаваемого продукта или сервиса. В традиционном подходе аналитик пишет проектные документы, востребованные только на текущем или следующем этапе проекта, после чего в них мало кто смотрит. Получается, что традиционные артефакты проектирования (по ГОСТ 34 или в других подходах) создаются и актуальны только на момент создания системы или продукта. В подходе SEAF он (архитектурный код и данные) востребованы и после создания системы или продукта: в ходе его эксплуатации сопровождения, в ходе управления изменениями, в ходе его последующей модернизации (рефакторинга, импортозамещения, миграции и т.п.). Аналитик становится "со-создателем" системы, получая больше возможностей влияния и вовлечения в процесс производства, поддержки и развития.

  5. Благодаря этому подходу аналитики, разработчики и архитекторы сходятся на Едином артефакте - кодовой базе продукта, из которой мы можем получить любой архитектурный артефакт для стейкхолдера Продукта и работающее приложение/систему.**

{width=“5.9006944444444445in” height=“2.9533552055993in”}

Структура кодовой базы Продукта SEAF

Для обращений с целью обучения и совместной проработки сценариев применения SEAF: [seaf_team@sber.ru]{.underline} @Караваев Илья, Порошин Денис.

================Далее заметки===============

*NB! Заметки для развития этого раздела сохранены в отдельном файле. В том числе тезисы, ценности от докладов на тему SEAF для целевой аудитории (аналитиков)

**NB! Владельцами этого раздела являются Караваев Илья Александрович @Порошин Денис Юрьевич. В том числе по подготовке тезисов и выступлений на целевых площадках - Flow и других (для аналитиков).

Проблемы и вопросы, актуальные для целевой аудитории в лице аналитиков, и которые в той или иной форме преодолеваются в SEAF:

  1. "Заказчик не знает чего хочет". Потребности недостаточно глубоко осознаны. Недостаточная ясность потребности.

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

  3. Может потеряться изначальная цель (не только может быть изменена - это может быть нормально, а именно потеряться)

  4. Требование было сформулировано, потом ушло в разработку. Вернулись результаты и нужно проверить соответствие результата требованию. Часто есть проблема доказательства (проверки) соответствия полученного результата потребности.

  5. Как проверить полноту (покрытие) потребности требованиями? То есть подрядчик может сформулировать грамотные требования, но как проверить, что результат, удовлетворяющий им, удовлетворит потребность? Нет понимания покрытия потребности сформулированными требованиями. 

  6. Как проверить качество формулировок требований? Часто возникают широкие трактовки требований.

  7. Не прослеживается трассировка требований к реализующим требования компонентам системы и наоборот: нет трассировки от компонент к требованиям (следствием/реализацией каких требований является компонент)

  8. Аналитик не является соавтором системы. Проблемой является наличие четко осознаваемого потолка роста аналитика. Если фреймворк помогает аналитику "оставить следы в системе" (а может быть не только оставить следы, но и удерживать контроль впоследствии) - это значительный мотив для аналитика освоить SEAF. Если SEAF предлагает аналитику оставить маркеры в системе, которые помогут идентифицировать аналитика как соавтора - это круто. Именно это SEAF делает, когда обучает аналитика создавать архитектурный код.

  9. Не отражается связь мотивации (потребности) с требованиями.

  10. SEAF предоставляет аналитику уникальные возможности для применения AI для задач аналитики и управления инкрементом развития продукта в коде.

  11. SEAF предоставляет возможности для работы с мотивацией (потребностью) в новом подходе.

  12. SEAF показывает такой код, который показывает связь между потребностью и требованием, обеспечивает трассировку от фичи к потребности и сохраняет вклад аналитика в создание кода Системы. Артефакты аналитика "навечно останутся в коде системы". Аналитик может участвовать в дальнейшем в рефакторинге / изменении исходного кода системы. 

  13. SEAF показывает как исследовать и документировать предметную область для создания системы. То есть в итоге SEAF "работает" на создание экспертных знаний аналитика (и экспертной власти как одного из видов власти).

  14. SEAF включает важный тренд и потребность для аналитиков - это тренд по стандартизации работ. Аналитика можно привлечь к стандартизации деятельности в предметной области с помощью SEAF, так как SEAF включает свод требований стандартов (в публичной или закрытой частях)

  15. Неразрывность процесса производства (вовлечение аналитика в производственный процесс). Аудитория аналитиков видит себя в некотором процессе и он для них "нов" - это жирное преимущество, вызывающее интерес.

  16. Подход SEAF обеспечивает неразрывность процесса производства и убирает лишние артефакты. Это важно, так как в классических подходах в разных документах мы должны отразить одно и то же.

  17. Появляется сотрудничество аналитика, архитектора и разработчика . Возникает некоторая новая форма делегирования.

  18. Основной страх, когда что-то поменяли в коде - а нужно что-то обновить в документации. SEAF полностью раскрывает подход "документация рядом с кодом". Форматы документации на системы в MS Word естественным образом становятся не цифровыми артефактами.

  19. **Если seaf позволит привнести цифру в работу аналитика  - то это гуд, процессы пойдут легче. Меньше избыточной работы. Вопрос только в том как сделать так, чтобы это удалось** - (Денис особенно отметил эту мысль для проработки на будущее).

  20. SEAF предоставляет ясные инструкции по синтезу знаний в виде создания архитектурных шаблонов и требований (в том числе в рамках задач стандартизации) и дерайва из элементов шаблона компонентов прикладной архитектуры. Аналитик может видеть и предлагать варианты архитектур решений, раздвигая границы своих возможных действий.

Ценностное предложение для Продуктовых команд #

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

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

Изучая проблематику архитектурной функции, создатели SEAF обнаружили сложности в организации развития собственных продуктов на основе open-source решений. Факторами, создающими проблемы, являются отсутствие или недостаток документации, понимания детальной архитектуры кода исходных продуктов, сложность доработки и рефакторинга исходного кода для своих целей и прочие моменты, которые в целом препятствуют созданию новых решений на основе собственного "видения".

Для продуктовых команд, начинающих (и продолжающих) развитие своих цифровых продуктов на основе open-source продуктов, ключевыми вызовами и проблемами, которые позволяет решить SEAF, являются:

  1. Не полная документация на open-source продукт с точки зрения его функциональности и архитектуры. Иногда в open- source наблюдается полное отсутствие описания архитектуры (в том числе в документации). Чаще всего понимание архитектуры open-source продукта распределено между "головами" его основных контрибьюторов и открытый код представляет собой отражение этой архитектуры в коде решения. Понимание архитектуры open-source - решения, как правило, недоступно для стороннего разработчика, а понимание этой архитектуры является довольно большим "порогом входа" для создания и развития нового продукта (для целей импортозамещения или в соответствии со своим видением его развития). SEAF решает эту проблему методиками и инструментами редокументирования архитектуры в кодовой базе. **Таким образом, SEAF предоставляет продуктовым командам "катализатор" для создания и начала развития собственного продукта, который может быть создан путем включения множества решений от других open-source - продуктов. **

  2. Препятствия, создаваемые для русскоязычных контрибьюторов в open-source продукты на зарубежных сервисах. Например, такие препятствия создаются в развитии ядра Linux и IntelliJ IDEA. Эти препятствие дополнительно повышают "порог входа" для создания собственных продуктов. SEAF является открытым продуктом и способствует развитию и разнообразию open source решений независимо от политической конъюнктуры.  

  3. Нехватка понимания внутренней детальной архитектуры любого продукта, исходный код которого доступен команде, и которую часто можно понять только путем детального и трудоемкого анализа кода специалистами. SEAF способствует созданию и развитию собственного трека развития продукта, включающий глубокий рефакторинг и архитектурную трансформацию кода. Например, для целей импортозамещения. Примером методики трансформации архитектуры является MIKADO (от монолита к микросервисам) и другие. SEAF включает в себя аналогичные методики и методологически способствует более зрелому управлению исходным кодом любой системы или продукта (как проприетарного, так и открытого). 

  4. Затрудненность управления изменениями архитектуры и доработкой open-source-продукта в соответствии с собственными видением и для собственных специфических требований. Как следствие - при создании форка ожидание решения проблем в исходном репозитории и только после этого слияние доработок в свой репозиторий. SEAF позволяет применять современные методы управления кодом с учетом архитектурных методов, включая GitOps.

SEAF старается объединить подходы "Архитектура как код", "Архитектура как данные" и органично дать необходимые инструменты следования этому подходу для команд.

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

В целом есть препятствия, связанные с нехваткой архитектурной документации и компетенциями для самостоятельного развития open-source продукта в соответствии с видением Продуктовой команды и их Заказчика.

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

Концептуально цикл управления архитектурой продукта (проекта) в SEAF изображен на рисунке ниже.

{width=“5.9006944444444445in” height=“2.4296981627296588in”}

Рис. Концепт цикла управления изменением архитектуры от исходного кода

Для автоматизации получения описания архитектуры из исходного кода можно обращаться к

TBD. Метаданные об архитектуре продукта могут быть описаны с помощью Domain Specific Language (DSL), специализирующегося на описании архитектур цифровых продуктов. Как референсную архитектуру для данного подхода можем использовать архитектуру ArgoCD, спроектированную для GitOps и "Инфраструктура как код". Таким образом, продуктовые команды могут использовать GitOps для целей управления развитием своего продукта, что включает: <в следующей итерации добавить материал после анализа архитектуры ArgoCD>.

Ценности SEAF для Корпоративного архитектора #

Часто начало работы Корпоративного архитектора в организации связано с внедрением / совершенствованием процессов управления архитектурой в организации или с решением различных задач в рамках этого процесса, а именно:

  1. Определением объектов и областей управления

  2. Инструментализацией архитектурных процессов

  3. Разработкой процессов управления изменениями (CHANGE - процессов)

  4. Разработкой шаблонов "архитектурных" документов

  5. Описанием моделей принятия решений

  6. Разработкой архитектурных стандартов

  7. Разработкой модели компетенций архитектора / архитектурной функции

{width=“5.9006944444444445in” height=“2.5199015748031495in”}

Рис. Модель добавленной ценности SEAF в работе корпоративного архитектора

В текущем виде SEAF предоставляет для помощи корпоративному архитектору:

  1. Помощь в определении объектов управления на основе:

    a. Метамодели управления архитектурой SEAF

    b. Публичной части требований стандартов SEAF

  2. Референсные инструменты описания и управления архитектурой

  3. Референсные процессы управления архитектурными изменениями

  4. Набор стандартных архитектурных артефактов (шаблонов)

  5. Открытые или предоставляемые в рамках консалтинга архитектурные требования, которые можно использовать в рамках архитектурного проектирования или создания стандартов.

Ценности SEAF для решения вопросов безопасности #

Вопросы, связанные с безопасной разработкой и secure by design. 

Владелец раздела Старовойтов Денис Владимирович 

TBD

Вовлечение экспертов в развитие SEAF #

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

Например, разрабатывая Capability map, доменную модель бизнеса, архитектурные процессы - желательно иметь форум, или площадку, объединяющую и другие организации для обмена опытом в решении подобных задач.

Каждая организация, в рамках решения своей локальной задачи, может участвовать в интересной ей тематике SEAF и в коллаборации с другими организациями, с привлечением фасилитатора, вырабатывать общий подход и применять его. Команда SEAF или отдельные ее представители могут выполнять роль фасилитатора (facilitator) с целью координации, направления и выработки общего подхода к решению задачи или проблемы. Типы решаемых задач, вопросы, перспективные направления и тренды - представляют собой тематики SEAF. Вопросы обмена конфиденциальной информацией решаются в каждом случае индивидуально.

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

Рабочие (текущие) тематики SEAF:

  1. Business capability maps, Business Building Blocks, PBCs - Packaged Business Capabilities, ФБС и аФБС (автоматизированные функциональные бизнес-способности)

  2. Проектирование и внедрение процесса управления архитектурой решений

  3. Разработка методик и внедрение genAI. Разработка требований к AI - native организации

  4. Проведение базового обучения описанию ИТ-ландшафта в референсном инструменте

  5. Требования к референсным инструментам SEAF

Для организаций Группы Сбер предоставляется инфраструктура в виде оборудованных переговорных помещений, программного обеспечения (JAZZ) для совместных онлайн-встреч.

Команда SEAF  может рассказать об используемых подходах и полученных результатах по тематике.

Участие в тематике для организации - своего рода проект, в рамках которого решаются вопросы:

  1. Какие результаты и в какой форме могут быть получены

  2. Сроки разработки результатов, удобные для участников и организации работ по тематике

  3. Эффекты от коллаборации с SEAF и другими участниками

  4. Формат "защиты" полученных материалов - публичное выступление / доклад и т.п.

Форум SEAF не конкурирует с сообществами, а рассматривает их площадки и аудиторию как подмножества заинтересованных в SEAF лиц.

Мероприятия SEAF могут проводится на площадках сообществ, находящихся в фокусе внимания:

  1. Сообщество архитекторов ДЗО Сбер (А. Юшков)

  2. Сообщество ИТ-архитекторов Сбер (Е. Крысанов, Е. Пьянзов) 

В зависимости от выбранной темы, площадками могут быть другие сообщества, количество которых в Сбере в 2024 году сосставляет 74.

Участники команды SEAF Core и участники проработки соответствующих тематик могут выступать на интересующих площадках и генерировать UGC (user-generated content).

Используя методики SEAF, участники могут в том числе наращивать экспертизу в интересующих областях и занимать лидирующие позиции в интересующих сообществах.

Для ДЗО Группы возможно участие в работе тематики в том числе в роли фасилитатора, модерирующего встречи и направляющего работу тематик.

TBD

  1. В ДЗО часто смотрят на совместную активность с ДКА как на потенциальный источник новых требований в свой адрес (включение каких-то требований в корпоративный налог). Как-то отразить отсутствие рисков включения в корпоративный налог каких-то шаблонов или подходов, полученных в рамках развития тематик

 Консалтинг на основе SEAF #

Составные части практики консалтинга представлены на рисунке ниже.

{width=“5.9006944444444445in” height=“6.408954505686789in”}

{width=“3.34375in” height=“2.3020833333333335in”}

Рис. Каталог услуг SEAF

Структура документации SEAF #

Структура документации SEAF представлена на рисунке ниже.

{width=“5.9006944444444445in” height=“6.057037401574803in”}

Рис. Структура документации SEAF

Модель и процесс моделирования #

Модель является одним из базовых архитектурных понятий.

Визуальная модель позволяет человеку "объемно" увидеть предмет рассмотрения, в то же время оставляя за границами детали, не важные для заданной цели.

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

Модель всегда создается с определенной целью и на определенном уровне рассмотрения

Модель всегда учитывает аспекты эргономики, связанные с возможностью восприятия и представления объекта в воображении человека. Человеческое воображение может одновременно удерживать 5-9 терминов или объектов, что в том числе определяет требования к количеству объектов на модели.

Обычно модели включают до нескольких десятков объектов, а если количество объектов увеличивается, то способность воспринимать модель и анализировать ее содержимое уменьшается. Возникает необходимость детализации группы связанных объектов на отдельную модель ("дриллдаун") для представления группы объектов в виде одного объекта или связи на модели верхнего уровня.

В случае, когда количество объектов на модели существенно увеличивается, то теряется весь смысл и эргономика представления сложного объекта в виде модели.

{width=“5.9006944444444445in” height=“4.5157436570428695in”}

Уровень абстракции формализованного знания SEAF #

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

Начнем с простых примеров.

Простой пример 1. Предположим, что имеется шаблон трехзвенной архитектуры, состоящий из трех элементов: клиент, сервер приложений, система управления базами данных. Это абстрактный пример описания архитектуры, в соответствии с которым создано множество конкретных информационных систем, в рамках которых выбраны и внедрены или созданы конкретные компоненты, выполняющие роль (реализующие) элементы архитектурного шаблона. Компоненты решений имеют свои версии, платформы разработки, технический стек, инфраструктуру и т.п. В простом матричном (табличном) представлении  удобно представлять архитектуры трехзвенных систем в виде таблицы, в которой в первом столбце находятся архитектурный элементы, в первой строке - перечень трехзвенных систем, в ячейках - компоненты систем, реализующие каждый архитектурный элемент. Удобное представление для анализа, типизации и стандартизации трехзвенных систем в ландшафте. Компоненты имеют конкретный статус жизненного цикла, что может быть отражено в представлении и удобно для управления жизненным циклом, что также является частью методик управления архитектурой. Какие архитектурные шаблоны, архитектурные элементы использовать, какие требования стандартизации предъявляются к выбору компонентов системы- составляют свод знаний и практик SEAF. Специфические для организации решения, отражающиеся в компонентах архитектур - не являются предметом знаний SEAF, но могут быть материалами для анализа или обобщения, формирования рекомендаций в рамках SEAF.

Простой пример 2. В Сбере имеется Сборник архитектурных стандартов ДЗО и ДБ, представляющий собой набор сгруппированных по темам архитектурных требований, на основании которых производится оценка архитектур дочерних и зависимых обществ. Эти требования сформулированы не в отношении конкретных объектов (компонентов архитектуры), а в отношении типов объектов (архитектурных элементов). Каждое требование Сборника касается определенного контекста в виде элементов. В рамках оценки происходит уточнение какие компоненты архитектуры организации подпадают под область действия требования. Таким образом, требования Сборника формулируются на том же условном уровне абстракции, что и архитектурные элементы. Требования Сборника являются ценной чатью SEAF и представляют собой формализованное знание на основе опыта управления архитектурой Группы. Аналитическая справка по каждому требованию включает рекомендации и указания, позволяющие идентифицировать контекст применения требования в компонентах архитектуры конкретной организации.

Простой пример 3. Результат реверса архитектуры из инфраструктуры или облачных инфраструктурных решений - это в исходном виде набор компонентов архитектуры (в слое управления инфраструктурой, например). Группировка компонентов, например, в ресурсно-сервисную модель информационной услуги (ИТ-услуги, автоматизированной системы и т.п.) - это отражение взаимосвязи компонентов в существующем ландшафте как результат принятых ранее архитектурных решений. 

Простой пример 4. Результат анализа архитектуры (редокументирования) из исходного кода продукта (например, из исходного кода любого open-source-продукта из GitHub) - это архитектурные элементы, на модели отражающие концепцию работы какого-либо продукта. Таким образом, исходный код любого продукта с открытым исходным кодом может служить источником информации о его архитектурных элементах и концепции его работы. Описание в виде документации обычно не сопровождается информацией такого рода, поэтому архитектурное редокументирование является эффективным инструментом "заглянуть под капот" работающего продукта и ценным источником знаний для SEAF.

Пример 5 (из TOGAF). TOGAF использует следующее разделение: архитектурный континуум (architecture continuum), состоящий из architecture building block (ABB) и континуум решений (solution continuum) состоящий из своих блоков - Solution Buildig Block (SBB). Таким образом, TOGAF использует аналогичное разделение и уровень абстракции для аккумуляции своих знаний, но в несколько другом контексте и для иных целей, чем SEAF.

Таким образом, свод знаний SEAF формулируется в отношении архитектурных элементов на основании опыта и лучших практик управления ландшафтом и проектирования любых типов систем.

Одним из ключевых вкладов в SEAF со стороны Сбера (ДКА ДЗО) являются требования и концепции, аккумулированные ДКА ДЗО в области управления архитектурой ДЗО и ДБ Группы Сбер в форме Сборника стандартов ДЗО и ДБ (далее - Сборник).

Требования Сборника - квинтэссенция большого объема работы и обобщения знаний в области управления архитектурой Группы.

Актуальные оцифрованные в формат SEAF требования Сборника собраны здесь: SEAF Standards.

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

{width=“5.9006944444444445in” height=“4.440974409448819in”}

Рис. 1. Области требований SEAF и их аккумуляция в Базах знаний

Комментарии 1. В общем случае проверка (валидация) выполнения требований Сборника - трудно алгоритмизируемый процесс. В отдельных случаях, когда проверку можно выполнить по значению какого-либо атрибута в описании архитектуры решений (конкретных компонентов) - проверки могут быть автоматизированы. Но в общем случае требуется ручная (экспертная, в рамках ассесмента с привлечением Архитектора ДКА) валидация требования. Именно ввиду сложности такой проверки чаще всего требуется максимально подробная аналитическая справка по требованию.

Комментарий 2. В общем случае cущность процедуры валидации требования SEAF (любого, не только из Сборника) в конкретном ландшафте организации - в проверке выполнения требований и рекомендаций, полученных в цикле управления архитектурой SEAF в ИТ-ландшафте организации и целевом видении ИТ-ландшафта с точки зрения организации. То есть в проверке соответствия (проверке консистентности, согласованности) между циклом управления архитектурой в SEAF ("элементами архитектуры") и циклом (процессом) управления архитектурой решений в организации ("компонентам архитектуры"). Это называется термином Архитектурный контроль (во множественном числе - "Архитектурные контроли"). Архитектурные контроли могут включать не только свод требований Сборника.

Комментарий 3. Архитектурные контроли должны быть достаточно сбалансированными по шкале "жесткость-гибкость" для того, чтобы не блокировать между собой цикл управления разработкой архитектуры в SEAF и циклы управления архитектурой в организациях. Циклы управления архитектурой в организациях работают с учетом собственных правил, с собственной ритмичностью, с учетом сложности и масштабности своей архитектуры и интегрированы в свою систему управления. **Архитектурные контроли обеспечивают, с одной стороны, архитектурный контроль, а с другой стороны - не блокируют развитие (управление архитектурой) в конкретной организации.  **Полная автоматизация архитектурных контролей не нужна и невозможна.

Концептуальная модель требований SEAF и их накопление в базах знаний предполагает наличие двух взаимодействующих циклов управления:

  • Цикла разработки SEAF

  • Цикла управления архитектурой решений, - 

что отражено на модели ниже.

{width=“5.9006944444444445in” height=“2.978109142607174in”}

 

Рис. Разделение областей управления SEAF и архитектур организаций

Накопление знаний SEAF невозможно без работы с архитектурой решений в Группе, а адекватная и консистентная работа по контролю архитектурой Группы невозможна без организации накопления знаний. Два цикла не могут существовать совершенно отдельно друг от друга. Поэтому в расширенном смысле SEAFом называется вся область деятельности ДКА ДЗО по контролю архитектуры Группы (совокупность двух циклов работы). Однако формализованная часть, представляющая собой синтез опыта управления архитектурой в Группе, отражается в результатах работы Цикла (процесса) разработки SEAF.

Комментарий 1. Создание SEAF требует сложной организационной, методологической и технической работы и инструментов. Прямым аналогом (но значительно более масштабным), например, является площадка Catalyst TMForum. Зарубежные площадки часто вводят ограничения на участие в зарубежных сводах знаний (баны аккаунтов и т.п.). Это один из факторов (драйверов), приводящих к необходимости создания SEAF в Сбере.

Продолжим демонстрацию применения концепции процесса разработки SEAF на примерах.

Простой пример 6. Является ли какой-либо процесс управления архитектурой, внедренный в ДЗО или между ДЗО и ДКА СБера, частью SEAF? Ответ: реализация такого процесса в общем случае отражает как общие идеи (на уровне "элементов" архитектуры или паттернов), так и специфику организации (специфику Сбера или специфику ДЗО, включая логику и атрибутивный состав). Поэтому такие процессы не являются частью процесса развития (разработки) SEAF. Они могут рассматриваться как целевые процессы, в которых применяются идеи и рекомендации SEAF, или процессы, в которых изучаются соответствующие практики для последующего обобщения и включения в свод знаний SEAF. Частью SEAF описание таких процессов может стать только после обобщения требований и принципов их организации на уровень рассмотрения SEAF. Процесс, построенный с учетом рекомендаций и выполняющий требования SEAF, может быть назван "SEAF compliant" или "Powered by SEAF" и т.п.) То есть создан в том числе с помощью SEAF, частью SEAF не является.

Простой пример 7. Является ли какая-либо информационная система, внедренная в организации/группе организаций, частью SEAF?

Требования Сборника ввиду, например, существенных рисков для безопасности, не распространяются в полном объеме в open source. В открытом доступе находятся примеры архитектурных требований, которые организация может дополнить своими архитектурными требованиями или, (если организация входит в Группу Сбер), дополнить требованиями Сборника в полном объеме, распространяемым по внутренним каналам передачи информации. 

Протомодель фазы управления архитектурой #

{width=“5.9006944444444445in” height=“4.19849300087489in”}

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

Глубина (гранулярность) описания архитектуры SEAF #

По глубине описания архитектуры выделяются следующие уровни:

  1. Концептуальный (=корпоративный). Абстрактный уровень описания архитектур "в крупную клетку"

  2. Системный (system architecture). Описание на среднем уровне продуктов, систем, их компонентов и их взаимодействия

  3. Программный (=детальный). Архитектура программного обеспечения (software architecture). Детальный уровень

В рамках любого цикла управления архитектурой (SEAF или цикла управления решениями) существует детализация по глубине от концептуального уровня до детального.

Направления внедрения SEAF #

SEAF как архитектурный фреймворк внедряется в двух направлениях:

  1. "Сверху вниз". Внедрение начинается с головной организации или организации, создающей собственные продукты. Верхним объектом управления является организация, архитектура которой описывается "сверху вниз" от наиболее крупных архитектурных объектов - организационной структуры, бизнес-процессов, классификации (каталога) информационных систем и далее детализируется в области, имеющие высокий потенциал оптимизации. В целом это направление внедрения SEAF идет от системы управления организацией к исходному коду (автоматизированных систем, продуктов, сервисов организации).

  2. "Снизу вверх". Внедрение SEAF начинается с редокументирования кода и (или) архитектуры создаваемых или имеющихся цифровых продуктов. Это направление внедрения может быть распараллелено между различными цифровыми продуктами / продуктовыми командами. Архитектура в SEAF может поддерживаться в различных продуктах, сверху никак не связанных между собой. Интеграция управления продуктами в SEAF и управления организацией в целом по SEAF осуществляется через Digital ADR. В целом это направление внедрения SEAF идет от исходного кода (автоматизированных систем, продуктов, сервисов организации) к системе управления организации в целом.

{width=“5.9006944444444445in” height=“2.9525153105861768in”}

Рис. Направления внедрения SEAF "Сверху вниз" и "Снизу вверх"

SEAF внедрен в организации в целом, если путь "сверху вниз" и области, управляемые в SEAF "снизу вверх", интегрированы между собой, и достигнуто консистентное развитие организации в целом и ее продуктов. Таким образом, SEAF внедрен, когда цели развития организации в целом и цели развития Продуктов организации конгруэнтны.

Концепция кодовой базы Продукта #

{width=“5.9006944444444445in” height=“3.23125in”}

Концепция Digital ADR #

Пример DADR:

Владелец раздела и соответствующего артефакта Садыков Тимур Равилевич, исходные материалы здесь:

Внедрение SEAF "Сверху вниз" #

Внедрение референсных процессов #

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

Референсный процесс SEAF - это абстрактный ("виртуальный", "предсобранный") в логике и из данных SEAF для предполагаемого контекста (предметной области) процесс.

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

  1. Адаптации шаблонов документов под требования организации

  2. Распределения ролей и соответствующих им полномочий и обязанностей в текущей или целевой организационной структуре организации и в целом системе ее управления.

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

  4. Уточнения логики взаимодействия (логики бизнес-процесса) в конкретном окружении организации

Референсные процессы проектируются для:

  1. Отраслей/индустрий

  2. Крупных ИТ-решений (ERP)

  3. Типовых бизнес-задач (типовых бизнес-процессов), встречающихся в различных организациях (например, планирование и бюджетирование).

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

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

  1. Адаптации шаблонов архитектурных артефактов под требования организации

  2. Распределения ролей и соответствующих им полномочий и обязанностей в текущей или целевой организационной структуре организации и в целом системе ее управления.

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

  4. Уточнения логики взаимодействия (логики бизнес-процесса) в конкретном окружении организации

Рефересный процесс SEAF может включать или использовать другие артефакты SEAF более высокого уровня абстракции или другие по своей природе: 

  1. Карта архитектурных функций (architecture capability map)

  2. Категории (классы) информационных систем

  3. Шаблоны архитектурных артефактов (документов) и другие.

Общий подход для идентификации и внедрения бизнес-процесса универсален и применяется в том числе в SEAF.

{width=“5.9006944444444445in” height=“1.61752624671916in”}

Рис. Обобщенный алгоритм (модель) идентификации процесса как объекта управления

Примеры процессов в контексте ДКА ДЗО: 

  1. П2652: Оценки (Латушкин)

  2. П2653: Экспертиза отклонений (Букавнев)

  3. П2649: КАДЗО (Юшков) и другие в конкретных организациях

SEAF по своему замыслу является фреймворком ("конструктором"), который дает необходимые элементы на абстрактном уровне, из которых легче проектировать, улучшать и внедрять реальные бизнес-процессы в организациях.

Условно проектирование деятельности "сверху вниз" с применением SEAF показано на модели ниже.

Концептуальная модель формирования референсных процессов и их применения в организациях представлена на рисунке ниже.

{width=“5.9006944444444445in” height=“3.5921325459317583in”}

Рис. Концепция разработки и применения референсных процессов SEAF.

Референсные процессы (сценарии использования) SEAF для решения архитектурных задач #

{width=“5.9006944444444445in” height=“3.4587226596675418in”}

Рис. Сценарии использования SEAF для решения архитектурных задач в рамках уровня архитектурной зрелости 1

capabilities

{width=“5.818463473315836in” height=“8.625in”}

Рис. Сценарии использования SEAF в рамках уровня зрелости архитектуры 2

Сценарий определения объема архитектурных работ с применением ИИ

{width=“5.9006944444444445in” height=“5.515762248468941in”}

Проектирование с учетом типовых и референсных архитектурных решений #

Протомодель информационной услуги (сервиса) и управления требованиями к ней #

В значительной части случаев (контекстов) синонимом слова "услуга" является слово "сервис", однако термин "услуга" является более предпочтительным.

Любая информационная услуга, продукт, прикладной сервис, технический сервис (ИТ-услуги) создаются как результат анализа и применения Требований. Требования могут называться и оформляться различными понятиями и артефактами, принятыми в конкретной организации: запрос на автоматизацию, фича с продукта, epic story, внешняя спецификация сервиса и другие. Поэтому в данной модели используется только базовая сущность - требование. Названия артефактов приводятся как пример для понимания применения модели.

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

Создание любой услуги начинается с формулирования  того, какой она представляется его потребителю по различным методикам, которые могут включать изучение и проектирования CJM, исследования потребительского поведения, исследования предметной области и пр. Атомарная часть результатов этих исследований - условное требование, сформулированное в терминах, понятных потребителю. Нужно понимать, что это требование с внешней стороны - потребителя, поэтому требования разделяют на требования внешней спецификации услуги или продукта и требования внутренней спецификации услуги или Продукта. Требования внутренней спецификации  - это требования внешней спецификации, уточненные, декомпозированные, дополненные архитектурными и другими нефункциональными требованиями, изложенные во внутренней спецификации продукта. Внутренняя спецификация Продукта - описывает внутренние (не видимые потребителю) компоненты Продукта и связывает требования с внутренней архитектурой продукта (невидимой потребителю). Для исключения недопонимания в названии внутренней спецификации, ее часто называют Архитектурной спецификацей Продукта. Понятия спецификаций и требований изложены на рисунке ниже.

{width=“5.9006944444444445in” height=“2.4232108486439197in”}

Рис. Модель прототипа информационной услуги и управления требованиями

Модель прототипа информационной услуги и управления требованиями содержит следующие связи и типы объектов:

  1. Потребитель или аналитик услуги/продукта, отвечающий за формирование требований к проектируемой услуге или новую фичу/изменения в ее поведении

  2. Требования внешней спецификации услуги. Требования сформулированы терминологией, понятной потребителю и как правило, представляют собой требования к функциям прикладного сервиса/услуги/продукта

  3. Внешняя спецификация услуги - документ, сформированный путем включения свода требований, как правило, в таблицу. Внешняя спецификация, как правило, проходит процесс согласования и утверждения (в различных формах) со стороны заказчика услуги

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

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

  6. Общий анализ требований по заявке приводит к пониманию применяемых шаблонов (архитектурных паттернов, РАР, ТАР и прочего. Выбор концептуальной архитектуры может (и должен быть) отражен в DADR. 6.x - различные типы связей между требованиями и компонентами проектируемой услуги. Основной тип связи - реализует. Другие типы возможны, например, когда в проектируемой услуге требуются данные, создаваемые в других продуктах, услугах или сервисах. В этом случае Архитектор услуги/продукта отражает требуемые информационные потоки, при необходимости - с расчетом SLA.

  7. В случае необходимости информационных потоков к / от внешних компонентов, Архитектор Продукта отражает необходимые связи

  8. Архитектор услуги/продукта/прикладного сервиса/технического сервиса. Целью Архитектора продукта при разработке внутренней спецификации услуги является разработка архитектуры услуги.

  9. Архитектор Продукта формирует требования к потребляемым услугам/сервисам, как из "меню в ресторане". Например, может планировать использование и запрашивать стандартные технические сервисы для развертывания прикладных сервисов/продуктов.

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

  11. Модель завершается формированием структуры работ, полной с точки зрения достижения требований принятой внешней спецификации. Сформулированный объем работ в случае реализации, должен обеспечивать удовлетворение требований внешней спецификации в согласованные (разумные) сроки. Сформулированные работы должны быть направлены в адрес продуктовых команд, инициаторов ИТ-проектов, инициаторов ИТ-изменений и приняты в работу другими подсистемами управления организации (системой управления проектами, системами гибкой разработки/Сберджайл, процессами управления изменениями ИТ и т.п. Частью архитектурой функции "в идеале" является и мониторинг с оценкой исполнения соответствующего блока работ (так называемый Architecture Governance).

  12. Изменение каждого статуса артефакта - внешней или внутренней спецификации - должно попадать в DADR и согласовываться на предмет консистентности (конгруэнтности) целей организации.

<Комментарии после ревью с Е.Черепановым:

  1. Модель в целом одобрена с учетом комментариев под моделью.

  2. Выявили необходимость дополнить разделом про то, что такое Продукт (чтобы при чтении было понятно, что имеется ввиду не только прикладной сервис, а более абстрактный объект)

  3. Выявили необходимость дополнить разделом про то, чем SEAF отличается на концептуальном уровне от "банковской методологии управления архитектурой".

  4. Для прикладной области или технической архитектуры сделать примеры формирования требований. Здесь же можно сделать примеры документов: внешняя и внутренняя спецификации. Из примера получим шаблоны этих документов.

  5. На схеме не хватает в архитектурной работе над внутренней спецификацией введения в понятие архитектурного шаблона ("архитектурного паттерна"и элементов этого паттерна, в соответствии с которыми "выбираются" целевые компоненты проектируемой услуги/сервиса)

>

Предварительное условие: наличие существующего портфеля продуктов или ландшафта информационных систем/сервисов (не greenfield).

SEAF фокусируется вокруг создания и управления изменениями Продуктов, под которыми могут в более узком контексте пониматься прикладные или технические сервисы.

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

Создание любого продукта начинается с формулирования  того, каким он представляется его потребителю по различным методикам, которые могут включать изучение и проектирования CJM, исследования потребительского поведения, исследования предметной области и пр. Составная часть результатов этих исследований - условное требование. Нужно понимать, что это требование с внешней стороны потребителя, поэтому требования разделяют на требования внешней спецификации продукта и требования внутренней спецификации Продукта. Требования внутренней спецификации продукта - это требования внешней, декомпозированные, дополненные архитектурными и другими нефункциональными требованиями, изложенные во внутренней спецификации продукта. Внутренняя спецификация Продукта - описывает внутренние (не видимые потребителю) компоненты Продукта и связывает требования с внутренней архитектурой продукта (невидимой потребителю). Для исключения недопонимания в названии внутренней спецификации, ее часто называют Архитектурной спецификацей Продукта. Понятия спецификаций и требований изложены на рисунке ниже.

Категории конфиденциальности протомодели информационной услуги #

SEAF вводит категории конфиденциальности информации об информационной услуге:

  1. Confidential level 1 (далее - CL1). Публичная информация о сервисе, доступная неопределенному кругу лиц. К этой категории конфиденциальности относится вся информация, опубликованная на публичных сервисах GitHub, GitVerse. Информация для потенциальных клиентов для получения услуг/сервисов (маркетинговая информация в случае публичных сервисов)

  2. Confidential level 2 (далее - CL2). Информация, раскрывающая методы получения ресурсов сервиса. Wiki, tutorials, консультации, получаемые и изучаемые пользователем сервиса после аутентификации.

  3. Confidential level 3 (далее - CL3). Информация wiki, раскрывающая внутренние механизмы работы сервиса, не видимые для его "обычных" потребителей.

  4. Confidential level 4 (далее - CL4). Информация, составляющая стратегию развития продукта, внутренние компоненты, характер и режимы их работы и интеграции. Информация, которой владеет Владелец продукта или известная ограниченному кругу лиц под его контролем. 

Адаптируя SEAF, возможно перераспределение информации по уровням конфиденциальности и увеличение или уменьшение количества уровней.

Увеличение количества категорий может происходить за счет расширения информации о стратегии развития Продукта в стратегических или тактических целях организации-владельца продукта. 

Разработка и внедрение архитектурных стандартов #

{width=“5.9006944444444445in” height=“0.6274278215223097in”}

Рис. Разработка и внедрение архитектурных стандартов

Управление архитектурными изменениями #

{width=“2.790608048993876in” height=“2.6041666666666665in”}

Рис. Концепция (концептуальный процесс) управления архитектурными изменениями

{width=“3.0643985126859143in” height=“2.6041666666666665in”}

Рис. Модель контроля архитектурных изменений

Управление архитектурными отклонениями #

{width=“5.9006944444444445in” height=“2.294499125109361in”}

Внедрение SEAF "снизу вверх" #

Перечень метамоделей SEAF #

Требования к референсным инструментам SEAF #

TBD

Общая цель SEAF и конечная цель внедрения референсных инструментов SEAF - обеспечить переход к AI-native организации.

Мы пытались собрать с помощью людей метасущности (определить метамодели SEAF), однако эта задача может быть лучше выполнена с помощью реверс-инжиниринга+AI (специфический entity recognition подход)

Капитализация JetBrain 10 млрл долларов.

Классификация публичности (закрытости) информации SEAF #

Внутренние ресурсы Сбера для разработки SEAF #

Основные концепции, методология SEAF для контрибьюторов и мейнтейнеров Сбера излагаются в разделе Confluence.

Актуальный список репозиториев в соответствии с Распоряжением о публикации SEAF, включает следующие репозитории на внутренних ресурсах Сбера (в bitbacket):

Внешние open-source ресурсы SEAF #

GitHub #

На текущий момент в публичном сегменте SEAF основная работа ведется на сервисе GitHub под технической учетной записью seafteam:

Управлением внутренней структурой, контентом репозиториев SEAF занимается команда SEAF, руководствуясь стратегией создания продукта, оперативными планами-графиками работ.

Публикация на внешних ресурсах, доработка (модификация) производится только в указанных репозиториях SEAF.

GitVerse #

На внешнем сервисе GitVerse организовано зеркалирование (пайплайн) базовых репозиториев под учетной записью (профилем) организации seafteam:

Допускается создание форков репозиториев SEAF, создание новых репозиториев под личными учетными записями участниками разработки SEAF (как часть производственного процесса, для проработки POC, рабочих гиптотез и т.п.).

Интеграция GitHub и GitVerse #

На текущий момент настроена ежесуточная синхронизация репозиториев GitHub в Gitverse:

  • SEAF CORE

  • SEAF DZO CORE

  • SEAF DZO Example

  • SEAF Hexagon

  • SEAF IaaS

  • SEAF Software Registry

  • SEAF Standards

  • SEAF Base Of Knowledge

  • SEAF Examples

  • SEAF KADZO

  • SEAF MM-discovery

  • SEAF DZO-prototype

В случае работы с репозиториями SEAF (клонирования, PR, MR...) с территории Крыма, для исключения возможных блокировок личных УЗ, рекомендуется работать с репозиториями публичного сервиса GitVerse.

Требования производственного процесса и стандарта FOSS #

Ключевыми артефактами процесса публикации SEAF по FOSS являются:

  1. Описание компонент SEAF. Документ включает описание публикуемых репозиториев, их назначение, зависимости от внешних opensourse продуктов (в частности, которые могут иметься в инструментах визуализации)

  2. Распоряжение о публикации SEAF на внешних публичных сервисах GitHub, GitVerse

  3. Заключения о правовых рисках и проверке лицензионной чистоты

В случае необходимости создания новых продуктов в пространствах seafteam, необходима актуализация, согласование и утверждение как минимум указанных документов. 

Требования кибербезопасности #

Каждый сотрудник Сбера, являющийся контрибьютором SEAF, несет ответственность за соответствие публикуемой информации уровню конфиденциальности информации не выше К3 (то есть публикуемая информация не должна содержать конфиденциальную информацию К1/К2).

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

  1. Значимый файл должен быть проверен с помощью сервиса "Автоматически определить категорию конфиденциальности информации и обезличить файлы" черед СберДруг, или с помощью ручной проверки (сервис ручной проверки так же доступен через СберДруг). Сервис "умеет" определять автоматически определять категории К1/К2/К3 (К3 от К4 он не отличает).

  2. Результатом проверки файла являются файл отчета (excel) и файл разметки (html), доступные в сети Омега.

  3. Если по результатам определения категории выявлена информация, составляющая К1/К2, то ее необходимо устранить в исходном проверяемом файле, или, если обнаруженная КИ не является таковой, получить результат апелляции, в котором категория конфиденциальности информации определена как К3.

Информация может быть опубликована на публичных сервисах SEAF только после того, как она признана с помощью сервисов ДКБ категории К3.

Процесс разработки SEAF #

Процесс выпуска релиза SEAF для участника открытого сообщества #

В совместной разработке open source продукта выделяются роли:
Контрибьютору (contributor)- участник открытого сообщества, который имплементирует изменения в продукте и направляет изменения (pull request) в основной репозиторий продукта.
Коллаборатор (collaborator) - участник открытого сообщества, который может присоединяться к контрибьютору для совместной работы над изменениями.
Команда продукта (SEAF CORE TEAM) - участники открытого сообщества, взаимодействующие с контрибьюторами для формирования итогового образа изменений в соответствии с видением развития продукта.

Участники открытого сообщества SEAF работают с методологическими репозиториями SEAF в пространстве seafteam, на текущий момент - в GitHub по адресу: https://github.com/SEAFTeam.

Общий паттерн работы с ветками репозиториев #

  1. Репозитории SEAFTeam являются основным набором репозиториев, содержащий актуальный набор моделей\инструментов по описанию архитектуры как кода.

  2. В каждом репозитории SEAFTeam всегда присутствуют как минимум 2 ветки:

    a. master - содержит последнюю актуальную версию (релиз)

    b. vx.x.x - ветка с рабочими изменениями. В эту ветку отправляют свои PR (pull request) контрибьюторы. Доработки контрибьюторов попадают (вливаются) в ветку после прохождения ревью как минимум со стороны еще одного контрибьютора.

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

Работа с удаленными репозиториями в роли контрибьютора #

  1. Для реализации изменений контрибьютор создает собственный fork исходного репозитория из пространства SEAFTeam. Обратите внимание, что при создании форка желательно снять опцию "copy the master branch only". Это позволит видеть релизную ветку репозитория в своем форке, что облегчает взаимодействие. Если ранее был создан форк с опцией "copy the master branch only", рекомендуется сохранить наработки локально из текущего форка (если они есть и не закоммичены в оригинальном репозитории), удалить исходный форк и создать новый форк без опции "copy the master branch only".

  2. В собственном репозитории рекомендуется следовать общим правилам по работе с удаленными репозиториями:

    a. При разработке не использовать ветки master и v x.x.x. Данные ветки подтягиваются из основного репозитория SEAFTeam при синхронизации fork`а. Подобный подход позволяет получать изменения, внесенные другими участниками в основной репозиторий SEAFTeam/repo.

    b. Новые ветки рекомендуется “растить” от последней версионной ветки v x.x.x.

  3. По завершению работы по внесению изменений контрибьютор отправляет pull request в ветку v x.x.x основного репозитория SEAFTeam.

    a. В процессе ревью могут возникнуть дополнительные вопросы\рекомендации по реализации изменений. Для успешного прохождения ревью необходимо "закрыть" (либо предоставив уточняющие комментарии, либо внеся изменения в реализацию).

    b. После прохождения ревью изменений будут внесены в ветку v x.x.x .

Общий шаблон работы с релизными ветками представлен на модели

{width=“5.9006944444444445in” height=“1.5868088363954507in”}

Подключение коллабораторов для совместной работы над изменениями #

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

  2. Для подключения коллаборатора необходимо отправить ему “инвайт” (дать доступ) в собственный репозиторий (fork основного) и договориться о правилах совместной работы над ветками.

    a. В совместной работе коллаборатора и контрибьютора стоит придерживаться "общих паттернов работы с удаленными репозиториями".

Коллаборатор работает непосредственно в репозитории контрибьютора.

Производственный процесс SEAF для Сотрудников Сбера из Сигмы #

TBD включая инструкции или ссылки на них

До момента разработки текущей статьи закрыт доступ из сигмы на push в публичные репозитории сервисов GitVerse, GitHub. Открытие доступа разработчикам SEAF из Сигмы прорабатывается. Модель отрисована в предположении, что доступ предоставлен.

Производственный процесс SEAF для Сотрудников ДЗО, ДБ, ГПГ Сбера #

TBD включая инструкции или ссылки на них

Производственный процесс SEAF для Сотрудников для участников сообщества #

TBD включая инструкции или ссылки на них

Данный раздел является переработкой ранее разработанных черновых материалов:

  1. Процесс распределенной разработки SEAF 1.х (Караваев)

  2. SEAF. Коллаборативное развитие фреймворка (Мячин)

Вехи (ключевые цели) развития SEAF #

  1. Запустить и ежеквартально собирать QuickStart Guide SEAF как срез информации из базы знаний SEAF о том, как начать осваивать, решать практические задачи и внедрять архитектурную функцию в организации. Материалы можно брать из базы знааний SEAF и из дайжестов (куда собираются в том числе все текущие события из развития SEAF)

  2. Выпускать текущие релизы SEAF

  3. Разработать и обкатать на реальных примерах методику редокументирования (реверса) документации (архитектуры) из открытого исходного кода (есть примеры)

  4. Стратегическая цель SEAF: создание кириллического DSL языка для создания современных коммерческих Продуктов в Группе и внешнем рынке. 

  5. Включить DADR в методику редокументирования архитектуры. 

  6. Включить AST как технологию в инструмент для возможности рефакторинга и транспиляции кода (возможность создания архитектурных артефактов) 

Справочные материалы:

FAQ #

Вопросы, на которые отвечает настоящая страница:

№ ВопросаВопросОтвет/комментарий
Ради каких целей SEAF публикуется в открытый доступ? 
Какие выгоды есть у Банка от создания и публикации SEAF?
Какие риски есть у публичной части SEAF?
Для кого создается SEAF (для какой целевой аудитории он существует)?
Какую ценность SEAF приносит потенциальным архитекторам - бизнес- и системным аналитикам?
Какую ценность SEAF приносит продуктовым командам?
В чем заключаются ценности и намерения создателей SEAF? (новая версия манифеста, разделяемая командой)
Какие направления и методики внедрения SEAF предполагаются?
Какие правила разметки кода требуется соблюдать, чтобы поддерживать соответствие требованиям правообладателя - Сбера и авторскому праву контрибьюторов SEAF?
Как оценить или измерить внедрен SEAF или нет?
Что является и что не является частью SEAF по уровню абстракции? Является ли SEAF "всем", чем занимается ДКА ДЗО?
В какой базе знаний содержится знание SEAF?
Что такое архитектурные контроли и их валидаторы? Необходима ли их 100% автоматизация?
Необходимы рекомендации для определения гранулярности разделения SEAF на части, классифицируемые по уровню публичного доступа
Что такое редокументирование архитектуры из исходного кода любого open-source - продукта с GIT - и почему это золотая жила для развития SEAF?
Что такое и чем отличаются циклы развития SEAF и управления архитектурой решений? Как они взаимодействуют?
Что такое SEAF?
Какие есть текущие компоненты SEAF?
Как выглядит Процесс разработки SEAF для сотрудников Сбера из Сигмы
Как выглядит Процесс разработки SEAF для любого контрибьютора из открытого сообщества
Какие есть предложения по принципиальным целям (дорожной карте) развития SEAF на год и стратегический горизонт?

Справочно: DOD определения критериев и процедуры публикации SEAF

  1. Сформулированы цели публикации материалов в открытый доступ, т.е. сформулировать что получает Сбер публикую часть своей интеллектуальной собственности, какие бенефиты получает, какие риски и затраты несет

  2. Сформулированы критерии к определению гранулярности частей, на которые «условно» разделяется СЕАФ для принятия решении о классификации доступа

  3. Определены критерии для классификации уровня доступа частей (размер части должен определяться гранулярностью)

  4. Проведена оценка текущих материалов по сформулированный методике

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