1. АРХИТЕКТУРА ПРЕДПРИЯТИЯ:
ИНТЕГРАЦИИ ПРИЛОЖЕНИЙ КОМПАНИИ
MARCUS AURELIUS LTD
Г. МОСКВА
2015 ГОД, ДЕКАБРЬ
Pont du Gard — самый высокий сохранившийся древнеримский акведук

2. СТРАНИЦА 2
ТЕМА 1. ПРОБЛЕМА УНИФИКАЦИИ
ИНФОРМАЦИОННЫХ МОДЕЛЕЙ
Подход к унификации информационных
моделей при проектировании распределенных
информационных систем с неоднородными
информационными ресурсами.
MARCUS AURELIUS LTD
MARCUS AURELIUS
Б И З Н Е С К А К Ф И Л О С О Ф И Я

3. СТРАНИЦА 3
Ключевые слова:
 информационная модель;
 семантика информационной модели;
 отображение моделей;
 каноническая модель;
 принцип уточнения;
 верификация уточнения моделей;
 унификатор информационных моделей;
 метакомпиляция
КЛЮЧЕВЫЕ СЛОВА

4. СТРАНИЦА 4
Задачи интеграции неоднородных источников данных и задачи создания композитных ИС (систем,
состоящих из нескольких разрозненных компонентов) являются актуальными в настоящее время. Причина:
наработанная практика лоскутной автоматизации, причем лоскутность не всегда является недостатком
проектирования, а скорее следствием хаотичной истории развития компании и ее бизнеса.
С этой целью развиваются и трансформируются такие интеграционные технологии (технологии
промежуточного слоя), как CORBA, Java RMI, .NET, Web Services, Semantic Web, Grid и другие. В рамках
внедрений на базе этих технологий накоплено большое количество программных и информационных
технически интероперабельных компонентов.
Технологии промежуточного (интеграционно-композитного) слоя (связующее ПО):
 обеспечивают техническую возможность интеграции источников и конструирования распределенных,
интероперабельных ИС из компонентов;
 позволяют накапливать репозитории компонентов для их дальнейшего использования при создании
новых ИС.
В ходе интеграции данных и создания композитных систем возникает задача достижения семантической
интероперабельности компонентов.
ИНТЕГРАЦИЯ И КОМПОЗИЦИЯ НЕОДНОРОДНЫХ ИС

5. СТРАНИЦА 5
Достижение семантической интероперабельности характеризуется следующими
чертами:
 Релевантность подобранных компонентов разрабатываемому применению,
 Соответствие их прикладных контекстов контексту применения,
 Непротиворечивость интероперабельной композиции ресурсов в контексте
разрабатываемого применения.
СЕМАНТИЧЕСКАЯ ИНТЕРОПЕРАБЕЛЬНОСТЬ
Интероперабельность обеспечивает предметный посредник.
Предметный посредник предназначен для преобразования несистематизированного набора
информационных источников, предоставляемых различными провайдерами, в хорошо
структурированную (систематизированную) коллекцию однородных спецификаций.
Посредник обеспечивает пользователей метаинформацией, однородно представляющей
предметный контент охватываемых источников, поддерживает унифицированную (каноническую)
информационную модель, а также обеспечивает интероперабельность провайдеров информации
(или взаимодействующих агентов (пользователей)).

6. СТРАНИЦА 6
«ВАВИЛОНСКАЯ БАШНЯ» ИНФОРМАЦИОННЫХ МОДЕЛЕЙ
НЕОБХОДИМА КОРРЕЛЯЦИЯ ИНФОРМАЦИОННЫХ МОДЕЛЕЙ РАЗНОРОДНЫХ
ИНФОРМАЦИОННЫХ РЕСУРСОВ
Данные, накапливаемые в компании, оформляются в виде
информационных ресурсов, каждый из которых организован
согласно определенной информационной модели.
Marcus Aurelius ltd.
Информационная модель (или модель представления
информации) состоит из языков для описания:
 структуры информации;
 семантики информации;
 операций, определяющих характерные преобразования
информации в заданной модели.
В основе различных моделей лежат разнообразные парадигмы и
понятия, не совместимые между собой.
Число информационных ресурсов быстро растет и это вызывает
потребность совместного использования таких ресурсов (интеграции
ресурсов).

