Архитектурные принципы как способ управления архитектурой

Ионов Дмитрий Петрович

Корпоративный архитектор ООО «РКС-Холдинг»

• Корпоративный архитектор
• Системный архитектор
• Архитектор информационных потоков
• Руководитель отдела разработки
• Разработчик С\С++\Java\Oracle\Web

2

Компании: РКС, ПСБ, Росатом, ВТБ, Сбер\Сбертех, ПЭК, Московская Биржа и др.

Опыт работы

— инструмент управляемости бизнеса и средство цифровой трансформации. �

3

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

В подавляющем большинстве компаний IT - вспомогательное подразделение, поддерживающее основной бизнес.

IT-архитектура

Но ITшники нацелены на то, чтобы облегчить работу �бизнес-подразделениям.

4

Как найти взаимопонимание �и двигаться в одном направлении?

Установка многих представителей бизнес-подразделений такова:

«

«

Мы деньги зарабатываем, а вы их тратите на свои «ITшные игрушки»

Лица, принимающие решения �со стороны бизнеса, хотят, �чтобы IT-проекты и задачи были с минимальными затратами, �но приносили прибыль �или сокращали расходы.

5

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

Вариант решения

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

6

Структура решения

7

Инструменты архитектурного контроля

Формализация �приёмов и ограничений

Определение архпринципов

Выделяем ключевые понятия, миссии компании

Собираем потребности и «боли» от IT-подразделений и/или конкретных специалистов.

8

Формирование архпринципов

Архитектурные принципы высокоуровневые, в достаточной мере абстрактные утверждения – некие вехи которые обозначают фарватер направления развития IT в компании, отвечающий вектору её развития.

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

Добиваемся расшифровки �и понимания целей, ценностей и задач компании

Знакомимся �с видением компании на ближайшие 5-7 лет, если оно есть �и доступно

Формируем свое общее архитектурное видение ландшафта.

Формируются на основе утвержденных архитектурных принципов.

Важно чтобы Архитектурные требования были достаточно конкретны и понятны для действий �на проекте (проектировании, разработке, внедрении).

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

​

9

Формирование архтребований

Чёткой и однозначной трассировки требований и принципов может и не быть (на ваше усмотрение) важно чтобы сформулированные архтребования помогали достигать цели IT-проектов и выполнять архитектурные принципы.

Одно архитектурное требование может диктовать выполнение одного или нескольких архпринципов полностью или частично.

По большей части архтребования строятся �из технических соображений.

!

Необходимый административный шаг

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

Обсуждение архитектурных требований также должно проходить коллегиально среди ведущих IT-специалистов компании.

10

Утверждение архпринципов должно быть, по возможности, на максимально высоком уровне компании. Как минимум СТО.

Формальное утверждение общего документа содержащего Архитектурные принципы и архитектурные требования возможно среди ведущих IT-специалистов компании в СЭД. Если возможно и на более высоком уровне.

1

2

3

4

Очень важное условие\оговорка во всей этой большой работе!

Не нужно революционных изменений в текущем IT-ландшафте. �Данную методологию применяем к новым проектам.

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

К legacy – по возможности.

!

В большей степени применимы архитектурные требования, как конкретные правила в построении ИС.

11

Применение

Для внутренней разработки

Архитектурные принципы дают основу экспресс- анализа решения на основе технической документации с описанием рассматриваемого решения и его архитектуры.

Для закупки и конкурсных процедур

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

Для внедрения

12

Резюме

Первая реакция на архитектурные принципы «Это же очевидно!». Несмотря на очевидность принципов важно соблюсти их комплексное выполнение.

Задача минимум – не допустить их нарушения. При этом мы понимаем, что архитектурные принципы - лишь инструмент для выстраивания IT-архитектуры предприятия, а она, в свою очередь, инструмент для достижения целей компании.

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

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

Случаи, когда это может �не работать

13

1

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

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

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

Это не волшебная таблетка и даже не серебряная пуля. �А всего лишь способ найти общую точку зрения с руководителями компании и, если нужно, собственниками бизнеса.

2

3

Жить с этим так:

14

1

Использовать когда приходите в новую компанию, где нужно выстраивать архитектурную компетенцию и нужно с чего-то начать можно использовать как методологию.

Когда необходимо построить конструктивный диалог �с бизнес-подразделениями, использовать как способ настройки коммуникаций.

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

Когда нужно повысить управляемость IT ландшафта.

При старте нового IT-проекта, дает чёткое направление выстраивания системы и её структуры.

2

3

4

5

Дополнительные материалы

16

Пример работы в РКСХ

Миссия компании

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

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

