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

Единая шина предприятия или "лоскутное одеяло” для гетерогенной сети оператора связи: необходимость выбора

Ключевые слова: сервисная шина предприятия ESB, системы поддержки операций OSS, системы поддержки бизнеса BSS, "лоскутное одеяло", оператор связи, интеграция систем, гетерогенная сеть, информационные системы.

Проведен анализ подходов для интеграции систем класса поддержки операций (ОББ)/под-держки бизнеса (ВББ), основанных на архитектуре сервисной шины предприятия ЕБВ или имеющих структуру "лоскутного одеяла". Представлены краткие характеристики данных решений построения систем (с иллюстрацией), указаны преимущества и недостатки, характерные для выбранной архитектуры решения; приведены схемные иллюстрации с пояснениями. Проведено сопоставление указанных способов, обозначены входные условия использования, а также противопоказания. Сравнение решений приводится посредством качественного сопоставления введенных ключевых показателей. Приведены примеры, подтверждающие факт отсутствия общего подхода для интеграции ИС предприятия. Обозначены основные направления стандартизации систем класса ОББ/ВББ; перечислены основные международные стандартизующие организации. Составлен набор тезисов для использования указанных архитектурных подходов интеграции систем ОББ/ВББ. Приведен условный порядок интеграции систем согласно обозначенным архитектурным подходам. Рассмотрены существующие программно-аппаратные реализации российских разработчиков программного обеспечения для предприятий и операторов связи, имеющих гетерогенную и кросстехнологичную инфрастрактуру, сделаны выводы об их применимости, соответствии международным рекомендациям и зарубежным решениям. Составлен краткий список тезисов по проведенной работе, сделаны выводы.

Аржанцев С.В.,

аспирант ФГОБУ ВПО МТУСИ, s.v.arzhantsev@gmail.com

Во второй половине XX в. началось активное развитие автоматизированных систем управления (АСУ), призванных автоматизировать некоторые технологические процессы, повторяющихся из раза в раз с целью повышения эффективности использования человеческого ресурса. Частичная автоматизация технологического процесса привела к логичному развитию АСУ — преобразование в более специализированные системы: управления предприятием (АСУП), технологическими процессами (АСУТП) и другие.[7] После появления и повсеместного распространения персональных компьютеров (следовательно, усложнения систем в сторону информатизации) можно говорить о выделении из АСУ такого рода систем, как информационные системы (ИС), которые имеют и на входе, и на выходе результат не только в виде завершённого технологического этапа, но и в виде информации для последующего переиспользования. [5],[6] Условная шкала развития АСУ представлена на рис. 1.

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

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

Порядка десяти лет назад был анонсирован концепт сервисной шины предприятия (ESB), который должен был прийти на смену существующему "лоскутному одеялу" межсистемных интерфейсов ИС.[4] В частности, это требовалось интеграции набирающих популярность систем класса поддержки операций (OSS) и поддержки бизнеса (BSS). В связи с наличием концепт архитектуры с брокером

Рис. 1 . Условная временная шкала развития АСУ

РЦс. 2. Возможные топологии взаимодействия ИС

был обобщён на территориально и функционально распределённое предприятие, получив название "(унифицированной) сервисной шины предприятия (U)ESB)". Теперь не требовалось делать межсис-темный интерфейс "каждый с каждым", а только 2 интерфейса: от ESB в сторону ИС и обратно [2], при этом, в отличие от концепта с использованием брокера у нас отсутствовала единая точка отказа. Схематическое описание трёх, описанных выше, топологий представлено на рис. 2.

Концепт UESB является основой сервисно-ориентированной архитектуры построения (SOA) ИС [1]. Его внедрение позволяет упростить структуру и управление ей, улучшить масштабируемость, оптимизировать вопросы гибкости, использования политик безопасности и вопросы QoS сервисов предприятия, в т.ч. благодаря прозрачности полученного решения [3]. Введём субъективные (не основанные на количественных характеристиках) ключевые параметры эффективности (KPI) для сравнения трех представленных решений и оценим показатели (1-min, З-max), сведённые в табл. 1.

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

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

сколько показательных антипримеров, в которых покажем, что это утверждение далеко не всегда справедливо:

1. Слишком мало ИС на предприятии: компания, которая занимается региональными продажами зарубежного оборудования: маленький штат (10 человек), 3 ИС: billing, CRM, inventory — проще сделать 6 соединений точка-точка, нежели покупать дорогостоящую инфраструктуру.

