Развитие проекта в области интеграций v8 ОК

АРХИТЕКТУРА ПРЕДПРИЯТИЯ: ИНТЕГРАЦИИ ПРИЛОЖЕНИЙ КОМПАНИИ

MARCUS AURELIUS LTD

Г. МОСКВА2015 ГОД, ДЕКАБРЬ

Pont du Gard — самый высокий сохранившийся древнеримский акведук

СТРАНИЦА 2

ТЕМА 1. ПРОБЛЕМА УНИФИКАЦИИ ИНФОРМАЦИОННЫХ МОДЕЛЕЙ

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

MARCUS AURELIUS LTD

MARCUS AURELIUSБ И З Н Е С К А К Ф И Л О С О Ф И Я

СТРАНИЦА 3

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

КЛЮЧЕВЫЕ СЛОВА

СТРАНИЦА 4

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

С этой целью развиваются и трансформируются такие интеграционные технологии (технологии промежуточного слоя), как CORBA, Java RMI, .NET, Web Services, Semantic Web, Grid и другие. В рамках внедрений на базе этих технологий накоплено большое количество программных и информационных технически интероперабельных компонентов.

Технологии промежуточного (интеграционно-композитного) слоя (связующее ПО): обеспечивают техническую возможность интеграции источников и конструирования распределенных,

интероперабельных ИС из компонентов; позволяют накапливать репозитории компонентов для их дальнейшего использования при создании

новых ИС.

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

ИНТЕГРАЦИЯ И КОМПОЗИЦИЯ НЕОДНОРОДНЫХ ИС

СТРАНИЦА 5

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

разрабатываемого применения.

СЕМАНТИЧЕСКАЯ ИНТЕРОПЕРАБЕЛЬНОСТЬ

Интероперабельность обеспечивает предметный посредник.

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

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

СТРАНИЦА 6

«ВАВИЛОНСКАЯ БАШНЯ» ИНФОРМАЦИОННЫХ МОДЕЛЕЙ

НЕОБХОДИМА КОРРЕЛЯЦИЯ ИНФОРМАЦИОННЫХ МОДЕЛЕЙ РАЗНОРОДНЫХ ИНФОРМАЦИОННЫХ РЕСУРСОВ

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

Marcus Aurelius ltd.

Информационная модель (или модель представления информации) состоит из языков для описания:

структуры информации; семантики информации; операций, определяющих характерные преобразования

информации в заданной модели.

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

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

СТРАНИЦА 7

КАНОНИЧЕСКАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ИНФОРМАЦИИ

СОЗДАНИЕ ИНТЕРОПЕРАБЕЛЬНЫХ И КОМПОЗИТНЫХ РЕШЕНИЙ ВОЗМОЖНО ТОЛЬКО ПРИ ИСПОЛЬЗОВАНИИ КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ

Варианты совместного использования информационных ресурсов: Интероперабельность и композитное поведение – совместная работа ресурсов при решении

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

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

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


СТРАНИЦА 8

ТЕМА 2. ЗАДАЧА ПОСТРОЕНИЯ КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ РАСПРЕДЕЛЕННОЙ КОМПАНИИ

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

MARCUS AURELIUS LTD

СТРАНИЦА 9

ЗАЧЕМ? – ПРЕДПОСЫЛКИ ЗАДАЧИ


НЕОБХОДИМО: ПОСТРОИТЬ УНИФИЦИРОВАННУЮ МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ ИНФОРМАЦИОННЫХ СИСТЕМ ДЛЯ ЦЕЛЕЙ СНИЖЕНИЯ СЛОЖНОСТИ УПРАВЛЕНИЯ СТОЛЬ БОЛЬШИМ ИНТЕГРАЦИОННЫМ ПОЛЕМ

В рамках проекта по инвентаризации информационных систем компании Ростелеком (на январь 2016 года) выявлено и занесено в QPR (программный инструмент класса Enterprise Architect) в виде паспортов более 9000 (!) инфопотоков.

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