Ценности компании

Расшифровка ценностей компании на сайте

Профессионализм

Командность

Эффективность

Надежность

Развитие

Честность

roscomsys.ru/about/missiya/RKS_Values.php

www.roscomsys.ru/about/missiya/RKS_Mission.php

17

1. Цели цифровой трансформации

1.1. Повышение стоимости бизнеса

1.2. Повышение инвестиционной привлекательности

1.3. Улучшение клиентоориентированности

1.4. Повышение уровня информационной безопасности

​

2. Задачи цифровой трансформации

2.1. Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.3. Улучшение управляемости бизнеса

2.4. Трансформация корпоративной культуры бизнеса

2.5. Выход на новые продукты и услуги

2.6. Внедрение лучших отраслевых и мировых практик

2.7. Развитие компетенций персонала

2.8. Поиск и развитие новых цифровых подходов и технологий

Взято из Стратегии цифровой трансформации

ИТ-Архитектура как способ управления цифровой трансформацией и достижение её целей.

18

Архитектурные принципы

19

20

21

*Портируемость – кросплатформенность, возможность развертывания решения на разных платформах без доработок.

22

23

24

25

26

0. Превосходство принципов

Всё выстраивание и перестраивание архитектуры в организации должно вестись согласно основополагающим принципам.

Расшифровка

Что помогает достичь, какие ценности в синергии

Польза для компании

1.1. Повышение стоимости бизнеса

1.2. Повышение инвестиционной привлекательности

1.3. Улучшение клиентоориентированности

2.1 Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.4 Трансформация корпоративной культуры бизнеса 2.5

2.6 . Внедрение лучших отраслевых и мировых практик

2.8 Поиск и развитие новых цифровых подходов и технологий

Последствия / Ограничения

Понятное и централизованное управление архитектурой, и как следствие, бизнесом через Архитектуру. Необходим единый комитет по принятию архитектурных решений.

27

1. Открытость сервисов

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

Расшифровка

Что помогает достичь, какие ценности в синергии

Польза для компании

1.3. Улучшение клиентоориентированности

1.4. Повышение уровня информационной безопасности

2.1. Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.4. Трансформация корпоративной культуры бизнеса

2.6. Внедрение лучших отраслевых и мировых практик

2.8. Поиск и развитие новых цифровых подходов и технологий

Последствия / Ограничения

Открытость конечным пользователям. Высокая доступность интерфейсов. Как вариант развития - OpenAPI.

28

4. Интеграционная независимость

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

Расшифровка

Что помогает достичь, какие ценности в синергии

Польза для компании

1.1 Повышение стоимости бизнеса

1.2. Повышение инвестиционной привлекательности

1.3. Улучшение клиентоориентированности

1.4. Повышение уровня информационной безопасности

Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.3. Улучшение управляемости бизнеса

2.4. Трансформация корпоративной культуры бизнеса

2.6 Внедрение лучших отраслевых и мировых практик

2.8 Поиск и развитие новых цифровых подходов и технологий

Последствия / Ограничения

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

29

7. Гибкость

Гибкость решений как устойчивость к изменениям условий и внешней среды.

Расшифровка

Что помогает достичь, какие ценности в синергии

Польза для компании

1.1. Повышение стоимости бизнеса

1.2. Повышение инвестиционной привлекательности

1.3. Улучшение клиентоориентированности

2.1 Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.3. Улучшение управляемости бизнеса

2.5. Выход на новые продукты и услуги

2.6. Внедрение лучших отраслевых и мировых практик

2.7. Развитие компетенций персонала

2.8. Поиск и развитие новых цифровых подходов и технологий

Последствия / Ограничения

Дает стабильность в обслуживании клиентов и работоспособности IT-систем в условиях изменяющейся внешней среды.

Тщательная работа по функциональной декомпозиции между информационными системами и модулями. Универсализация. По возможности – портируемость*.

*Портируемость – кросплатформенность, возможность развертывания решения на разных платформах без доработок.

30

13. Импортонезависимость

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

Расшифровка

Что помогает достичь, какие ценности в синергии

Польза для компании

1.1. Повышение стоимости бизнеса

1.2. Повышение инвестиционной привлекательности

1.3. Улучшение клиентоориентированности

1.4. Повышение уровня информационной безопасности

2.1. Обеспечение реализации бизнес-стратегии

2.2. Обеспечение устойчивости и конкурентоспособности бизнеса

2.3. Улучшение управляемости бизнеса

2.4. Трансформация корпоративной культуры бизнеса

2.5. Выход на новые продукты и услуги

2.8. Поиск и развитие новых цифровых подходов и технологий