7. СТРАНИЦА 7
КАНОНИЧЕСКАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ
СОЗДАНИЕ ИНТЕРОПЕРАБЕЛЬНЫХ И КОМПОЗИТНЫХ РЕШЕНИЙ ВОЗМОЖНО ТОЛЬКО ПРИ
ИСПОЛЬЗОВАНИИ КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ
Варианты совместного использования информационных ресурсов:
 Интероперабельность и композитное поведение – совместная работа ресурсов при решении
конкретной задачи. При этом композиция ресурсов, выполняющих совместную работу, должна
семантически реализовывать части этой задачи или даже всю задачу в целом.
 Информационная связность - семантическое отождествление объектов, представленных в
различных информационных моделях, например, семантическое отображение схемы нескольких
разрозненных ресурсов в глобальную схему.
Для совместного использования неоднородных ресурсов требуется приведение различных
информационных моделей к унифицированному виду в рамках унифицирующей информационной
модели. Такая модель называется канонической.
Marcus Aurelius ltd.

8. СТРАНИЦА 8
ТЕМА 2. ЗАДАЧА ПОСТРОЕНИЯ
КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ
МОДЕЛИ РАСПРЕДЕЛЕННОЙ КОМПАНИИ
Постановка задачи построения канонической информационной модели и
канонических сервисов для крупной организации.
MARCUS AURELIUS LTD

9. СТРАНИЦА 9
ЗАЧЕМ? – ПРЕДПОСЫЛКИ ЗАДАЧИ
Marcus Aurelius ltd.
НЕОБХОДИМО: ПОСТРОИТЬ УНИФИЦИРОВАННУЮ МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ ИНФОРМАЦИОННЫХ СИСТЕМ ДЛЯ
ЦЕЛЕЙ СНИЖЕНИЯ СЛОЖНОСТИ УПРАВЛЕНИЯ СТОЛЬ БОЛЬШИМ ИНТЕГРАЦИОННЫМ ПОЛЕМ
В рамках проекта по инвентаризации информационных систем компании Ростелеком (на январь 2016 года)
выявлено и занесено в QPR (программный инструмент класса Enterprise Architect) в виде паспортов более
9000 (!) инфопотоков.
Примечание: инфопотоки представляют собой передачу данных, команд или событий между ИС.
При анализе этих инфопоток, спроектированных и запрограммированных в разное время разными
коллективами разработчиков, выявляются конфликты данных, передаваемых в инфопотоках:
 конфликты именования (в различных ИС используется различная терминология, что приводит к
омонимии и синонимии в именовании)
 семантические конфликты
 выбраны различные уровни абстракции для моделирования подобных сущностей реального мира
 структурные конфликты (одни и те же сущности представляются в разных источниках разными
структурами данных).
Как следствие имеем аналогичные конфликты самих инфопотоков.
Полный перечень функций и инфопотоков, полученный из материалов, представленных ИТ-службами МРФов
и КЦ Ростелекома, отражает то, что хотели построить разные люди, в разное время на удаленных друг от
друга территориях.

10. СТРАНИЦА 10
СЛУЖБЫ/СЕРВИСЫ
Marcus Aurelius ltd.
ОБНАРУЖЕНИЕ СЛУЖБЫ И СОГЛАСОВАНИЕ КОНТРАКТА С НЕЙ – ВАЖНЕЙШИЕ
СОСТАВЛЯЮЩИЕ SOA-АРХИТЕКТУРЫ
Проблемы в существующей архитектуре приложений РТК:
 Во многих информационных системах выявлена избыточная функциональность. Каждую
из таких функций можно было бы вынести за пределы приложения и оформить в виде
функций совместного использования, доступных всем системам в виде служб (или
сервисов).
 Служба (сервис) - это строго определенная и универсально доступная функция (или набор
функций), реагирующая на запросы своих потребителей.
 Интегрируемым приложениям должен быть предоставлен доступ к централизованному
списку всех служб (каталогу служб).
 Описание интерфейса каждой службы должно способствовать согласованию контракта
взаимодействия приложений с этой службой.
 Обращение к сервисам и переход к SOA будет полезен прежде всего при внедрении новых
систем, а так же при выводе систем из эксплуатации