При анализе этих инфопоток, спроектированных и запрограммированных в разное время разными коллективами разработчиков, выявляются конфликты данных, передаваемых в инфопотоках:

конфликты именования (в различных ИС используется различная терминология, что приводит к омонимии и синонимии в именовании)

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

структурами данных).Как следствие имеем аналогичные конфликты самих инфопотоков.

Полный перечень функций и инфопотоков, полученный из материалов, представленных ИТ-службами МРФов и КЦ Ростелекома, отражает то, что хотели построить разные люди, в разное время на удаленных друг от друга территориях.

СТРАНИЦА 10

СЛУЖБЫ/СЕРВИСЫ


ОБНАРУЖЕНИЕ СЛУЖБЫ И СОГЛАСОВАНИЕ КОНТРАКТА С НЕЙ – ВАЖНЕЙШИЕ СОСТАВЛЯЮЩИЕ SOA-АРХИТЕКТУРЫ

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

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

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

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

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

Обращение к сервисам и переход к SOA будет полезен прежде всего при внедрении новых систем, а так же при выводе систем из эксплуатации

СТРАНИЦА 11

АРХИТЕКТУРА СЕРВИСА

СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ В ОДИН УНИФИЦИРОВАННЫЙ И ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ


СЕРВИС – ЛОГИЧЕСКАЯ ЕДИНИЦА ПРОЕКТИРОВАНИЯ. СОВОКУПНОСТЬ СЕРВИСОВ ОБРАЗУЕТ ПРИЛОЖЕНИЕ. ОДИН СЕРВИС МОЖЕТ БЫТЬ ОДНИМ ПРИЛОЖЕНИЕМ ИЛИ ЕГО МОДУЛЕМ.

СТРАНИЦА 12

СЕРВИС. ФУНКЦИИ –МЕТОДЫ-ОБЪЕКТЫ


МЕТОД – частный случай функции. Мы используем понятие «метод» вместо «функция», когда можно четко выделить Объект, к методу которого мы хотим обратиться.

Объект

Метод 3

Функция 1

Функция 2

Функция 3

API-1.1

API-1.2

API-1.3

Метод 1

ОбъектОбъект

Объект

Метод 2

API – описывает контекст (как информационный, а часто и событийный) и правила применения функций/методов.

API

СТРАНИЦА 13

СПЕЦИ

ФИ

КАЦИ

Я (КОНТРАКТ)

СЕРВИСА

ТЕЛО СЕРВИ

СА

СЕРВИС. ФУНКЦИИ –МЕТОДЫ-ОБЪЕКТЫ


СЕРВИС – это функции или методы, выставленные приложением наружу в единой манере (согласно унифицированному контракту) для обращения к ним со стороны приложений-потребителей. Как правило, это Web-сервисы, описанные в стилях REST, SOAP, HTTP и т.п.Сервис применяется к объекту данных или его атрибутам.

Объект

Метод 3

Функция 1

Функция 2

Функция 3

Метод 1

ОбъектОбъект

Объект

Метод 2

СТРАНИЦА 14

СЕРВИС ПРИЛОЖЕНИЯ В ARCHIMATE® 2.1 SPECIFICATION


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

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

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

Сервис приложения должен быть значащим с точки зрения окружения приложения; он должен представлять единицу функциональности, которая по своей природе полезна для ее потребителей. Например, если окружение состоит из бизнес-процессов, сервисы приложения должны быть актуальны для этих бизнес-процессов, то есть реализовывать те или иные транзакции бизнес-процесса. Сервис приложения может иметь доступ к данным и предоставлять/принимать данные.

Имя сервиса приложения желательно должно быть отглагольным существительным. Так же может использоваться имя, которое явно содержит слово «Сервис».

СТРАНИЦА 15

Внутренний мир приложений