2. Использование нестандартизованных интерфейсов: на текущий момент ИС регионального оператора связи являются наследием, оставшимся после поглощения 2-3 компаний, в которых разработки ИС велись собственными силами — не могут взаимодействовать друг с другом без "тонкой настройки".

3. Некорректные бизнес — процессы в компании: многие считают, что при внедрении дорогой и известной системы ESB бизнес в компании пойдет "как надо": уменьшаться издержки из-за проволочек, тупиковых ситуаций и т.п. На деле эти потоки будут "загнаны" в ESB, что введёт к еще большему снижению эффективности.

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

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

Таблица 1

Субъективная оценка ключевых показателей эффективности

Критерий «Точка-точка» Broker (U)ESB

Простота развёртывания 3 2 1

Масштабируемость 1 3 3

Сложность текущего управления 3 2 2

Простота интеграции новых ИС 3+ 2 1

Проблема безопасности 3 2 1

Таблица 2

Соответствие российских компаний актуальным практикам OSS/BSS

Критерий НТЦ «Аргус» Orange System («roup System Development Lab

Работает на популярных програм м но-ап паратн ых платформах + + +

Модульное решение + + +

Рекомендация к наличию ESB +/- -

Использует открытые стандарты для интерфейсов + +

Успешный опыт внедрения продукта в РФ + + +

1. Сектор по стандартизации в области электросвязи (ITU-T). Особое внимание среди обилия рекомендаций следует обратить на серию М, а также на группу стандартов М.Зххх, где описывается модель управления сетью (TMN) основные функции и логика бизнес-процессов [8].

2. TM Forum. Данный отраслевой консорциум разработал ряд инициатив на основе совокупных "лучших практик" операторов связи и разработчиков программноаппаратных решений. В частности, следует отметить концепт Frameworx, в котором описывается эталонная модель бизнес-процессов предприятия (eTOM) и логика их развертывания посредством ИС предприятия (SID) [9].

3. Консорциум OASIS — Organization for the Advancement of Structured Information Standards. Занимается вопросами адаптации открытых стандартов для нужд информационного общества, в частности SOA, основным транспортным элементом которой является UESB [10].

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

Программное обеспечение (ПО) на сегодняшний день по вопросу распространения можно условно разделить на два типа: частное (с закрытым программным кодом, распространяемое строго по договорным условиям) и открытое, когда часть программного кода/весь код/продукт могут использоваться без заключения двусторонних договорных отношений между разработчиком/дистрибьютором продукта и пользователем/"покупателем"). На международном рынке решений OSS/BSS известны большие игроки (они же разработчики аппаратной базы): IBM, HP, Naumen Telecom и другие частные компании. Их решения соответствуют целому ряду показателей и основываются на запросах конечных потребителей. Основными отличительными техническими характеристиками являются кросплатформенность (поддерживается на большинстве современных популярных программно-аппаратных платформах), модульность (решение состоит из элементов, каждый из которых несет свой функционал), использование открытых межсистемных интерфейсов для взаимодействия и упрощения интеграции. К нетехническим характеристикам требуется отнести высокую стоимость таких решений, что значительно снижает их популярность. В последнее время все большим успехом пользуется открытое )или условно открытое) ПО — получая частично готовый продукт, некую заготовку для своего решения, оператор связи может "заточить" решение под свои требования. Примерами разработок такого ПО могут быть продукты компаний RiverMuse и Transverse.

При анализе российского сегмента данного рынка не было выявлено широко используемого открытого ПО класса OSS/BSS. Однако следует отметить факт того, что существует целый ряд успешно зарекомендовавших себя компаний, таких как петербуржские компании НТЦ "Аргус", Orange System Group, а также московская компания System Development Lab. Сегодня бытует расхожее мнение о том, что российские ИТ-продукты не могут конкурировать по качест-

ву с зарубежными аналогами даже в своих нишах. Для наглядности сведем обозначенные технические характеристики в сводную таблицу показателей и проверим их на соответствие, исходя их документации на продукцию у отечественных предприятий [11, 12, 13].

Как видно из таблицы, продукты всех трех компаний соответствуют существующим практикам. Отдельно следует отметить требование к ESB для решений — не везде такая необходимость является обязательным условием развертывания.

При развертывании любого решения, в частности новой системы класса OSS/BSS требуется провести ряд итераций с целью достижения поставленной задачи. Далее представлен краткий список шагов по развертыванию новой ИС с пояснениями:

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