11. СТРАНИЦА 11
АРХИТЕКТУРА СЕРВИСА
СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ В ОДИН УНИФИЦИРОВАННЫЙ И
ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ
Marcus Aurelius ltd.
СЕРВИС – ЛОГИЧЕСКАЯ ЕДИНИЦА ПРОЕКТИРОВАНИЯ. СОВОКУПНОСТЬ СЕРВИСОВ ОБРАЗУЕТ ПРИЛОЖЕНИЕ. ОДИН
СЕРВИС МОЖЕТ БЫТЬ ОДНИМ ПРИЛОЖЕНИЕМ ИЛИ ЕГО МОДУЛЕМ.

12. СТРАНИЦА 12
СЕРВИС. ФУНКЦИИ –МЕТОДЫ-ОБЪЕКТЫ
Marcus Aurelius ltd.
МЕТОД – частный случай функции. Мы используем понятие «метод» вместо «функция», когда
можно четко выделить Объект, к методу которого мы хотим обратиться.
Объект
Метод 3
Функция 1
Функция 2
Функция 3
API-1.1
API-1.2
API-1.3
Метод 1
Объект
Объект
Объект
Метод 2
API – описывает контекст (как информационный, а часто и событийный) и правила применения
функций/методов.
API

13. СТРАНИЦА 13
СПЕЦИФИКАЦИЯ(КОНТРАКТ)
СЕРВИСА
ТЕЛОСЕРВИСА
СЕРВИС. ФУНКЦИИ –МЕТОДЫ-ОБЪЕКТЫ
Marcus Aurelius ltd.
СЕРВИС – это функции или методы, выставленные приложением наружу в единой манере
(согласно унифицированному контракту) для обращения к ним со стороны приложений-
потребителей. Как правило, это Web-сервисы, описанные в стилях REST, SOAP, HTTP и т.п.
Сервис применяется к объекту данных или его атрибутам.
Объект
Метод 3
Функция 1
Функция 2
Функция 3
Метод 1
Объект
Объект
Объект
Метод 2

14. СТРАНИЦА 14
СЕРВИС ПРИЛОЖЕНИЯ В ARCHIMATE® 2.1 SPECIFICATION
Marcus Aurelius ltd.
Сервис приложения - это поведение приложения, реализующее одну или группу бизнес-
значимых операций (транзакций) для внешних по отношению к приложению заинтересованных
агентов (потребителей).
Сервис приложения представляет функциональность компонентов приложения для других приложений. Эта
функциональность доступна через интерфейсы приложения (API).
Сервис приложения реализуется одной или несколькими функциями приложения, которые исполняются
компонентом/модулем приложения. В рамках функции могут запрашиваться, использоваться и создаваться
объекты данных.
Сервис приложения должен быть значащим с точки зрения окружения приложения; он должен
представлять единицу функциональности, которая по своей природе полезна для ее потребителей.
Например, если окружение состоит из бизнес-процессов, сервисы приложения должны быть актуальны для
этих бизнес-процессов, то есть реализовывать те или иные транзакции бизнес-процесса. Сервис
приложения может иметь доступ к данным и предоставлять/принимать данные.
Имя сервиса приложения желательно должно быть отглагольным существительным. Так же может
использоваться имя, которое явно содержит слово «Сервис».

15. СТРАНИЦА 15
Внутренний мир приложений
Marcus Aurelius ltd. +7 985 922 12 40 Рудь Виктор
Каждая система имеет своё
поведение, моделируемое
аналитиком через список функций.
Наружу, во внешний мир, система
выставлена в виде совокупности
предоставляемых сервисов.
Таким образом, функции – это взгляд
на систему изнутри. Сервисы –
взгляд на систему снаружи.
Ясно, что госсервисы (госуслуги)
отличаются от функций государства.
Здесь (в информационных системах)
такая же аналогия.
ДВА ВЗГЛЯДА НА ПРИЛОЖЕНИЕ: ИЗНУТРИ И СНАРУЖИ
Сервис Е2
функция
функция
функция
функция
функция
функция
функция
функция
функция
функция
функция
функция
Сервис Е1
Сервис В2
Сервис В1
Сервис А2
Сервис А1
Сервис D2
Сервис D1
Сервисы – это то, как приложения
представлены друг другу для взаимодействия
Так систему B видят
приложения А,E,D