Marcus Aurelius ltd. +7 985 922 12 40 Рудь Виктор

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

Наружу, во внешний мир, система выставлена в виде совокупности предоставляемых сервисов.

Таким образом, функции – это взгляд на систему изнутри. Сервисы – взгляд на систему снаружи.

Ясно, что госсервисы (госуслуги) отличаются от функций государства. Здесь (в информационных системах) такая же аналогия.

ДВА ВЗГЛЯДА НА ПРИЛОЖЕНИЕ: ИЗНУТРИ И СНАРУЖИ

Система А Система В

Система Е Система DСервис Е2

функция

функция

функция

функция

функция

функция

функция

функция

функция

функция

функция

функция

Сервис Е1

Сервис В2

Сервис В1Сервис А2

Сервис А1

Сервис D2

Сервис D1

Сервисы – это то, как приложения представлены друг другу для взаимодействия

Так систему B видят приложения А,E,D

СТРАНИЦА 16

Реестр сервисов

АРХИТЕКТУРА, ОРИЕНТИРОВАННАЯ НА СЛУЖБЫ


Приложение-посредник (среда передачи сообщений = среда взаимодействия)

Сервис Х

функ

ции

мет

оды

мет

оды

Сервис Х+1

функ

ции

мет

оды

мет

оды

Приложение

функ

ции

мет

оды

мет

оды

Сервис ХСервис Х+1Сервис Х+2

…Сервис N

функ

ции

Запрос функции или данных

Адаптер Х Адаптер Х+1 Адаптер

СТРАНИЦА 17

СЕРВИС ПРИЛОЖЕНИЯ: МЕСТО В АРХИТЕКТУРЕ


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

бизнес-процессами; бизнес- функциями; бизнес-взаимодействиями; функциями приложений;

Сервис : Проверка ТВ

Бизнес-процессПродажа

Бизнес-взаимодействие:

Онлайн проверка ТВ

Система А

Система В

Бизнес-процессИзыскание ТВ

Бизнес-сервис : Проверка ТВ

Инфопоток : Онлайн проверка ТВ

Бизнес-сервис : Оформление заказа

Сервис : Запрос проверки ТВ

СТРАНИЦА 18

SOA-АРХИТЕКТУРА


РАЗРАБОТКУ НОВОГО ПРИЛОЖЕНИЯ В РАМКАХ СУЩЕСТВУЮЩЕЙ SOA-АРХИТЕКТУРЫ МОЖНО СРАВНИТЬ С СОЗДАНИЕМ РАСПРЕДЕЛЕННОГО ПРИЛОЖЕНИЯ

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

-

--

-

-

--

-

СТРАНИЦА 19

РАСПРЕДЕЛЕННЫЙ БИЗНЕС-ПРОЦЕСС


SOA-АРХИТЕКТУРА И РАСПРЕДЕЛЕННЫЙ БИЗНЕС-ПРОЦЕСС ИМЕЮТ МНОГО ОБЩЕГО, ПОСКОЛЬКУ ВСЕ ТРЕБУЕМЫЕ БИЗНЕС-ФУНКЦИИ МОЖНО ПРЕДСТАВИТЬ В ВИДЕ WEB-СЛУЖБ, ЧТО СООТВЕТСТВУЕТ КОНЦЕПЦИИ SOE – СЕРВИС-

ОРИЕНТИРОВАННОГО ПРЕДПРИЯТИЯ. ТАКИМ ОБРАЗОМ БИЗНЕС-ПРОЦЕСС МОЖНО РЕАЛИЗОВАТЬ ВНУТРИ ОБРАЩАЮЩЕГОСЯ К WEB-СЛУЖБАМ ПРИЛОЖЕНИЯ

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

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

2. Бизнес-процесс компании – это, как правило, целая цепочка взаимосвязанных бизнес-транзакций, исполняемых при поддержке различных систем компании. Вся эта цепочка должна контролироваться от начала и до конца с использованием ПО. Для координации выполнения цепочки бизнес-транзакций используется компонент управления распределенным бизнес-процессом.