2. Анализ инфраструктуры заказчика. Основным элементом данного этапа является, по сути, инвентаризация сети на уровне аппаратной части и интерфейсов ИС.

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

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

5. Разработка и выдача документации на реализацию. Составление ряда технических и организационно-административных документов — рабочих и отчетных.

6. Развертывание решения. Монтаж аппаратной части, интеграция с существующими системами.

7. Тестирование, пуско-наладочные работы. Проверка работоспособности новой системы по заранее составленному плану, с указанием критериев успеха и ряда мероприятий по "откату" в случае неудачи.

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

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

Из данной обзорной работы можно сделать ряд выводов. Во-первых, следует отметить 2 основных — довольно широко используемых сегодня — подхода к построению информационной инфраструктуры оператора связи: "лоскутное одеяло" (множественное соединение "точка-точка" и концепт с использованием унифицированной сервисной шины предприятия. При этом следует заметить, что не следует использовать UESB в качестве общего подхода к построению взаимодействия ИС, чему приведены наглядные примеры. Во-вторых, на сегодняшний день в качестве руководящей документации для организации взаимодействия систем класса OSS/BSS наиболее приемлемо использовать рекомендации ITU-T (особенно серию М), TM Forum и OASIS. При этом для эффективного использования инфраструктуры следует делать выборку для реализации конкретной задачи, а не пытаться создать унифицированное решение. В результате общего анализа рынка отечественных разработчиков решений OSS/BSS можно в явном виде выделить третий подытог: в России есть ряд компаний, активно работающих в данном направлении и выпускающие продукты, которые вполне компетентны на мировом рынке по качественным характеристикам (в условиях определенной ниши). В качестве последнего вывода стоит отметить схожесть биз-

нес — процесса внедрения новых ИС на предприятии с развертыванием любого решения в сфере ИКТ.

Литература

1. Patterns: Implementing an SOA Using an Enterprise Service Bus / IBM Redbooks, First Edition изд. IBM.Com/Redbooks, 2004. — 386 с.

2. Sanjay P Ahuja, Amit Patel. Enterprise Service Bus: A Performance Evaluation // Communications and Network. School of Computing, University of North Florida, Jacksonville, USA: 2011, 3. С. 133-140.

3. Eduardo B. Fernandez, Nobukazu Yoshioka and Hironori Washizaki. Two patterns for distributed systems: Enterprise Service Bus (ESB) and Distributed Publish/Subscribe Portland, OR, USA Pattern Languages of Programs Conference 2011 October 21-23, 2011. 15 c.

4. David A. Chappell Enterprise Service Bus. Sebastopol, Calif., USA: O'Reilly Media, Inc., 2004. 247 с.

5. Стандарт ISO/IEC 2382-1.

6. ГОСТ РВ 51987.

7. ГОСТ 34.003-90.

8. http://www.itu.int/rec/T-REC-M/en(дата обращения 17.11.12).

9. http://www.tmforum.org/TMForumFrameworx/191 1/home.html (дата обращения 17.11.12).

10. https://www.oasis-open.org/standards (дата обращения 17.11.12).

11. http://www.argustelecom.ru/ (дата обращения 24.11.12).

12. http://www.orangesystem.ru/ (дата обращения 24.11.12).

13. http://www.sdl.ru/(дата обращения 24.11.12).

Enterprise Service Bus or "patchwork" approach for heterogeneous telecoms operator network:

the need of choice

Sergey Arzhantsev, MTUCI, postgraduate student, s.v.arzhantsev@gmail.com

Abstract

The paper analyzes OSS/BSS integration approaches based on ESB or "patchwork" architecture. Brief characteristics for these systems formation solutions are introduced. They note advantages and disadvantages regular for the architectural concepts and illustrated explained schemes. There is a comparison of the two methods and a list of input conditions and stop-factors of use. The comparison is made by the qualitative introduced key indicators match. The paper contains examples acknowledging the absence of general approach for enterprise information systems integration. There is a list of main standardization directions of OSS/BSS class systems and international standardization organizations. The composed thesis set is done to use for the mentioned OSS/BSS integration architecture approach. There is a production of the integration reference order according to the two architectural approach noted previously. They consider existing firmwares of Russian enterprise and telecoms operator software developers for heterogeneous and intertechnological infrastructure. Their applicability and correspondence are resumed with international recommendations and foreign solutions. The executed work thesis summary is performed.

Keywords. "patchwork" approach, enterprise service bus ESB, operational support system OSS, business support system BSS, telecoms operator, heterogeneous network, systems integration, information systems.