16. СТРАНИЦА 16
Реестр сервисов
АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ НА СЛУЖБЫ
Marcus Aurelius ltd.
Приложение-посредник (среда передачи сообщений = среда взаимодействия)
Сервис Х
функции
методы
методы
Сервис Х+1
функции
методы
методы
Приложение
функции
методы
методы
Сервис Х
Сервис Х+1
Сервис Х+2
…
Сервис N
функции
Запрос функции или данных
Адаптер Х Адаптер Х+1 Адаптер

17. СТРАНИЦА 17
СЕРВИС ПРИЛОЖЕНИЯ: МЕСТО В АРХИТЕКТУРЕ
Marcus Aurelius ltd.
На архитектурных диаграммах сервисы приложения
могут быть связаны прямо или косвенно с:
 бизнес-процессами;
 бизнес- функциями;
 бизнес-взаимодействиями;
 функциями приложений;

18. СТРАНИЦА 18
SOA-АРХИТЕКТУРА
Marcus Aurelius ltd.
РАЗРАБОТКУ НОВОГО ПРИЛОЖЕНИЯ В РАМКАХ СУЩЕСТВУЮЩЕЙ SOA-АРХИТЕКТУРЫ
МОЖНО СРАВНИТЬ С СОЗДАНИЕМ РАСПРЕДЕЛЕННОГО ПРИЛОЖЕНИЯ
SOA-архитектура стирает грань между интеграцией приложений и созданием
распределенного приложения.
При создании нового приложения разработчики могут использовать службы
(сервисы), предоставляемые существующими приложениями.
В этом случае обращение к службе может рассматриваться как интеграция
приложений. Однако, во многих SOA-архитектурах, вызов внешней службы ничем
не отличается от вызова локального метода (за исключением производительности).
-
-
-
-
-
-
-
-

19. СТРАНИЦА 19
РАСПРЕДЕЛЕННЫЙ БИЗНЕС-ПРОЦЕСС
Marcus Aurelius ltd.
SOA-АРХИТЕКТУРА И РАСПРЕДЕЛЕННЫЙ БИЗНЕС-ПРОЦЕСС ИМЕЮТ МНОГО ОБЩЕГО, ПОСКОЛЬКУ ВСЕ
ТРЕБУЕМЫЕ БИЗНЕС-ФУНКЦИИ МОЖНО ПРЕДСТАВИТЬ В ВИДЕ WEB-СЛУЖБ, ЧТО СООТВЕТСТВУЕТ КОНЦЕПЦИИ
SOE – СЕРВИС-ОРИЕНТИРОВАННОГО ПРЕДПРИЯТИЯ. ТАКИМ ОБРАЗОМ БИЗНЕС-ПРОЦЕСС МОЖНО РЕАЛИЗОВАТЬ
ВНУТРИ ОБРАЩАЮЩЕГОСЯ К WEB-СЛУЖБАМ ПРИЛОЖЕНИЯ
Необходимость в интеграции приложений возникает по двум причинам:
1. Во многих случаях вся функциональность, необходимая для выполнения одной бизнес-транзакции,
сконцентрирована в одном из существующих приложений компании. Но если в выполнении одной
бизнес-транзакции, например, размещение заказа клиентом участвует нескольких различных систем
компании, то эти системы нужно интегрировать.
2. Бизнес-процесс компании – это, как правило, целая цепочка взаимосвязанных бизнес-транзакций,
исполняемых при поддержке различных систем компании. Вся эта цепочка должна контролироваться
от начала и до конца с использованием ПО. Для координации выполнения цепочки бизнес-транзакций
используется компонент управления распределенным бизнес-процессом.
- - -

20. СТРАНИЦА 20
API - СПЕЦИФИКАЦИЯ
Marcus Aurelius ltd.
Спецификация API позволяет описать правила доступа к какому-либо объекту или
набору связанных общим бизнес-смыслом объектов.
Спецификация API включает в себя:
 описание модели данных, использованных в методах, с описанием смысловой нагрузки
объектов данных, их атрибутов, связей между ними;
 операции (методы), применимые к этим данным;
 нотификации, информирующие о событиях, связанных с изменениями объекта данных;
 множество базовых статусов объекта с описанием правил изменений этих статусов
ТАКИМ ОБРАЗОМ, API ПОЗВОЛЯЕТ ПОЛНОСТЬЮ ОПИСАТЬ СЕМАНТИКУ
ПРАВИЛ РАБОТЫ С ДАННЫМИ ИЗ ОПРЕДЕЛЕННОЙ ОБЛАСТИ