- - -

СТРАНИЦА 20

API - СПЕЦИФИКАЦИЯ


Спецификация API позволяет описать правила доступа к какому-либо объекту или набору связанных общим бизнес-смыслом объектов.

Спецификация API включает в себя:

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

операции (методы), применимые к этим данным; нотификации, информирующие о событиях, связанных с изменениями объекта данных; множество базовых статусов объекта с описанием правил изменений этих статусов

ТАКИМ ОБРАЗОМ, API ПОЗВОЛЯЕТ ПОЛНОСТЬЮ ОПИСАТЬ СЕМАНТИКУ ПРАВИЛ РАБОТЫ С ДАННЫМИ ИЗ ОПРЕДЕЛЕННОЙ ОБЛАСТИ

СТРАНИЦА 21

МЕТАМОДЕЛЬ ДЛЯ МОДЕЛИРОВАНИЯ ВЗАИМОДЕЙСТВИЙ


НА КАКИЕ ВОПРОСЫ И КАКИМ ОБРАЗОМ ПОЗВОЛЯЕТ ОТВЕТИТЬ СОБРАННАЯ В РАМКАХ МЕТАМОДЕЛИ ИНФОРМАЦИЯ?

Структура модели: системы, функции, интерфейсы, интеграции, данные

Application YApplication X

Application Function

Application Interface


Application Interaction

(ИНФОПОТОК)

Application Collaboration


Data Object

Application YApplication X




Application Interaction

(ИНФОПОТОК)

Application Collaboration


Data Object

СТРАНИЦА 22Marcus Aurelius ltd.

Каноническая модель позволит: При работе с большим количеством приложений минимизировать количество трансляторов

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

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

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

терминах сферы деятельности компании (а не конкретной реализации ИС); Полезно было бы построить каноническую модель данных на промежуточном слое (интеграционной

шине) и обращаться к этим данным с помощью канонических сервисов

Каноническая модель

Инфопоток 1

КАНОНИЧЕСКАЯ МОДЕЛЬ

Система - потребитель сервиса

Система – поставщик сервиса

Сервис 1

Инфопоток 2Сервис 2


API1

API2


Канонические сервисы позволят: Выделить классы подобных с точки зрения

бизнеса функций, выставленных ИС наружу, и объявить их как сервисы;

Унифицировать правила именования функций, представленных в качестве сервисов;

Определить перечень сервисов, предоставляемых каждой ИС для применения оптимального подхода к построению взаимодействий этой ИС с ее окружением;

Определить мастер-систему по каждому классу данных, выделенных в канонической модели;

Упростить и унифицировать приземление целевых бизнес-процессов компании на ИТ-ландшафт.

Канонические сервисы

КАНОНИЧЕСКИЕ СЕРВИСЫ


Система ЕСистема D

Серв

ис 1

Сервис 2

Система С

СТРАНИЦА 24

ТЕМА 3. ПОДХОД К ПОСТРОЕНИЮ КАНОНИЧЕСКОЙ ИНФОРМАЦИОННОЙ МОДЕЛИ РАСПРЕДЕЛЕННОЙ КОМПАНИИ

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

MARCUS AURELIUS LTD

СТРАНИЦА 25

Задача

ИД задачиИД типа задачиИД этапа обработкиИД статуса задачиИД сотрудникаИД обращенияИД заказа

Вспомогательная задача

ИД вспомогательной задачиИД задачиИД типа задачиИД этапа обработкиИД статуса задачиИД заказа

Заказ

ИД заказаНомер заказаСтатусДата создания заказаИД клиентского профиляИД статуса заказаИД договораИД лицевого счетаИД адреса (установки)ИД типа заказа

Начисления

ИД начисленияДата выставленияСуммаТип начисленияИД лицевого счетаБиллинговый цикл