Последствия / Ограничения

Дает независимость от геополитики в обеспечении результатов работы бизнеса.

Необходима выработка алгоритма принятия решения по выбору IT-продуктов.

31

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

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

Обязательны для новых систем. Для дорабатываемых – решается в индивидуальном порядке. Для существующих систем – по возможности.

Архитектурные требования

Наиболее оптимальным для нужд нашего предприятия является брокер сообщений, построенный по принципу издатель-подписчик, так как в одном событии часто заинтересованы несколько потребителей. Как вариант, предлагаю Apache kafka или производный от него продукт. В качестве ETL инструмента предлагаю Apache NiFi или произвольный от него продукт.

1

Каждое архитектурное решение должно быть задокументировано.

• Архитектурное решение должно быть оформлено и виде ADR (Architectural Decision Record)
• Каждая Информационная система и её экземпляр должны иметь паспорт, в котором должны быть отражены: назначение, участие в бизнес-процессах, подразделения, работающие с ней, информационные потоки и интеграции с другими системами и протоколами; для каких объектов данных она является мастер-системой. А так же владелец системы (подразделение), контактное лицо, её актуальная версия в ПРОД, статус (РАЗРАБОТКА, MVP, ОПЭ, ЭКСПЛУАТАЦИЯ, АРХИВ), сервера, виртуальные машины на которых она развернута.
• Каждый программный интерфейс должен иметь детальное описание.
• Бизнес-процесс должен иметь описание с указанием подразделений и систем, которые в нем задействованы, с детализацией до роли исполнителя.
• Каждый объект данных должен иметь описание в канонической модели данных как отдельный документ и как объект передачи данных DTO, со схемой данных.

2

32

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

3

Требования к транспортному пакету: Формат взаимодействия json, кодировка utf-8, любой пакет данных должен давать техническую возможность передавать массив однотипных объектов.

{

"RKSDTO": { // транспортный пакет

"HEAD": { // технический заголовок

"timestamp": "yyyy-mm-dd hh:mi:ss.ssss", // момент создания этого сообщения где yyyy-год, mm-месяц,

// dd-день, hh-час, mi-минута, ss.ssss–секунда с её долями

"protVer": "00.00.00", // версия протокола обмена данными, на текущий момент "01.00.00"

"DTOVer": "00.00.00", // версия объекта данных

"sender": "SystemName", // код или имя системы, которая создала это сообщение

"senderVer": "00.00.00" // версия компонента создавшего это сообщение

},

"BODY": { // содержимое пакета данных

"dataList": [ // коллекция однотипных объектов данных

{

"dataItem": { // объект данных

"field1": "value1", // поля и значения объекта данных

"field2": "value2"

// ...

}

},

{

"dataItem": {

"field1": "value1",

"field2": "value2"

// ...

}

}

// ...

]

}

}

}

​

/**

Наименования полей dataList, dataItem должно быть зависимо от передаваемых данных, чтобы отражать их суть.

Лучше если это будет название из канонической модели данных.

Например если мы передаем данные абонента то рекомендуется сделать имена соответственно

personList и personItem.

**/

“НАЗВАНИЕ ОБЪЕКТА ИЛИ ПОЛЯ” // комментарий к нему

В случае интеграции внутренних систем, предполагающей передачу большого объема данных за 1 раз с возможностью трансформации данных и\или их форматов используется ETL-система (EXTRACT TRANSFORMATION LOAD) из интеграционного слоя.

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

4

Выбор новых IT-решений должен осуществляться следующим образом:

5

5.1. Анализ рынка российского ПО и выбор готового решения как есть или с минимальными доработками.

5.2. Если не удалось выбрать готовое решение в результате выполнения п. 5.1., проводится конкурс среди российских вендоров по разработке необходимого решения и заказ такой разработки.

5.3. Если не устраивают условия по разработке, полученные в п. 5.2., проводится рассмотрение OpenSource продуктов при условии наличия ресурсов на его сопровождение.

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

6

Архитектурная документация на проект должна содержать:

7

7. 1. Потребность и обоснование решения.

7. 2. Архитектурное описание решения: Текстовое описание решения, архитектурные схемы (UML диаграммы) – диаграмма информационных потоков с описанием функциональных блоков и потоков данных достаточной детализацией для понимания решения (на базе компонентной диаграммы), диаграмма развёртывания отражающая вычислительные узлы, сети и подсети, направления вызова одной системы другой, сетевой протокол прикладного уровня, элементы технологического стека. При необходимости, для пояснения поведения систем добавляется необходимое количество диаграмм последовательностей. Так же, при необходимости, может быть добавлена use-cаse диаграмма для пояснения изменений в использовании той или иной системы или систем. Диаграмма данных (ERD) обязательна в том случае, когда вводятся новые объекты данных.