21. СТРАНИЦА 21
МЕТАМОДЕЛЬ ДЛЯ МОДЕЛИРОВАНИЯ ВЗАИМОДЕЙСТВИЙ
Marcus Aurelius ltd.
НА КАКИЕ ВОПРОСЫ И КАКИМ ОБРАЗОМ ПОЗВОЛЯЕТ ОТВЕТИТЬ СОБРАННАЯ В
РАМКАХ МЕТАМОДЕЛИ ИНФОРМАЦИЯ?
Структура модели: системы, функции, интерфейсы, интеграции, данные
Application YApplication X
Application
Function
Application
Interface
Application
Function
Application
Interaction
(ИНФОПОТОК)
Application
Collaboration
Application
Interface
Data Object
Application YApplication X
Application
Function
Application
Interface
Application
Function
Application
Interaction
(ИНФОПОТОК)
Application
Collaboration
Application
Interface
Data Object

22. СТРАНИЦА 22Marcus Aurelius ltd.
Каноническая модель позволит:
 При работе с большим количеством приложений минимизировать количество трансляторов
сообщений, которые применяются для устранения различий в форматах сообщений, которыми
могут обмениваться приложения при передаче данных от одной ИС к другой;
 Упростить вывод из эксплуатации унаследованных ИС при построении интеграций с новой ИС;
 Из общего множества данных, обрабатываемых в ИС компании, выделить те, которые участвуют в
интеграционных взаимодействиях и привести их к каноническому виду;
 Разработчикам и бизнес-пользователям обсуждать интеграционное решение в унифицированных
терминах сферы деятельности компании (а не конкретной реализации ИС);
 Полезно было бы построить каноническую модель данных на промежуточном слое (интеграционной
шине) и обращаться к этим данным с помощью канонических сервисов
Каноническая модель
Инфопоток 1
КАНОНИЧЕСКАЯ МОДЕЛЬ
Система -
потребитель сервиса
Система –
поставщик сервиса
Сервис 1
Инфопоток 2
Сервис 2
API1
API2

23. СТРАНИЦА 23Marcus Aurelius ltd.
Канонические сервисы позволят:
 Выделить классы подобных с точки зрения
бизнеса функций, выставленных ИС наружу,
и объявить их как сервисы;
 Унифицировать правила именования
функций, представленных в качестве
сервисов;
 Определить перечень сервисов,
предоставляемых каждой ИС для применения
оптимального подхода к построению
взаимодействий этой ИС с ее окружением;
 Определить мастер-систему по каждому
классу данных, выделенных в канонической
модели;
 Упростить и унифицировать приземление
целевых бизнес-процессов компании на ИТ-
ландшафт.
Канонические
сервисы
КАНОНИЧЕСКИЕ СЕРВИСЫ
Сервис1
Сервис 2

24. СТРАНИЦА 24
ТЕМА 3. ПОДХОД К ПОСТРОЕНИЮ
КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ
МОДЕЛИ РАСПРЕДЕЛЕННОЙ КОМПАНИИ
Применение описанного подхода к построению канонической информационной
модели в условиях крупной организации.
MARCUS AURELIUS LTD

25. СТРАНИЦА 25
МЕТОДОЛОГИЯ ПОСТРОЕНИЯ КАНОНИЧЕСКОЙ МОДЕЛИ ДАННЫХ
• Выделение типов объектов данных,
которые участвуют в интеграционных
взаимодействиях, унификация их
именования и описания;
• Классификация полученных типов объектов
данных в соответствии с доменами
телекома
• Группировка типов объектов данных в
каждом домене для формирования базовых
бизнес-объектов;
• Анализ модели данных ЕКХД;
• Анализ типов объектов данных,
передаваемых в инфопотоках;

26. СТРАНИЦА 26Marcus Aurelius ltd.
Данные классифицируются с применением следующего подхода:
 При моделировании данных различаются 3 уровня:
Бизнес-уровень – понятия, которыми оперирует бизнес (тезаурус);
Логический уровень – представление понятий, которыми оперирует бизнес, в виде
объектов и взаимосвязей между этими объектами;
Физический уровень представляет объекты логического уровня в виде,
обеспечивающем корректную реализацию на уровне СУБД ( напр., в виде таблиц
реляционной БД, классов в объектно-ориентированной БД и т.п.)
 Логический уровень позволяет разобраться в структуре информации: выделить сущности ,