Платежи

ИД платежаДата выставленияСуммаТип платежаИД лицевого счета

Счета

ИД счетаПериодНомер счетаИД лицевого счетаБиллинговый цикл

Начисления Платежи

Счета

Заказ. Типы заказа

ИД типа заказаНазвание типа заказа

Корректировка начислений

ИД корректировки начисленияНазвание корректировкиТип корректировкиИД начисленияПричина корректировки

Корректировка платежей

ИД корерктировки платежаНазвание корректировкиТип корректировкиИД платежаПричина корректировки

МЕТОДОЛОГИЯ ПОСТРОЕНИЯ КАНОНИЧЕСКОЙ МОДЕЛИ ДАННЫХ

• Выделение типов объектов данных, которые участвуют в интеграционных взаимодействиях, унификация их именования и описания;

• Классификация полученных типов объектов данных в соответствии с доменами телекома

• Группировка типов объектов данных в каждом домене для формирования базовых бизнес-объектов;

• Анализ модели данных ЕКХД;• Анализ типов объектов данных,

передаваемых в инфопотоках;


Данные классифицируются с применением следующего подхода: При моделировании данных различаются 3 уровня:

Бизнес-уровень – понятия, которыми оперирует бизнес (тезаурус);Логический уровень – представление понятий, которыми оперирует бизнес, в виде объектов и взаимосвязей между этими объектами;Физический уровень представляет объекты логического уровня в виде, обеспечивающем корректную реализацию на уровне СУБД ( напр., в виде таблиц реляционной БД, классов в объектно-ориентированной БД и т.п.)

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

Логический уровень сглаживает различия между бизнес-уровнем и физическим уровнем и служит базой для ведения диалога между представителями бизнеса и разработчиками ПО;

Каноническая модель -это модель логического уровня; На начальном этапе анализа предметной области мы не пытаемся опуститься на уровень

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

МЕТОДОЛОГИЯ КЛАССИФИКАЦИИ ДАННЫХ

Этот уровень мы не

рассматриваем

КЛАССИФИКАЦИЯ ДАННЫХ ПОМОЖЕТ ПОСТРОИТЬ КАНОНИЧЕСКУЮ МОДЕЛЬ И ВЫПОЛНИТЬ КЛАССИФИКАЦИЮ МЕЖСИСТЕМНЫХ ВЗАИМОДЕЙСТВИЙ.


МЕТОДОЛОГИЯ МНОГОУРОВНЕВОГО ПРЕДСТАВЛЕНИЯ ДАННЫХ

Физ.Лицо домохозяйство Фабрика

ДОМЕН: КЛИЕНТ

Клиент-ФЛ

Информационная модель (логическая)

ФИОВозрастПаспорт

Клиент-ЮЛ

НазваниеФорма собственностиРасчетный счет

Банк

Домохозяйство

АдресТипЛПР Таблицы БД

(Физическая модель)

ПерсонаФамилияИмяОтчествоВозраст

ДокументТип (ex, Паспорт)НомерДата выдачиОрган выдачиСрок действия

Адрес

ГородИндексУлицаДомСтроение

ОрганизацияНазваниеФорма собственностиБанковские реквизиты

Реквизиты счета

Название банкаБИКРасчетный счетВалюта счет

СТРАНИЦА 28

ВАРИАНТ№1: МЕТОДОЛОГИЯ ВЫЯВЛЕНИЯ ГРУПП РОДСТВЕННЫХ ВЗАИМОДЕЙСТВИЙ: КЛАССИФИКАЦИЯ ИНФОПОТОКОВ

MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор

Взаимодействия вотношении

подключения/возможности

подключения сервиса

Взаимодействия вотношении оплаты ивыставления счетов

Взаимодействия вотношении состояния

ресурсов


справочной иконфигурационной

информации


маркетинга/ продажВзаимодействия в