Технологический стек должен быть из импортозамещенных продуктов и продуктов в едином российском реестре ПО. Продукты OpenSource не желательны, их использование необходимо согласовывать дополнительно на архитектурном комитете.

8

Предпочтения:

DBMS – решения на базе PostgreSQL и ClickHouse

Message Broker – решения на базе Apache Kafka

ETL – Решения на базе Apache NiFi

Требования к документации на ИС от вендоров или при внутренней разработке:

9

9. 1. Описание назначения системы, из которого ясно, какие задачи с его помощью можно решить.

9. 2. Коммерческое предложение с описанием стоимости решения, работ по его внедрению и сопровождению продукта с указанными SLA на ответ и решение инцидентов и полного восстановления работоспособности системы, которые должны войти в договор.

9. 3. Архитектурное описание См. п. 7.

9. 4. Четкие системные требования по аппаратному обеспечению, системному программному обеспечению, сетевому оборудованию.

9. 5. Указание на запись в реестре российского ПО.

9. 6. Описание возможностей подключения систем мониторинга.

9. 7. Описание возможностей масштабирования.

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

9. 8. 1. Доступность: допустимое время простоя системы за сутки и суммарно за год.

9. 8. 2. Требования к восстановлению данных и резервному копированию: RPO (Recovery Point Objective) и RTO (Recovery Time Objective).

9. 8. 3. Требования к нагрузке RPS (request per second) при средней нагрузке и при пиковой с заданным размером пакета данных.

9. 8. 3. Требования ко времени отклика системы в секундах при средней нагрузке и при пиковых нагрузках.

9. 8. 4. Требования к информационной безопасности (security): способы и системы аутентификации и авторизации, модель предоставления прав (ABAC/RBAC), необходимость шифрования и его параметры.

9. 8. 5. Требования к эксплуатационной безопасности (safety): описывается индивидуально для систем, управляющих оборудованием, потенциально способным причинить вред здоровью человека, каким образом минимизируются эти риски.

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

36

Пример экспресс анализа системы

На вход получаем архитектурное описание системы, ТЗ где описан функционал.

Пример: Предлагается решение по сбору данных с приборов учета воды, анализ этих данных и предоставление аналитики по потерям воды. Решение предоставляется в виде SaaS на серверах поставщика.

37

Пример экспресс анализа системы

38

39

40

Результат анализа

Рекомендовано отклонить использование этого решения в РКСХ и управляемых обществах. Предлагаю найти альтернативные решения подобного класса удовлетворяющее следующим условиям:

1. Решение должно использовать российские сертифицированные приборы учёта.
2. В рамках такого решения должно использоваться программное обеспечение, зарегистрированное в российском реестре ПО. Так же обладающее требованиям безопасности.
3. Применение облачных технологий возможно в случае частного облака на инфраструктуре РКСХ в закрытом контуре для данных составляющих гостайну.
4. Рекомендовано применение защищенных каналов связи при передаче данных от приборов учета.

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

41

42

Пример такой работы в Атомэнергосбыт (Росатом)

Расшифровка целей

1.1. Сохранение статуса гарантирующего поставщика.

1.1.1. Снижение уровня дебиторской задолженности

1.1.2. Клиентоориентированность, клиентоцентричность.

1.1.3. Сохранение массового сегмента рынка физ. лиц.

1.1.4. Выполнение требований Федерального Законодательства.

1.2. Устранение зависимости от внешней компании-разработчика ПО.

1.3. Увеличение выручки.

1.3.1. Расширение клиентской базы

1.3.1.1. Расширение направлений бизнеса.

1.3.1.1.1. Дополнительные услуги ЖКХ, помимо электроэнергии.

1.3.1.1.2. Предоставление функционала создаваемой платформы как отдельного сервиса (SaaS).

1.3.1.2. Создание условий выхода на новые рынки.

1.3.2. Снижение операционных затрат.

1.3.3. Выход в новые регионы.

1.3.4. Создание централизованного ЕРКЦ в рамках каждого региона присутствия. Каждый местный ЕРКЦ работает через удаленное соединение с централизованным.

1.3.5. Снижение количества ручных операций.

43

Сделано �в Атомэнергосбыт (Росатом)

44

Архитектурные принципы построения Единой цифровой платформы.

Сделано �в Атомэнергосбыт (Росатом)

45

Сделано �в Атомэнергосбыт (Росатом)

46