их отдельные важные атрибуты, а так же связи между сущностями.
 Логический уровень сглаживает различия между бизнес-уровнем и физическим уровнем и
служит базой для ведения диалога между представителями бизнеса и разработчиками ПО;
 Каноническая модель -это модель логического уровня;
 На начальном этапе анализа предметной области мы не пытаемся опуститься на уровень
логической модели. Скорее, мы выделяем домены, с помощью которых можно выделить
или классифицировать понятия, применяемые в области бизнеса и использующиеся в
моделях различных ИС компании.
МЕТОДОЛОГИЯ КЛАССИФИКАЦИИ ДАННЫХ
Этот уровень мы
не
рассматриваем
КЛАССИФИКАЦИЯ ДАННЫХ ПОМОЖЕТ ПОСТРОИТЬ КАНОНИЧЕСКУЮ МОДЕЛЬ И
ВЫПОЛНИТЬ КЛАССИФИКАЦИЮ МЕЖСИСТЕМНЫХ ВЗАИМОДЕЙСТВИЙ.

27. СТРАНИЦА 27Marcus Aurelius ltd.
МЕТОДОЛОГИЯ МНОГОУРОВНЕВОГО ПРЕДСТАВЛЕНИЯ ДАННЫХ
Физ.Лицо домохозяйство Фабрика
ДОМЕН: КЛИЕНТ
Клиент-ФЛ
Информационная модель
(логическая)
ФИО
Возраст
Паспорт
Клиент-ЮЛ
Название
Форма собственности
Расчетный счет
Банк
Домохозяйство
Адрес
Тип
ЛПР Таблицы БД
(Физическая модель)
Персона
Фамилия
Имя
Отчество
Возраст
Документ
Тип (ex, Паспорт)
Номер
Дата выдачи
Орган выдачи
Срок действия
Адрес
Город
Индекс
Улица
Дом
Строение
Организация
Название
Форма собственности
Банковские реквизиты
Реквизиты счета
Название банка
БИК
Расчетный счет
Валюта счет

28. СТРАНИЦА 28
ВАРИАНТ№1: МЕТОДОЛОГИЯ ВЫЯВЛЕНИЯ ГРУПП РОДСТВЕННЫХ
ВЗАИМОДЕЙСТВИЙ: КЛАССИФИКАЦИЯ ИНФОПОТОКОВ
MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
МЕЖСИСТЕМНЫЕ ВЗАИМОДЕЙСТВИЯ КЛАССИФИЦИРУЮТСЯ ПО ПРИЗНАКУ ПЕРЕДАВАЕМОЙ ИНФОРМАЦИИ

29. СТРАНИЦА 29Marcus Aurelius ltd.
Классификация инфопотоков будет многоуровневой.
I уровень классификации инфопотоков будем строить от данных, в отношении которых
происходит взаимодействие в рамках каждого инфопотока.
Даже в том случае, когда инфопоток непосредственно не передает данные (напр., передается событие,
срабатывает как триггер), результатом работы инфопотока является операция, выполняемая над данными.
По аналогии с классификацией данных, при первичной классификации инфопотоков используем домены:
инфопоток, оперирующий данными, отнесенными к некоторому домену, приписывается к тому же
домену.
Для определения уровня II и следующих уровней классификации инфопотоков используем различные
критерии классификации:
 Понятия бизнес уровня или логические сущности;
 Типы операций над данными;
 Типы взаимодействий в отношении данных.
Таким образом могут быть определены классификационные домены 2-ого уровня.
Один и тот же инфопоток может быть отнесен одновременно к двум и более классификационным доменам
МЕТОДОЛОГИЯ КЛАССИФИКАЦИИ ИНФОПОТОКОВ ДЛЯ РОСТЕЛЕКОМ
ПОСТРОЕНИЕ КАНОНИЧЕСКОЙ МОДЕЛИ ДАННЫХ ПОМОЖЕТ БОЛЕЕ ТОЧНО
ВЫПОЛНИТЬ КЛАССИФИКАЦИЮ ИНФОПОТОКОВ И ИДЕНТИФИЦИРОВАТЬ СЕРВИСЫ.