отношении ТТ


использованияресурсов


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

Взаимодействия вотношении Заказов

Взаимодействия вотношении объектов

сети


клиентскогооборудования

Взаимодействия вотношении массовых

ТТ


информации поклиенту


использованиясервисов

Взаимодействия в отношении обращений клиента/ к клиенту


сервисов


подключенияресурсов


конфигурированиясервиса

Взаимодействия в отношении клиентов

Взаимодействия в отношении услуг

Взаимодействия вцикле расчетов

Взаимодействия в отношении ресурсов


резервированияресурсов

Взаимодействия вцикле управления

Заказом

Взаимодействие в цикле предоставления услугиВзаимодействия приподдержке

операционнойдеятельности

Взаимодействие в отношении предприятия

Взаимодействия сцелью проверки

выполнения условийбезопасности

Взаимодействие врамках управления

предприятием

Взаимодействия дляпечати документов

Взаимодействиев отношении

заявок/нарядов

Взаимодействия вотношении Заказов,выполненных через

дилера

Взаимодействия в отношении поставщиков и партнеров

МЕЖСИСТЕМНЫЕ ВЗАИМОДЕЙСТВИЯ КЛАССИФИЦИРУЮТСЯ ПО ПРИЗНАКУ ПЕРЕДАВАЕМОЙ ИНФОРМАЦИИ

Ольга Ковальчук

Этот и 2 следующих слайда показывают историю изменения подхода к выделению сервисов


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

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

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

Для определения уровня II и следующих уровней классификации инфопотоков используем различные критерии классификации:

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

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

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

МЕТОДОЛОГИЯ КЛАССИФИКАЦИИ ИНФОПОТОКОВ ДЛЯ РОСТЕЛЕКОМ

ПОСТРОЕНИЕ КАНОНИЧЕСКОЙ МОДЕЛИ ДАННЫХ ПОМОЖЕТ БОЛЕЕ ТОЧНО ВЫПОЛНИТЬ КЛАССИФИКАЦИЮ ИНФОПОТОКОВ И ИДЕНТИФИЦИРОВАТЬ СЕРВИСЫ.

СТРАНИЦА 30





ресурсов











сети




ТТ




сервисов








Заказом





дилера

ПЕРЕХОД ОТ КЛАССОВ ИНФОПОТОКОВ К СЕРВИСАМ

НА ОСНОВАНИИ РЯДА ФАКТОРОВ, ОТДАВАЯ ПРИОРИТЕТ ГРУППИРОВКЕ ИНФОПОТОКОВ, МЫ ВЫДЕЛЯЕМ БУДУЩИЕ СЕРВИСЫ ЕДИНОЙ ИТ-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

Сервис управления

заказами

Сервис управления клиентами

Сервис управления

услугами

Сервис управления ТТ

СТРАНИЦА 31

ВАРИАНТ№2: МЕТОДОЛОГИЯ ВЫЯВЛЕНИЯ МИКРОСЕРВИСОВ НА БАЗЕ МЕТОДОВ

Приостановление/восстановлениедоступа к услугам ШПД при наличии

дебиторской задолженности(СИБ.008_НФ.ОФ.503)

Блокировка абонентов в LDAP каталогена основе списков сформированных в

модуле по работе с дебиторами(СИБ.012.ВФ.011)

Изменение профиля в LDAP каталоге,отражающее изменение тарифного

плана (СИБ.012.ВФ.026)

Ядросистема.Работа сдебиторами (МРД)

(МРФ СИБ)

Отправка команды на блокировкуабонента в HP OV SA

Отправка команды на разблокировкуабонента в HP OV SA

Автоматическое применение спискадебиторов (СИБ.012.ОФ.010)

Формирование списков абонентов наотключение услуг

ШПД(СИБ.012.ВФ.008)

Формирование списков абонентов наподключение услуг ШПД

(СИБ.012.ВФ.007)

