1 Операционная надежность (надежность операций, процессов, функций)
Регулятор (ЦентроБанк, ЦБ) уже несколько лет ведет «крестовый поход» под знаменем «Операционная надёжность»: выпускает «одноименные» Положения (850-П / 787-П, 779-П), Стандарты Банка ��оссии (СТО БР БФБО-1.5-2023), ГОСТы (ГОСТ 57580.3 / 57580.4, с его участием), а также методические рекомендации (18-МР) и формы обязательной отчетности по «Операционной надёжности» (operational resilience).
Под знаменем «Операционная надёжность» - делается попытка «скрестить» (где-то «ежа с ужом», но сама идея достойная) бизнес-архитектуру (архитектуру процессов, как технологических, так и бизнес – хотя разделение их не понятное), EA (enterprise architecture) / ИТ-архитектуру, ITSM (CMDB, управление инцидентами, в том числе, инцидентами операционной надежности), информационную безопасность (вкл. ГОСТ 57580.1 / 57580.2), надежность / отказоустойчивость / ОНиВД, риск-менеджмент (опер-риски, 716-П), импортозамещение (ФТК). Подобный «единый узел» - это проекции «одного и того же» на разные плоскости (EA, BPM, GRC, ИБ, ITIL и др.) с разными словарями / концепциями, поэтому формализовать его видимо равносильно притчи / сценарию «Вавилонская башня». Однако «язык графа» сближает такое восприятие и снижает барьер сложности.
Далее будем говорить только о Форме 0409072 (далее ф072) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.
Кредитные организации (вкл. НКО, но есть нюансы) сдают обязательную ф072 (такую же обязательную как баланс), в которой закодирована архитектура банка, точнее архитектура, поддерживающая ключевые процессы банка согласно списку технологических процессов (ТП), относительно номенклатуры которых тоже возникают вопросы. Если банк ведет (формализует, хранит) архитектуру в xml – файлах Archi (Archimate), то ему нужно будет сделать выгрузку в «другой формат xml» - в формат ф072 (прежде всего разделы 3, 7, 10). Если банк не ведет архитектуру «инструментально», то ему все равно придется ее формализовать «руками» для передачи регулятору в форме ф072 (обычно сперва собирают в excel, потом выгружают в xml). Таким образом ЦБ обязывает каждый банк формализовывать архитектуру (причем детально), что в целом похвально. Даже если в каком-то компоненте изменилась версия с 1.1.1.0 на 1.1.1.1 - нужно это закодировать (отразить) в составе ф072 и своевременно передать «столь важную корректировку» регулятору.
В ф072 (№ 6406-У) и в 850-П перечислены Технологические процессы, которые подлежат учету в части Операционной надежности и по которым «до винтика» должна быть расписана реализующая эти тех-процессы ИТ-система организации. Форма ежеквартальная, т.е. регулятор получает детальный срез архитектуры компании с актуальностью за квартал.
Форма (ф072) содержит не только ИТ-архитектуру: модели серверов и их ПО (CI, Configuration Item) и не только их «упаковку» в АС (автоматизированную систему), например, состав элементов трёхзвенной архитектуры АС. Форма включает привязку АС как к технологическим процессам (ТП) и технологическим участкам (ТУ), так и к бизнес-функциям (читай бизнес-процессам, хотя это «еще то мутное деление»). Эти «архитектурные знания» (детальная информация по ИТ - архитектуре и бизнес-архитектуре) представлены тысячами или десятками тысяч строчек поля 4 разделов 4, 7, 10 формы ф072. Назовем эти строки Арх-строками (архитектурная строка). Пример одной арх-строки приведен в 18-МР: CSV с разделителем «|». В одной арх-строке 34 позиций (34 граф) через разделитель «|» (33 разделителя), но некоторые позиции являются составными через разделитель «-» (например, поз. 3, 4, 8 и 9). По тексту называем «позициями» (блоки в арх-строке), а не «графами» (как регулятор), т.к. тут речь тоже про графы (узлы и ребра), но другие (графа vs граф).
Реализация каждого ТП (открытие счетов, кредитование, вклады, переводы и т.п.) автоматизацией «как на ладони» показана через детальное описание каждого ИТ-��омпонента («винтика»), включая АС, оборудование, прикладное и системное ПО, номер версии, производителя, сертификата и т.п.
Таким образом, общий контекст (ф072 из № 6406-У, 850-П, 18-МР, СТО БР БФБО-1.5-2023 и т.п.):
Операционная надежность -> форма 072 -> арх-строка (закодированная строка для каждой конфигурационной единицы).
Не хватает только инструментов визуализации этих арх-строк.
2 «Обратный отсчет»
Абстрагируемся от того, как (каким инструментом) ведет кредитная организация архитектуру, включая архитектуру ИТ-системы в привязке к процессам: технологическим и бизнес-процессам (бизнес-функциям). Не рассматриваем «прямой отсчет» - подготовку формы ф072, т.е. считаем, что у нас уже есть «официальная 072 форма» и мы хотим ее визуализировать в виде архитектурной картинки. «Руками» ли она была собрана в Excel или выгружена из ARIS \ Sparx Enterprise Architect \ Archi \ CMDB (iTOP) \ архитектурного репозитария на Wiki – не имеет значения: используем данные из обязательной отчетности.
Огромный объем сведений об архитектуре банка, формализованный в этих арх-строках хорошо бы как-то визуализировать. Например, в виде графа (графа архитектуры), еще лучше графа знаний (это указатель в сторону семантических технологий, RDF). Это также поможет обеспечить визуальный контроль с «высоты птичьего полета» итоговой формы перед ее отправкой регулятору.
Причем в форме ф072 есть связка не только АС с бизнес-функциями и ТП, но и между собой (АС-АС), как система – источник и система – приемник данных. Мы имеем огромный граф: 34 позиций и еще под позиции (измерение «в широту», т.е. в составе одной арх-строки) и тысячи \ десятки тысяч арх-строк (измерение «в глубину»), где связи бизнес-архитектуры с ИТ-архитектурой, структура АС, например, звенья трехзвенной архитектуры, а также взаимосвязи source \ target между АС. И конечно детальное описание каждого CI \ ИТ-продукта (компонента). И такая «кладезь» описаний архитектуры компании «зарывается в землю»? Ведь по этим данным можно создать интерактивный граф с реализацией Drill Down (детализация и углубленный анализ), позволяющий перейти от общих, агрегированных показателей к более детальной информации, двигаясь по иерархии данных (drilling down into data).
3 Подготовка графа архитектуры
Из ф072 из поля 4 разделов 3, 7, 10 формируем файл из арх-строк. Далее их парсим (разбор по позициям и под позициям) и перекладываем данные в формат mermaid и смотрим полученное.
В качестве реализации DaC (diagram as code) выбран mermaid только потому, что он встроен в markdown github (не требуется даже активация Pages). В Dot (graphviz, особенно graphviz for excel) или PlantUML (dot «под капотом») было бы лучше, т.к. возможности mermaid скромнее. Можно использовать встроенный в visio автопостроитель - аналог DaC как через штатные мастера (типа mind map), так и через собственный, например, собранный на VBA.
Для упрощения строить схему будем без cluster - без группировки элементов через компонент Кластер \ блок. С cluster будет более структурно и ближе к картинке на Рис. 2.1 Бизнес-процесс и его ИТ-инфраструктура.
Исходная арх-строка - это CSV с разделителем «|», который мы заменяем разделителем “-->” из синтаксиса mermaid. Строки из формата 18-МР\ ф072 (арх-строки) перепишем в формат mermaid и получим граф (DaC / AaC).
Ограничения предложенной реализации Ver1 на github: Исходные данные (DataSet) сгенерированы ИИ и валидны только для отображаемых на схеме параметров (парсер использует не все 34 позиции), т.е. другие параметры «с потолка». Это всего лишь демонстрация подхода через простенький MVP (не следует ожидать многого).
Общая схема для построения упрощенного графа:
1 Выделяем из арх-строки Цепочку: ТП | АС | ИТ-продукт как:
Process -> it-System -> CI, Configuration Item / Конфигурационный Элемент CMDB, Configuration Management Database / База данных управления конфигурацией.
2 Формируем новую цепочку фактически путем замены одного разделителя на другой:
ТП --> АС название + разработчик --> звено Арх Х.Х --> soft / hard и далее детализация ИТ-продукта \ конфигурационной единицы.
3 Согласно синтаксису объектов и связей в mermaid, см.: https://mermaid.js.org/intro/
«Грубо»: разделитель арх-строки "|" (CSV) меняем на "-->" для получения цепочки в формате mermaid:
TП --> АС --> звено Арх Х.Х (например, Арх3.3) --> hard\soft --> CI (Configuration Item)
Например:
graph LR;
ТпрКО3 --> АБС_Банка{{ АБС Банка <br> ЦФТ}} --> Арх3.3 --> software ...
В проекте Form072 показаны примеры визуализации графа по ф072, например, 1.2 TprKO6, no link. Фрагмент с пояснениями показан на рис. 1.
Там же (github) представлено подробное описание реализации: технические \ технологические подробности (см. code и wiki).
Настройки (const CONFIG =) позволяют загружать файл с арх-строками (т.е. предварительно нужно поле 4 раздела 7 выгрузить в файл) или использовать DataSet, размещенный в теле файла html form072_v1.html. Показано как выводить арх-строки тестом и визуализировать в online mermaid = https://mermaid.live/.
ИИ не смог привести нормальной конфигурации и сформировать «более – менее приличный» файл из арх-строк (положил как «анти-паттерн» в репозитарий файлом f072r7v2ai.txt), поэтому примеры «собирались руками».
4 Пути совершенствования Архитектурного графа
Варианты сделать «побольше» и «покрасивши» - это увеличить число отображаемых элементов (других позиций из 34) и раскрасить их через «богатую» нотацию, хоть Archimate. Пример раскраски EPC в mermaid через classDef и cluster, см. mermaid.live (online). Пример DaC на PlantUML с расширением Archimate (статья).
В 18-МР много справочников. Например, отдельным цветом задаем «уровень критичности», например, Mission Critical = красным. Объекты типа «Операционная система» (Клс1) рисуем фигурой одного типа, а Системы виртуализации и контейнеризации (Клс2) – фигурой другого типа. Например:
node3([Форма 3]) или node4[[Форма 4]] или node5[(Форма 5)] – понятно, что последней (Форма 5) лучше обозначать СУБД.
Далее на (супер большой) граф можно будет добавить фильтры: показывать такие-то объекты, например, только Клс1, или скрывать такие-то, например, Клс2. Фильтрами можно показать только резервные элементы или только Критические и т.п., причем фильтры комбинировать. Можно показать только АС – системы и их CI, которые связаны с выбранной АС.
Х��рошо бы еще технологию построения таких «арх-графов» не изобретать «по одиночке» (не городить «велосипеды»), а развивать через crowdsourcing. Простенький form072_v1.html показывает направление (концепт) и пример визуализации, как
Граф архитектуры = DaC \ AaC по арх-строкам ф072.
Развивать лучше видимо не на mermaid. На чем? Рассматриваем только Open Source и «подручное», например, ms visio (+ штатная связка MS с excel – как репозитарием + внешний web publisher). В любом случае, хочется найти сравнение mermaid – инструментов «по мощности»: для визуализации больших данных из тысячи узлов понадобятся видимо какие-то дополнительные манипуляции.
Также не хватает графической нотации (легенды) формализации объектов, как вариант «Archimate-подобное» (PlantUML с расширением Archimate), но и он «чудноват», хорошо хоть это в OG начинают признавать и планируют исправить Archimate. Работают в OG над своими ошибками.
Если будет понимание как сформировать и формализовать логичную структуру (грамотная декомпозиция ИТ-систем и привязка их к бизнес-процессам), то и компании будут готовить ф072 не «на отвали». Пока текущая практика ф072 - это про «нечто запутанное», которое ни сами архитекторы банков, ни ЦБ, ни «сам черт не разберет», - что же там содержится в этих десятках тысяч арх-строк этого «жуть-файла». При этом арх-строки многократно дублируются, и ссылаются друг на друга через какие-то (неформализованные) правила подстановки идентификаторов, например, source-target. Хотя, повторюсь, идея то хорошая.
Конечно есть Open Source EA-инструменты типа Archi (моделирование архитектуры предприятия с ограничением в виде «прибитым гвоздями» ArchiMate) или CMDB-инструменты типа iTOP, но речь о поддержке DaC / AaC (Architecture as Code) и формировании Архитектурных графов по данным ф072 или исходной к ней информации. Еще лучше «Архитектурных графов знаний» как Графов Семантических Связей (SKG, см. ниже).
«Архитектурить графом» по данным формы обязательной отчетности ф072 как показано выше на паре десятков арх-строк - совсем несложно. Однако, огромный объем ф072 даст Большой граф, как показано на рисунках «Визуализация больших графов для самых маленьких», т.е. рост объема данных \ числа узлов и их взаимосвязей будет требовать уже спец-технологии работы с «большими графами».
Еще масштабнее задача – это инструмент «раскрытия сети» (Discovery) и автоматического заполнения паспортов Конфигурационных единиц (ИТ-продуктов в ф072 или CI в ITSM) и их до обогащения (через интернет \ агентов ИИ, RAG) данными о сертификатах ФСТЭК / ФСБ, номеров в реестрах Минпромторга / МинЦифры, см. позиции арх-строки от 19 до 34.
5 Заключение
Чтобы статья выглядела позитивной (тем более в преддверии праздников) – из первоначальной версии удалил критику (ф072, МР-18 и др.). Ограничусь только цитатами некоторых оценок ф072 с профильных ТГ-каналов: «форма душная максимально, чудовищное дублирование, она бесполезная и фактически непроверяемая, она только отражает ход импортозамещения».
Кстати, если кто-то знает «военную тайну», напишите – зачем регулятору нужна ф072 и что он с ней делает?
Посыл статьи: даже несмотря на методологические недочеты ф072 (как формы 0409072, так и 18-МР) ее арх-строки (поля 4 разделов 3, 7, 10) уже сейчас можно выгрузить в граф и получать агрегированную схему архитектуры кредитной организации (в части заявленных регулятором ТП). Достаточно детальные данные («много данных», Big Data) по архитектуре в каждом банке уже есть в ф072 и их можно легко загрузить в графовую витрину.
Это как минимум позволит в банке частично преодолеть проблему «Вавилонской башни»: имея единую агрегированную картинку с ТП, бизнес-процессами (бизнес-функциями), взаимосвязанностью АС (8 и 9 поз.) и с детальной ИТ-инфраструктурой (CI части ИТ-систем, реализующий заданный регулятором перечень ТП) можно вместе на нее смотреть и анализировать (Drill Down, анализ взаимосвязей). Айтишники (ИТ), Ибэшники (ИБ), рисковики (716-П/850-П и другие), процессники (процессный офис), ответственные за ОНиВД и другие команды смогут общаться на «языке графа» (графическое представление их объектов учета, зон ответственности) и проще преодолеть зашоренность и келейность разных подразделений организации.
В идеальной «картине мира ИТ» хотелось бы чтобы форма ф072 и сам подход (вкл. глобальный "крестовый поход" под знаменами «Операционная надежность») строился с учетом интересов архитекторов банка: что им хотелось бы минимизировать в отчетной форме (убрать ненужное) или наоборот, чего не хватает (добавить нужное) для использования данных формы в архитектурной практике организации. При этом речь не только об интересах ИТ-архитекторов организации и менеджерах CMDB, но и корпоративных архитекторов, бизнес (процессных) - архитекторов, риск-офицеров, ИБ-офицеров и даже дата-сайентистов. Да, корпоративная архитектура – это и классификатор бизнес-процессов (когда регулятор начнет делать отечественный / импортозамещенный Banking PCF?) и прочие «смежники».
6 «На шаг» вперед: SKG и технологии BI «на службе» EA (Enterprise Architecture Intelligence)
Если "поднять планку" на постановку задачи и посмотреть на перспективу, то это к Forrester:
The Graphic Future Of IT Management
От классической CMDB к граф-ориентированным операционным моделям ИТ, т.е. к графам зависимостей из сервисов, API, процессов, приложений, серверной и сетевой инфраструктуры, инцидентов, изменений (включая сценарии реагирования на отказы и атаки). Речь про "Единый узел" в виде knowledge graph – в идеале семантическом графе - Semantic Knowledge Graph (SKG), т.е. реализованным на базе (формализованной) онтологии и в стеке Linked Data. В «топку» SKG «кидаем» не только ИТ-архитектуру (CI, конфигурацию, интеграцию), но и артефакты data management, «рабочий план» процессов (процессная модель) по «российскому» APQC Process Classification Framework (рабочий \ общий по аналогии с 809-П) и т.п. А там и "рукой подать" до цифрового двойника ИТ-системы компании или даже всей организации (двойника банка).
Если о "светлом графовом будущем" («архитектурный» BI для EA на базе SKG, вплоть до масштабов «Palantir») пока можно только мечтать, то визуализировать в виде графа уже имеющуюся во всех банках «обязаловку ф072» (пусть и «душную») - не так сложно и может быть даже полезно.
Используемые ссылки (некоторые)
1 Проект Form072 на GitHub
Code https://github.com/bpmbpm/Form072/tree/main/ver1
Wiki https://github.com/bpmbpm/Form072/wiki/18%E2%80%90%D0%9C%D0%A0
https://github.com/bpmbpm/Form072/wiki
Example https://github.com/bpmbpm/Form072/tree/main/example
/850P/f072 https://github.com/bpmbpm/doc/tree/main/IT/reliability_risk/risk/850P/f072
2 Статьи про ОперНадежность
[OpRes24-1] Надежность в процессах. Часть 1
[OpRes24-2] Надежность в процессах. Часть 2
3 Инструменты для ф072
aniva ; medoed ; TAB GRC: Заполнение Поля 4 в разделах отчета ф072
4 Свободные Инструменты ЕА
5 Некоторые НД (больше было указано по тексту)
СТО БР БФБО-1.5-2023 (html ; pdf)
Порядок составления и представления отчетности по форме 0409072 Сведения о показателях операционной надежности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков sudact ; consultant