30. СТРАНИЦА 30
ПЕРЕХОД ОТ КЛАССОВ ИНФОПОТОКОВ К СЕРВИСАМ
НА ОСНОВАНИИ РЯДА ФАКТОРОВ, ОТДАВАЯ ПРИОРИТЕТ ГРУППИРОВКЕ ИНФОПОТОКОВ, МЫ
ВЫДЕЛЯЕМ БУДУЩИЕ СЕРВИСЫ ЕДИНОЙ ИТ-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ
Сервис
управления
заказами
Сервис
управления
клиентами
Сервис
управления
услугами
Сервис
управления ТТ

31. СТРАНИЦА 31
ВАРИАНТ№2: МЕТОДОЛОГИЯ ВЫЯВЛЕНИЯ МИКРОСЕРВИСОВ
НА БАЗЕ МЕТОДОВ
• ОПИРАЯСЬ НА РЕЕСТР ИНОПОТОКОВ, МЫ ОПРЕДЕЛЯЕМ НАБОР ФУНКЦИЙ, КОТОРЫЕ ВЫЗЫВАЮТСЯ В
РАМКАХ МЕЖСИСТЕМНЫХ ВЗАИМОДЕЙСТВИЙ.
• ЕСЛИ ЭТИ ФУНКЦИИ ПРИМЕНЯЮТСЯ К ОДНОМУ И ТОМУ ЖЕ ТИПУ ИНФОРМАЦИИ, ОНИ МОГУТ БЫТЬ
ОБЪЕДИНЕНЫ ДЛЯ ПРЕДСТАВЛЕНИЯ ОКРУЖЕНИЮ ОДНОГО МЕТОДА.
• КАЖДЫЙ ИЗ ПОЛУЧЕННЫХ МЕТОДОВ МЫ ОПРЕДЕЛЯЕМ КАК МИКРОСЕРВИС (Т.Е. ТАКОЙ СЕРВИС,
КОТОРЫЙ ПРЕДСТАВЛЯЕТ ОКРУЖЕНИЮ ОДИН УНИФИЦИРОВАННЫЙ МЕТОД).
МИКРОСЕРВИСЫ ОБЕСПЕЧАТ ПРОСТОТУ И
ГИБКОСТЬ СОЗДАНИЯ ЛЮБОЙ КОНСТРУКЦИИ ИЗ
БОЛЕЕ МЕЛКИХ КОМПОНЕНТОВ.

32. СТРАНИЦА 32
ВАРИАНТЫ РАЗВИТИЯ ПАРАДИГМЫ
КАНОНИЧЕСКИХ СЕРВИСОВ
MARCUS AURELIUS LTD.
СОЗДАНИЕ КОМПОЗИТНЫХ СЕРВИСОВ ОСТАЕТСЯ ЗА РАМКАМИ НАШЕГО РАССМОТРЕНИЯ!
API
управления
заказами
API
управления
клиентами
API
управления
услугами
API
управления ТТ
• ИЗ ПОЛУЧИВШИХСЯ МИКРОСЕРВИСОВ ВСЕГДА МОЖНО БУДЕТ СОЗДАТЬ ЛЮБОЙ КОМПОЗИТНЫЙ
СЕРВИС
• КОМПОЗИТНЫЕ СЕРВИСЫ МОЖНО БУДЕТ СФОРМИРОВАТЬ, НАПРИМЕР, ГРУППИРУЯ
МИКРОСЕРВИСЫ ВОКРУГ ОБЪЕКТОВ ДАННЫХ КАНОНИЧЕСКОЙ МОДЕЛИ
• НА ЭТОЙ ЖЕ ОСНОВЕ МОЖНО ОПИСАТЬ БУДУЩИЕ API ЕДИНОЙ ИТ-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

33. СТРАНИЦА 33
РЕШЕНИЯ ДЛЯ ОПТИМАЛЬНОГО РАЗВИТИЯ
ИТ-ЛАНДШАФТА КОМПАНИИ
Marcus Aurelius ltd.
Построить каноническую модель данных:
Позволит описать все типы объектов данных, в отношении которых взаимодействуют
информационные системы всей большой компании.
Определить набор микросервисов:
Микросервисы позволят определить полный набор методов, применимых к данным
канонической модели.
Определить набор унифицирующих композитных сервисов:
Унифицирующие сервисы позволят абстрагироваться от деталей реализации семантически
подобных микросервисов в различных информационных системах и предоставить окружению
единый сервис, реализующий тот или иной метод, в каком бы конечном приложении он не
исполнялся. Оркестровку по реализации таких сервисов, предоставляемых различными
системами-провайдерами информации, можно возложить на интеграционного посредника.
Область применения
Все описанные действия не стоит применять тотально. Они нужны в случае множественного
обращения различных ИС к определенным типам объектов данных, множественного
обращения ИС к функциям, претендующим быть названными микросервисами.
Все перечисленные операции выполняются на логическом уровне
ТАКИМ ОБРАЗОМ, НА ЛОГИЧЕСКОМ УРОВНЕ МОДЕЛИРОВАНИЯ
МЫ ДОСТИГАЕМ СЕМАНТИЧЕСКОЙ УНИФИКАЦИИ