Управлениесервисом на базе

HP OV SA

Прием и выполнение команд науправление учетными записямипользователя в LDAP каталоге

(СИБ.012.ОФ.011)

Откат результата действий,выполненных по наряду на

предоставление доступа к услуге(СИБ.012.ВФ.027)

Включение сервиса в каталоге LDAP(СИБ.012.ВФ.024)

Создание профиля в LDAP каталоге вавтоматическом режиме

(СИБ.012.ВФ.005)

Разблокировка абонентов в LDAPкаталоге на основе списков

сформированных в модуле по работе сдебиторами(СИБ.012.ВФ.012)

Инициация разблокировки абонентов всистеме управления сервисами на базе

HP OV SA (СИБ.014.ВФ.042)

Инициация блокировки абонентов всистеме управления сервисами на базе

HP OV SA (СИБ.014.ВФ.043)

Определение результата выполненияоперации по наряду из СУУ в LDAP

каталоге (СИБ.012.ВФ.022)

• ОПИРАЯСЬ НА РЕЕСТР ИНОПОТОКОВ, МЫ ОПРЕДЕЛЯЕМ НАБОР ФУНКЦИЙ, КОТОРЫЕ ВЫЗЫВАЮТСЯ В РАМКАХ МЕЖСИСТЕМНЫХ ВЗАИМОДЕЙСТВИЙ.

• ЕСЛИ ЭТИ ФУНКЦИИ ПРИМЕНЯЮТСЯ К ОДНОМУ И ТОМУ ЖЕ ТИПУ ИНФОРМАЦИИ, ОНИ МОГУТ БЫТЬ ОБЪЕДИНЕНЫ ДЛЯ ПРЕДСТАВЛЕНИЯ ОКРУЖЕНИЮ ОДНОГО МЕТОДА.

• КАЖДЫЙ ИЗ ПОЛУЧЕННЫХ МЕТОДОВ МЫ ОПРЕДЕЛЯЕМ КАК МИКРОСЕРВИС (Т.Е. ТАКОЙ СЕРВИС, КОТОРЫЙ ПРЕДСТАВЛЯЕТ ОКРУЖЕНИЮ ОДИН УНИФИЦИРОВАННЫЙ МЕТОД).

МИКРОСЕРВИСЫ ОБЕСПЕЧАТ ПРОСТОТУ И ГИБКОСТЬ СОЗДАНИЯ ЛЮБОЙ КОНСТРУКЦИИ ИЗ

БОЛЕЕ МЕЛКИХ КОМПОНЕНТОВ.

СТРАНИЦА 32

ВАРИАНТЫ РАЗВИТИЯ ПАРАДИГМЫ КАНОНИЧЕСКИХ СЕРВИСОВ

MARCUS AURELIUS LTD.





ресурсов











сети




ТТ




сервисов








Заказом





дилера

СОЗДАНИЕ КОМПОЗИТНЫХ СЕРВИСОВ ОСТАЕТСЯ ЗА РАМКАМИ НАШЕГО РАССМОТРЕНИЯ!

API управления

заказами

API управления клиентами

API управления

услугами

API управления ТТ

• ИЗ ПОЛУЧИВШИХСЯ МИКРОСЕРВИСОВ ВСЕГДА МОЖНО БУДЕТ СОЗДАТЬ ЛЮБОЙ КОМПОЗИТНЫЙ СЕРВИС

• КОМПОЗИТНЫЕ СЕРВИСЫ МОЖНО БУДЕТ СФОРМИРОВАТЬ, НАПРИМЕР, ГРУППИРУЯ МИКРОСЕРВИСЫ ВОКРУГ ОБЪЕКТОВ ДАННЫХ КАНОНИЧЕСКОЙ МОДЕЛИ

• НА ЭТОЙ ЖЕ ОСНОВЕ МОЖНО ОПИСАТЬ БУДУЩИЕ API ЕДИНОЙ ИТ-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