Сделано �в Атомэнергосбыт (Росатом)

47

Сделано �в Атомэнергосбыт (Росатом)

48

Сделано �в Атомэнергосбыт (Росатом)

Архитектурные требования

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

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

2.3. По уровню логики: 

2.3.1. Бизнес-сервисы - сервисы предоставляющие функционал бизнес уровня. Обязательно предоставляют API с функциями бизнес-уровня.

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

2.3.3. Сервисы уровня данных - сервисы образующие определенный слой под уровнем слоя прикладных сервисов, предоставляющие доступ к данным из БД или интеграционной шины.

2.4. По степени гранулярности:

2.4.1. Информационная система - представляет собой совокупность сервисов и\или микросервисов для решения определенной задачи или класса задач. Обязательно предоставление API администрирования, для построения приложения администратора и мониторинга.

2.4.2. Микросервис - обособленная подсистема выполняющая определенную функцию. Может быть как самостоятельной единицей так и в составе информационной системы.

2.4.3. Библиотека - отдельный модуль выполненный в виде встраиваемого элемента в другие сервисы или системы. Может быть реализован в виде программной библиотеки или микросервиса, экземпляр которого разворачивается вместе с той системой или подсистемой куда он встраивается.

2.5. По Критичности:

2.5.1. Высокая - обеспечение работоспособности в режиме 24/7. Обязательны резервные копии данных, резервные экземпляры работающих модулей, бесшовное обновление и откат. RPO (recovery point objective) = 0. RTO (recovery time objective) 20 мин за раз, не более 121 час в год

2.5.2. Средняя - обеспечение работоспособности в режиме 24/7. Обязательны резервные копии данных. Резервные экземпляры работающих модулей - опционально. Бесшовное обновление и откат опциональны. RPO (recovery point objective) = 20 минут. RTO (recovery time objective) 1 час.

2.5.3. Низкая - для вспомогательных модулей, чей функционал не лежит на критическом пути бизнес-операций. Резервное копирование данных - желательно. Резервные экземпляры работающих модулей - по договоренности с пользователями.  Бесшовное обновление и откат - не требуются. RPO (recovery point objective) = 1 час. RTO (recovery time objective) 2 часа.

49

Сделано �в Атомэнергосбыт (Росатом)

50

Сделано �в Атомэнергосбыт (Росатом)

3. Требования по взаимодействию между модулями.

3.1. Основным интеграционным паттерном является шина предприятия (Enterprise Service Bus - ESB). Реализуется в проекте ЕИП (Единая интеграционная платформа).

3.2. Приоритетный способ взаимодействия между сервисами асинхронный.

3.3. Формат пакетов данных JSON. Рекомендуемый размер  пакета не более 64 килобайт.

3.4. Каждый сервис или микросервис должен поддерживать как минимум 2 интерфейса взаимодействия: 1й - основной, через очереди и обмен сообщениями (MQ и Kafka) через ЕИП. 2й - резервный HTTP Restfull.

3.5. Внешние взаимодействия с ЕЦП осуществляются через отдельно вынесенный в DMZ API-gateway, который обеспечивает безопасность и проксирует вызовы на API - бизнес-сервисов. 

3.6. Все системы для внешних пользователей имеющие пользовательский интерфейс реализуются как самостоятельные системы использующие API-gateway по протоколу HTTPS Restfull JSON.

3.7. Каждый шаг бизнес-процесса должен фиксироваться в журнале аудита событий.

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

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

• Где АА обозначение уровня модуля
• BS - BUSINESS SERVICE (Бизнес сервис)
• AS - APPLICATION SERVICE (Прикладной сервис)
• DS - DATA SERVICE ( Сервис уровня данных)
• BP - BUSINESSES PROCESS (Бизнес-процесс)
• NNNN - Номер высогоуровнего бизнес процесса
• _  -  разделитель
• DDD - номер модуля в рамках высокоуровнего бизнес-процесса  (информационной системы или бизнес-сервиса)
• МММ - номер микросервиса или библиотеки текущей системы 
• LIB - добавка для модуля библиотеки

51

Сделано �в Атомэнергосбыт (Росатом)

Правила формирования обозначений

Шаблон

AANNNN_DDD_MMM_LIB

Реестр бизнес-процессов

52

Сделано �в Атомэнергосбыт (Росатом)

53

Сделано �в Атомэнергосбыт (Росатом)

54

Сделано �в Атомэнергосбыт (Росатом)

Ионов Дмитрий Петрович

Корпоративный архитектор ООО «РКС-Холдинг»

+79851934152

dmionov@roscomsys.ru

@dmitry_ionov

​