34. СТРАНИЦА 34
В ЧЕМ ПОЛЬЗА СЕМАНТИЧЕСКОЙ УНИФИКАЦИИ?
Повышение эффективности работы
 При выведении ИС из эксплуатации мы всегда будем понимать, какие сервисы она
предоставляла окружению (объем доработок) и какие сервисы использовала (что можно
отключить/ не поддерживать).
 При внедрении новой системы у нас будет унифицированный набор сервисов, правил
обращения к ним, унифицированная модель данных. Это поможет четко выставить
требования к интеграции для новой системы.
 Можно просто сконструировать любое распределенное решение, понимая каким
инструментарием мы обладаем, а какой нужно заново разработать. Но, то что
накоплено в арсенале компании всегда можно переиспользовать.
 Устранить эффект «Вавилонской башни» в процессе коммуникаций с представителями
бизнеса, работающими во всех ИС компании, да и внутри подразделений ИТ-блока.
Marcus Aurelius ltd.
ГИБКОСТЬ, СКОРОСТЬ, МИНИМИЗАЦИЯ ЗАТРАТ ПРИ РЕШЕНИИ КАК
СТАНДАРТНЫХ, ТАК И СЛОЖНЫХ ЗАДАЧ!

35. MARCUS AURELIUS LTD.
КОНТАКТЫ ДЛЯ СВЯЗИ
Рудь, Ковальчук, Красинская
ООО «МАРК АВРЕЛИЙ»
http://www.consulo.ru
E-mail: v.rud @consulo.ru
Телефон: +7 (495) 922-12-40
Не отказывайся от помощи, особенно
когда это связано с исполнением долга.
Многое из того, что не удаётся сделать
в одиночку, может быть легко
достигнуто, если действовать сообща…
Марк Аврелий
MARCUS AURELIUS LTD.

36. WWW.MARCUS-AURELIUS.RU
Рудь Виктор Геннадиевич
Директор по консалтингу
ООО «МАРК АВРЕЛИЙ»
e-mail: v.rud @consulo.ru
Телефон: +7 (495) 922-12-40
Marcus Aurelius ltd.

37. СТРАНИЦА 37
ПЕРЕХОД К СЕРВИСАМ
ФУНКЦИИ
ПРИЛОЖЕНИЯ
ОБЕСПЕЧИВАЮЩЕЕ
ПРИЛОЖЕНИЕ
СЕРВИС
ДОСТУПНОСТЬ
СЕРВИСА для
ИСПОЛЬЗОВАНИЯ
СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ
В ОДИН УНИФИЦИРОВАННЫЙ И ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ
С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ
ДАННЫЕ
ПРИЛОЖЕНИЯ
Marcus Aurelius ltd.

38. СТРАНИЦА 38
ПОСЛЕДОВАТЕЛЬНОСТЬ ПЕРЕХОДА К СЕРВИСАМ
MARCUS AURELIUS LTD.
 Документирование инфопотоков между системами
 Маппирование инфопоток на API и методы, предоставляемые со стороны
вызываемых систем
 Анализ избыточности API: если одно и тоже запрашивается разными способами,
то есть смысл свернуть это в один вызываемый метод или функцию. Это упрощает
поддержку приложения и всех выставленных им наружу методов.
 Принятие решения на предмет устранения прямых вызовов каждого
анализируемого приложения: прямые вызовы заменяются на вызовы данного
приложения через шину ESB. Замена прямых интеграций на «шинные» является
затратных мероприятием. Такая замена обоснованно целесообразна для
следующих случаев:
- Планируется удаление анализируемой системы из ландшафта
- Планируется рост количества новых интеграций с анализируемой системой