СТРАНИЦА 33

РЕШЕНИЯ ДЛЯ ОПТИМАЛЬНОГО РАЗВИТИЯ ИТ-ЛАНДШАФТА КОМПАНИИ


Построить каноническую модель данных:Позволит описать все типы объектов данных, в отношении которых взаимодействуют информационные системы всей большой компании.Определить набор микросервисов: Микросервисы позволят определить полный набор методов, применимых к данным канонической модели.Определить набор унифицирующих композитных сервисов: Унифицирующие сервисы позволят абстрагироваться от деталей реализации семантически подобных микросервисов в различных информационных системах и предоставить окружению единый сервис, реализующий тот или иной метод, в каком бы конечном приложении он не исполнялся. Оркестровку по реализации таких сервисов, предоставляемых различными системами-провайдерами информации, можно возложить на интеграционного посредника.Область примененияВсе описанные действия не стоит применять тотально. Они нужны в случае множественного обращения различных ИС к определенным типам объектов данных, множественного обращения ИС к функциям, претендующим быть названными микросервисами.

Все перечисленные операции выполняются на логическом уровне

ТАКИМ ОБРАЗОМ, НА ЛОГИЧЕСКОМ УРОВНЕ МОДЕЛИРОВАНИЯ МЫ ДОСТИГАЕМ СЕМАНТИЧЕСКОЙ УНИФИКАЦИИ

СТРАНИЦА 34

В ЧЕМ ПОЛЬЗА СЕМАНТИЧЕСКОЙ УНИФИКАЦИИ?

Повышение эффективности работы При выведении ИС из эксплуатации мы всегда будем понимать, какие сервисы она

предоставляла окружению (объем доработок) и какие сервисы использовала (что можно отключить/ не поддерживать).

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

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

Устранить эффект «Вавилонской башни» в процессе коммуникаций с представителями бизнеса, работающими во всех ИС компании, да и внутри подразделений ИТ-блока.


ГИБКОСТЬ, СКОРОСТЬ, МИНИМИЗАЦИЯ ЗАТРАТ ПРИ РЕШЕНИИ КАК СТАНДАРТНЫХ, ТАК И СЛОЖНЫХ ЗАДАЧ!


КОНТАКТЫ ДЛЯ СВЯЗИ

Рудь, Ковальчук, КрасинскаяООО «МАРК АВРЕЛИЙ»

http://www.consulo.ruE-mail: v.rud @consulo.ruТелефон: +7 (495) 922-12-40

Не отказывайся от помощи, особенно когда это связано с исполнением долга.Многое из того, что не удаётся сделать в одиночку, может быть легко достигнуто, если действовать сообща…

Марк Аврелий


http://www.consulo.ru/

WWW.MARCUS-AURELIUS.RU

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


СТРАНИЦА 37

ПЕРЕХОД К СЕРВИСАМ

ФУНКЦИИ ПРИЛОЖЕНИЯ

ОБЕСПЕЧИВАЮЩЕЕ ПРИЛОЖЕНИЕ

СЕРВИС

ДОСТУПНОСТЬ СЕРВИСА для

ИСПОЛЬЗОВАНИЯ

СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ В ОДИН УНИФИЦИРОВАННЫЙ И ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ

С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ

ДАННЫЕ ПРИЛОЖЕНИЯ


СТРАНИЦА 38

ПОСЛЕДОВАТЕЛЬНОСТЬ ПЕРЕХОДА К СЕРВИСАМ


Документирование инфопотоков между системами Маппирование инфопоток на API и методы, предоставляемые со стороны

вызываемых систем Анализ избыточности API: если одно и тоже запрашивается разными способами, то

есть смысл свернуть это в один вызываемый метод или функцию. Это упрощает поддержку приложения и всех выставленных им наружу методов.

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

Documents

Развитие проекта в области интеграций v8 ОК