Пути ИТ-стандартизации – исповедимы. На примере логики развития OSS

TMN – техническая регламентация

Рынок средств OSS уже прошел значительный путь и претерпел некоторые трансформации. Поэтому его сегодняшнее состояние и тенденции будут лучше понятны, если заглянуть в недалекое прошлое. В ответ на появившиеся в конце прошлого столетия проблемы управления сетями ведущие международные организации в области стандартизации, такие как ISO (International Organization for Standardization), ITU (International Telecommunication Union), ETSI и др., разработали ряд стандартов для систем управления (СУ) сетями связи. В результате в рекомендациях ITU были изложены общие принципы планирования, функционирования и технического обслуживания системы управления электросвязью TMN (Telecommunications Management Network) с использованием стандартных протоколов и интерфейсов. Предложенная в рекомендациях пирамидальная модель СУ охватывала пять уровней (рассматривая сверху):
- управление бизнесом (Business Management, BM);
- управление сервисами (Service Management, SM);
- управление сетью (Network Management, NM);
- управление элементами (Element Management, EM);
- элементы сети (Network Element, NE).
В свою очередь для прикладных функций управления сетью в TMN
выделены пять функциональных областей (т. н. модель FCAPS):
- управление устранением отказов (Fault Management, FM);
- управление конфигурацией сети (Confi guration Management, CM);
- управление расчетами с пользователями и поставщиками услуг (Accounting Management, AM);
- контроль производительности сети (Performance Management, PM);
- обеспечение безопасности работы сети (Security Management, SM).
Оказалось, что представленная модель FCAPS и пирамида TMN взаимно дополняют друг друга. Такая модель в определенный период времени способствовала значительному развитию
OSS, которые соответствовали требованиям своего времени. При этом большое число OSS-систем были самописными или заказными, и каждая из них была настроена на «свои» архитектуру сети, используемое оборудование и предоставляемые услуги. Но со временем требования клиентов к услугам связи значительно возросли и оказалось, что системы OSS периода технологического роста слабо соответствуют новым бизнес условиям, а именно:
имеют, с одной стороны, дублирование, с другой – фрагментарное покрытие функций и, кроме того, их сложно и дорого модернизировать. Эти недостатки были следствием того, что основной целью концепции TMN было повышение эффективности работы сети, а не операторской компании как предприятия в целом [бизнес-цели пока не принимаются в расчет – Ред.].

TOM – типовая структура бизнес-процессов

Разрешению возникших сложностей в развитии телекоммуникационного бизнеса вообще и OSS-систем в частности поспособствовала начатая в 1995 году работа международной неправительственной организации TeleManagement Forum (TM Forum) по разработке способов управления телекоммуникациями по принципу от бизнес-задач предоставления услуг до управления оборудованием [теперь бизнес-требования выходят на первый план – Ред.]. Развивая идеи управления сетями, заложенные в документах ISO, ITU, и основываясь на обобщении опыта многих телекоммуникационныхкомпаний, TM Forum разработал для оператора связи типовую структуру бизнес-процессов по управлению предоставлением услуг – TOМ (Telecommunication Operations Map). Согласно TM Forum, для эффективного внедрения системы OSS необходимо прежде всего использовать соответствующую современным требованиям модель бизнес-процессов оператора связи, в создании которой операторам должна помочь
типовая структура бизнес-процессов TOM. Решения для OSS должны строиться в соответствии с общей структурой бизнес-процессов оператора. Модель бизнес-процессов позволяет правильно определить требования к OSS-системе, отвечающие за достижение бизнес-целей.
Поэтому структура процессов TOM стала для многих поставщиков OSS-решений, телекоммуникационных компаний и системных интеграторов отправной точкой при внедрении OSS-систем и позволила в большей мере согласовать технологический и бизнес-подход.

Термины и определения

Библиотека ITIL (Information Technology Infrastructure Library) – лучшая мировая практика, позволяющая организовать эффективное функционирование ИТ-служб организации для стабильного и прогнозируемого развития ее информационной системы.

eTOM – карта процессов инвариантная к технологиям

В дальнейшем TM Forum, анализируя фактическое развитие и тенденции телекоммуникационного рынка, постоянно совершенствует расширенную карту процессов телекоммуникационного оператора eTOM (enhanced Telecommunications Operations Map), которая пришла на смену TOM и разрабатывает рекомендации по ее практическому использованию. Структурная модель бизнес-процессов eTOM нацелена на создание общего представления о бизнес-процессах оказания услуг связи и ориентирована на полное удовлетворение запросов клиентов с высокой эффективностью для оператора. Основное отличие eTOM от TOM – это более полная и детальная структурная модель бизнес-процессов, имеющая четыре уровня детализации. Фактически в ней
описаны типовые бизнес-процессы оператора связи, декомпозированные до 4-го уровня, не требующие для их рассмотрения учета технологических особенностей оператора связи
[бизнес-модель инвариантна технологии ее реализации – Ред.]. Ответственности OSS-решений на структуре бизнес-процессов eTOM соответствуют бизнес-процессы в области «Операционные процессы» для горизонтальных уровней «Управление сервисами» и «Управление ресурсами». С 2004 года структура процессов eTOM как типовая структура бизнес-процессов оператора связи, получила статус официального стандарта ITU.

Национальные особенности процессного мышления

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



Рис. 1. OSS-системы: процессная логика стандартов и их взаимосвязь

Это период осторожного знакомства с eTOM и другими рекомендациями TM Forum. На наш взгляд, недостаточное внимание к процессному подходу не позволило операторам достичь ожидаемых результатов при внедрении OSS. Ведь, по мнению экспертов, именно бизнес-логика является при внедрении OSS той основой, которая позволяет правильно определить последовательность внедрения ключевых приложений и, как следствие, требуемый объем инвестиций и прогнозируемую отдачу от них.

Централизованные решения

В связи с тем, что в период экстенсивного развития сети операторов достигают масштабов всей страны и для предоставления услуг все больше используется сетевое оборудование и системы управления (NMS – Network Management System, EMS – Element Management System) различных производителей, возрастает роль централизованных OSS-решений, позволяющих создавать и использовать единые взаимодействующие между собой информационные
модели ресурсов сети (IMS-Inventory Management System), ее производительности (PMS-Performance Management System) и происходящих в ней событий (FMS-Fault Management System).
Такие OSS-системы становятся одним из важнейших элементов централизованных систем эксплуатации и позволяют операторам значительно повысить эффективность использования
ресурсов сети, отслеживать производительность сети, существенно упростить и сделать более эффективной обработку множества событий сети для сокращения времени на выявление аварийных ситуаций и их отработку. Эти системы требуют серьезных капиталовложений, к тому же при их создании все больше отдается предпочтение использованию готовых и проверенных решений вместо самописных и заказных.

Ориентация на клиента

Значительно исчерпав возможности экстенсивного развития, операторы связи для сохранения или завоевания рыночных позиций в конкурентной борьбе вынуждены выводить на рынок новые услуги в наиболее короткие сроки и уделять большое внимание качеству услуг в соответствии с все возрастающими запросами клиентов. Рынок телекоммуникаций становится все более клиент-ориентированным [OSS включается в борьбу за клиента – Ред.]. Для того чтобы соответствовать новым вызовам рынка, операторам потребовалось усовершенствовать свои подходы к управлению телекоммуникационными сетями, что, в свою очередь, привело к необходимости значительного расширения функциональной ответственности OSS-решений. Таким образом, к вышеупомянутым компонентам OSS (IMS, FMS, PMS) следует добавить следующие:
- TT (Trouble Ticketing) – контроль за устранением неисправности;
- WOM (Work Order Management) – управление выполнением работ на сети;
- SC (Service Catalog) – каталог услуг;
- AS (Activation System) – активация ресурсов и сервисов;
- SLM (Service Level Monitoring) – мониторинг уровня сервиса;
- SLA (Service Level Agreement) – управление уровнем обслуживания клиентов.
Потребность управления полным циклом предоставления услуги потребовала более тесной интеграции с системами бизнес-поддержки (BSS – Business Support System).

Услуги в виде ИТ-сервисов

Другой важной особенностью этого периода является то, что для предоставления услуг все больше используются ИT-сервисы, обуславливающие при внедрении OSS следующее:
- необходимость интеграции OSS с ИT-ресурсами, используемыми для предоставления услуг (централизованный мониторинг и инвентаризация ИT-ресурсов со стороны OSS, обмен данными с ИT-приложениями и др.);
- необходимость комбинированного использования подходов, определяемых различными стандартами (например, обеспечение взаимодействия eTOM-процессов и ITIL-процессов, т. е. бизнес-процессов, относящихся в службе эксплуатации сети и ИT-процессов). Эта особенность нашла свое отображение и в решениях TM Forum. В eTOM версии 8.0 предложена карта
процессов, включающая в себя и ITIL-процессы.

Новому поколению сетей - новые системы OSS

На подходе новое поколение сетей – NGN (New Generation Network), поддерживающее неограниченный набор услуг с гибкими возможностями по их управлению. Для этих сетей нужны новые системы OSS.

Термины и определения

Европейский институт по стандартам в области телекоммуникаций (ETSI) определил OSS (Operations Support Systems – система эксплуатационной поддержки) как базовое понятие для обозначения набора функций управления, которые применяются предприятием связи для мониторинга, анализа и управления системами, ресурсами и услугами.

Новому поколению сетей - новые системы OSS

Телекоммуникационное сообщество вступило в период очередных масштабных трансформаций, без которых теперь уже сложно ответить на вызовы рынка. Речь идет о технологиях сетей нового поколения (NGN – New Generation Network), которые призваны обеспечить широкий ассортимент и высокое качество предоставляемых услуг, и при этом сократить затраты оператора и повысить доходность предоставления услуг.

Главная цель - ориентация на клиента

Концепция NGN предусматривает поддержку неограниченного набора услуг с гибкими возможностями по их управлению, реализацию универсальной транспортной мультипротокольной сети с распределенной коммутацией, интеграцию с традиционными сетями связи. Базовым же принципом NGN является разделение функций переноса и коммутации, управления вызовом и управления услугами. Вместо принятого в традиционных сетях управления каналами для соединения между абонентами по принципу «точка-точка», в NGN реализуется переход к идеологии виртуальных частных сетей (VPN), осуществляющих доставку сервисов конечному пользователю поверх протокола IP. Технологии NGN предъявляют к OSS новые требования, которые изменяются вместе с развитием NGN и только сейчас начинают приобретать конкретные очертания. Главное отличие заключается в том, что OSS в сетях нового поколения отвечает не только за управление сетью, но и должна обеспечить качественное функционирование пользовательских услуг и технологических служб (сервисов). Т. е. акценты все больше смещаются в сторону обслуживания абонентов, а поэтому OSS должна уметь использовать информацию о пользователях, классифицировать ее, обогащать и интеллектуально обрабатывать. Поэтому решения, обеспечивающие заданный уровень услуги клиента (SLA -Service Level Agreement) и ее качество (QoS – Quality of Service), должны стать неотъемлемой частью OSS-систем. Все более востребованными становятся также решения для управления восприятием услуги пользователем (CEM-Customer Experience Management).

Проактивное управление

Сети следующего поколения и предоставляемые посредством их услуги на порядок сложнее и динамичнее, чем существующая сетевая среда, и реагировать на любые, в том числе
и возможные негативные изменения необходимо будет очень быстро, и поэтому в большинстве случаев придется использовать «проактивное (превентивное)» управление вместо «реактивного». Услуги в этих сетях непрерывно активизируются и дезактивируются. Это сопровождается активным добавлением, удалением и конфигурированием устройств, что приводит к значительному увеличению количества генерируемых при этом событий. Более того,
конвергентная природа NGN означает, что каждое событие может быть связано с затрагивающей какую-то услугу ошибкой, не воздействуя на нее самостоятельно. При этом оператор должен в режиме реального времени идентифицировать, какое событие, связаное с ошибкой в работе оборудования, влияет на предоставление услуг, например:
- события, свидетельствующие об отказе предоставления услуги;
- события, свидетельствующие о возможном отказе предоставления услуги в скором времени;
- события, свидетельствующие об отклонениях от ожидаемых конфигураций сети, которые могут воздействовать на SLA.

Уровень обработки входящих событий

NGN-сети более критичны к возможным простоям, поэтому недостаточно развитые технологии управления проблемами приведут к большим эксплуатационным затратам или даже к невозможности предоставления услуг. Из этого вытекает необходимость доработать или заменить соответствующие средства OSS на новые, чтобы они смогли обеспечить необходимый
уровень обработки входящих событий, а именно:
- автоматическое фильтрование, дедупликация и агрегация, чтобы показывать только связанные с первопричиной события; выявление критических событий;
- высокий уровень автоматизации изоляции проблемы путем применения сложного корреляционного анализа и эффективных правил поиска событий, связанных с первопричиной проблемы (Root Cause Analysis – RCA);
- обогащение событий, связанных с первопричиной проблемы, для автоматизированного / автоматического выявления их воздействия на пользователей и используемые ими услуги (Impact Analysis – IA);
- автоматизированная корреляция сетевых проблем и проблем пользователей;
- автоматический поиск на основе моделей первопричины проблемы (RCA) и выявление воздействия (IA), что будет очень актуально для сетей следующего поколения, так как методы на основе правил не всегда позволят эффективно решать указанные задачи в NGN-сетях.

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

Для быстрого устранения возникших проблем очень важна скорейшая мобилизация всех необходимых ресурсов и эфективное управление ими. Поэтому OSS должна иметь в своем составе средства для своевременного и гарантированного автоматического оповещения всех заинтересованных и привлекаемых к устранению возможной проблемы лиц при обнаружении критических событий еще до передачи события в систему контроля за устранением неисправности (Trouble Ticketing System). К томе же система контроля за устранением неисправности должна обладать для применения в NGN некоторыми отличиями, например, всей полной и детальной информацией о возникшей проблеме, а также содержать не только данные о статусе карточки контроля, но и данные о текущем состоянии решаемой проблемы в требуемой детализации.

Новый подход к планированию

Для предоставления услуг в гибко конфигурируемых сетях следующего поколения крайне важной является гарантия того, что необходимые для предоставления услуг ресурсы находятся в правильном месте и в нужное время. Кроме того, потребность отделения услуги от технологии вызывает необходимость понимания не только того, где, когда и какой ресурс необходим, но также и того, как развернуть его самым эффективным способом. NGN – это непрерывно изменяющаяся сеть, которая предназначена для предоставления многих различных видов услуг, с использованием разнообразных различных технологий и механизмов. Поэтому для NGN необходима интегрированная система планирования, способная непрерывно выполнять в едином замкнутом цикле долговременное, тактическое и текущее планирование сети для потребностей управления ресурсами (Inventory Management), предоставления услуг (Fulfi llment) и обеспечения (Assurance).

Методология NGOSS

В этих условиях для операторов особенно важным становится правильно предусмотреть внедрение соответствующих компонентов OSS уже на этапе закладки концепции построения сети с использованием технологий NGN. Европейский институт по стандартизации в области телекоммуникаций (ETSI) в своих стандартах для сетей NGN определил деловые и операционные, а также функциональные и архитектурные требования к OSS и ее компонентам, тем самым описав основные проблемы, стоящие на пути внедрения OSS для NGN, и заложив основу для их разрешения. Очень важным является то, что внедрение новых NGN услуг требует не только новых телекоммуникационных технологий, а и серьезного реинжиниринга эксплуатационных процессов. Исходя из этого, ETSI рассматривает методологию TM Forum NGOSS (New Generation Operations System and Soft ware) в качестве наиболее вероятной основы, которая может обеспечить успешную реализацию OSS для NGN. TM Forum с 2001 года в рамках методологии NGOSS разрабатывает для сетей нового поколения NGN много рекомендаций по эффективному управлению сетями в процессе предоставления услуг, тем самым определяя технологические направления и подходы развития OSS / BSS. В основе методологии NGOSS лежит перекрестное использование двух подходов, которые лежат в основе управления жизненным циклом NGOSS.
- «Рlug and play» компонентная архитектура является специфической формой SOA (Service-oriented architecture), и в итоге позволяет очень быстро создавать новые сервисы путем динамического комбинирования повторно используемых компонентов. Это должно обеспечить уменьшение времени на разработку, а также снижение затрат на внедрение и тестирование новых услуг.
- Управляемая моделью архитектура MDA (Model Driven Architecture), позволяющая специфицировать решение в виде абстрактной модели с возможностью последующей автоматизации генерации программного кода.

Компоненты методологии

Данная методология реализована в виде пакета общепринятых в телекоммуникационной индустрии спецификаций и рекомендаций и опирается на четыре взаимосвязанные между собою компонента:
- eTOM (enhanced Telecommunications Operations Map) – карта бизнес-процессов;
- SID (Shared Information Data Model) – связанная с eTOM бизнес-процессами корпоративная информационная модель;
- TAM (Telecommunications Applications Map) – связанная с eTOM бизнес-процессами карта приложений;
- Набор решений по интеграции и внедрению сетевых решений – TNA (Technology Neutral Architecture), SOA (Service-Oriented Architecture) и др.
Ключевой элемент этой методологии – eTOM, так как он является стартовой точкой для оператора связи при проведении работ по реинжинирингу его бизнес-процессов и созданию структурной модели бизнес-процессов. Создание, а затем и внимательный анализ этой модели позволят оператору определить наиболее критичные зоны, с которых нужно начинать строить собственную систему OSS. Созданная структурная модель будет использована и для определения бизнес-требований к строящейся системе OSS.

Золотая середина в трансформации процессов

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

Сходимость процессов по еТОМ

Разрешению этих противоречий помогает то, что сейчас большинство ведущих производителей систем OSS / BSS участвуют в разработках TMF и в любом случае хотя бы декларируют соответствие своего программного обеспечения еТОМ. Но часто также декларируется одновременное соответствие и другим моделям процессов, например, ITIL. И разобраться, что чему сответствует и в какой мере, непросто. Можно понести неоправданные расходы и не получить результата. Поэтому в дальнейшем при выборе программного обеспечения для OSS оператору связи необходимо учитывать степень приверженности производителя программного обеспечения стандартам модели еТОМ как типовой структурной модели бизнес-процессов предоставления услуг телекоммуникационного оператора, а также хотя бы видеть сходимость своих бизнес-процессов с бизнес-процессами по еТОМ. В противном случае компании грозят полная зависимость от выбранного поставщика приложения и сложность интеграции с информационными системами других производителей.

Роль общей информационной модели

Аналогичные аргументы можно привести и в пользу использования общей информационной модели SID, которая имеет непосредственную связь со структурной моделью еТОМ. Использование модели SID, позволит более легко и правильно определить функциональные и интеграционные требования к создаваемому решению и на этой основе создать необходимые модели данных для внедряемых приложений. Учитывая наши отечественные реалии и то, что поставщики приложений пока не все полностью придерживаются какой-либо стандартной
схемы данных, модель SID пока играет не столько роль общей схемы данных, сколько позволяет задать базис основных сущностей, которые связаны со структурой процессов eTOM или с другими бизнес-моделями.

Стандарт определяет развитие OSS

Появившись как средство повышения эффективности управления телекоммуникационными ресурсами, современные OSS становятся средством, без которого в сетях нового поколения невозможно предоставление услуг. Вместе с тем технологические направления и подходы развития OSS, как видно из вышеприведенного, определяют стандарты, в частности, такие как методология NGOSS для сетей нового поколения NGN. Как раз для эффективного управления такими сетями в процессе предоставления услуг в NGOSS и приведено много рекомендаций.

SOA на службе операторов связи

Широкий ассортимент и высокое качество пре­доставляемых услуг не­обходимы операторам связи, чтобы удовлетворить расту­щие потребности бизнес- и частных клиентов. Для решения этих задач разработаны сети нового поколения NGN (New Generation Network). Что­бы управлять этими сложными се­тями требуются системы эксплуата­ционной поддержки OSS (Operations Support Systems) с новыми функция­ми, обеспечивающими качествен­ное функционирование пользова­тельских услуг и технологических служб. Реализация современных ре­шений OSS в NGN требует стандар­тизации, которая была предложена в отраслевой методологии NGOSS (New Generation Operations System and Software). В ее основе лежит ис­пользование «Plug and play» компо­нентной архитектуры, являющейся формой SOA, которая позволяет создавать сервисы путем динамиче­ского комбинирования повторно-используемых компонент. В рамках такого подхода разработаны, в част­ности, рекомендации по картам бизнес-процессов (eTOM, enhanced Telecommunications Operations Map) и корпоративная информационная модель (SID, Shared Information Data Model), связанная с еТОМ бизнес-процессами.

Технологии архитектуры SOA

Рекомендации NGOSS очень важны для интеграции приложений, исполь­зуемых для построения OSS-решения, а также для управления взаимодей­ствием этих приложений для автомати­зации конкретных бизнес-процессов, поскольку стандартизируют создание соответствующей архитектуры OSS-решения. Наиболее перспективным подходом в рамках NGOSS признано использование архитектуры SOA. Эта архитектура основана на нескольких технологиях (интеграционная шина, шина сообщений, сервисная шина, шина данных и др.) и позволяет выполнять обмен сообщениями, преоб­разование данных, маршрутизацию и согласование («оркестровку») сер­висов. При этом появляется возмож­ность гибкого управления пользовательскими услугами за счет повторного использования сервисов и изменения бизнес-процессов их предоставления преимущественно путем конфигури­рования, вместо программирования.

Интеграция мультивендорных продуктов

После того как на смену интеграци­онной шине EAI (Enterprise Application Integration) пришла технология сервис­ной шины ESB (Enterprise Service Bus) архитектура SOA получила на рынке OSS-решений значительное признание. SOA на основе интеграционного про­граммного обеспечения с однородной интеграционной средой (на базе сервера приложений) уже используется ведущи­ми поставщиками (вендорами) для объе­динения своих OSS-приложений в единое OSS-решение. Но операторам приходится при построении своих OSS использовать по тем или иным причи­нам OSS-продукты различных постав­щиков, а также интегрировать уже рабо­тающие приложения с новыми. Поэтому приходится строить архитектуру SOA для интеграции разнородных интегри­рованных приложений с использовани­ем уже другого интеграционного про­граммного обеспечения.

Гибкость работы с данными

Кроме того, оказалось, что чи­сто синтаксической совместимости данных (совместимость форматов) для успешного использования преи­муществ архитектуры SOA не доста­точно, что также необходима совме­стимость на семантическом уровне, т. е. одинаковое понимание всеми сторонами элементов данных, которы­ми они обмениваются. Так появилось понятие сервисов данных и шины дан­ных EDB (Enterprise Data Bus), через которую они взаимодействуют.
Для преобразования потоков дан­ных EDB может импортировать и ис­пользовать общую информационную модель, например SID. Развитию EDB сейчас уделяется первостепенное внимание. Считается, что EDB поможет SOA стать высокоэффективной и об­щедоступной технологией. На самом деле еще нет программного обеспе­чения полностью соответствующего EDB. Но некоторые поставщики ин­теграционных приложений уже пред­ложили программное обеспечение, которое можно интегрировать с ESB для решения вопросов обмена данны­ми в средах, основанных на использо­вании сервисно-ориентированных ар­хитектур (SOA), и обеспечить такую же гибкость работы с данными, какую SOA дает для сервисов. Это позволяет снизить затраты времени и средств, необходимых для обеспечения инте­грации систем OSS/BSS обеспечивая, таким образом, более быстрое предо­ставление новых сервисов.

Выбор сценария

Сервисно-ориентированная ар­хитектура может быть использована для реализации как простых, так и сложных бизнес-сценариев, например:
- интеграция приложений;
- интеграция с базами данных;
- использование сервисов различных приложений;
- автоматизация процессов посред­ством оркестровки сервисов;
- сервисно-ориентированный бизнес.
Выбор необходимых для реализа­ции сценариев технологий SOA (напр, типа шины) определяется выполняе­мыми задачами и конкретными усло­вия развития OSS-решения оператора телекоммуникационных услуг. Что ка­сается СНГ, и Украины в частности, то проекты с использованием элементов SOA носят пока интеграционный характер, который не стоит путать с изначально выбранной архитекту­рой SOA. Стремление заказчиков со­хранить реально работающие прило­жения вполне понятно, и выбрасывать их ради SOA никто пока не имеет желания. Но для реализации OSS, соответ­ствующих сетям NGN, без технологий SOA обойтись будет очень сложно или, скорее всего, вообще невозможно.

Многофакторность условий

Появившись как средство повы­шения эффективности управления телекоммуникационными ресурсами, современные OSS становятся сред­ством, без которого в сетях нового по­коления невозможно предоставление услуг. В итоге для реализации полнофункциональной OSS необходим зна­чительный набор компонент от раз­ных производителей и выполнение большого объема интеграционных ра­бот. На рынке достаточно много пред­ложений класса OSS, в той или иной степени обеспечивающих конкурент­ные преимущества и стабильность в управлении телекоммуникационным бизнесом. С чего начать и в какой по­следовательности вести наращивание функционала - вот те вопросы, кото­рые волнуют оператора, решившего­ся на внедрение OSS. Несмотря на то, что до последнего времени наиболее востребованными были своего рода зонтичные OSS-решения (Umbrella Management System), которые решали задачи технического учета сетевых ре­сурсов (IMS) и обработки событий сети (FMS), к сожалению, единых ответов на эти вопросы сегодня дать нельзя. Кроме того, OSS-решение конкретного оператора не может быть неизменным, прежде всего, в силу изменчивости его бизнес-процессов и необходимости соответствовать вызовам рынка.

Гладко было на бумаге

Применение любых методологий для реализации новых сложных тех­нических решений без соответствую­щего опыта похоже на пользование крупномасштабными географически­ми картами: гладко было на бумаге, да ухабы подвели. Многовариантность архитектуры, мультивендорность, многофакторность условий при реа­лизации OSS-проектов в парадигме NGOSS - все это требует знаний и практики в реализации. Поэтому в таких проектах особенно велика роль системного интегратора, способ­ного помочь оператору в выборе адек­ватных его требованиям приложений для создания и поддержки в эксплуа­тации эффективного OSS-решения. Выбранный оператором системный интегратор должен быть способен вы­полнить весь комплекс работ по про­ектированию, поставке, монтажу, ин­теграции и пуску в эксплуатацию всех элементов поставляемого решения, обучению персонала, а также обеспечить требуемые виды обслуживания и поддержки установленного обору­дования и программного обеспечения. Учитывая практические для текущего момента требования мультивендорности поставляемых решений, а также необходимость создания комплекс­ного OSS-решения и его интеграции с существующими компонентами OSS и другими автоматизированными си­стемами - это является непростой задачей. При этом интегратор должен удовлетворить не только текущие тре­бования, но и представить концепцию перспективного развития (roadmap) OSS-оператора с учетом перспектив развития телекоммуникационных технологий и операторского бизнеса. Для успешного решения этих задач интегратор должен опираться на стан­дарты, рекомендации и методологии в области создания, управления и под­держки эксплуатации телекоммуника­ционных сетей (TMF, ITU-T, TISPAN и др.); с самого начала закладывать возможности интеграции, отдавая предпочтение решениям, соответству­ющим международным стандартам и поддерживающим открытые интер­фейсы. Такой подход также должен быть основой для создания прединтегрированных решений или их со­ставных частей, поскольку это напря­мую влияет на длительность проекта и связанные с ним издержки.

Методология для «индпошива»

Но вместе с тем основой взаимо­действия с заказчиком для построе­ния OSS-оператора должен быть индивидуальный подход к каждому заказчику, гарантирующий построе­ние OSS-решения, удобного в работе, учитывающего все нюансы эксплуата­ционной деятельности оператора и направленного на достижение его конеч­ных бизнес целей. Реализация целей
должна достигаться отображением це­лей заказчика на приемлемые для него модели бизнес-процессов, информа­ционную и функциональную модель и, в конечном счете на программно-техническую инфраструктуру системы операционной поддержки - OSS. Та­кой подход к созданию OSS-решения, особенно для сетей NGN, будет за­труднительным без практического использования интегратором методо­логии TMF NGOSS. Эта методология является также основополагающей для постепенного пошагового вне­дрения интегратором компонент OSS, с обеспечением практического ис­пользования каждой из внедренных компонент и получения экономиче­ского эффекта после каждой фазы вне­дрения.

Факторы успеха

Успех проекта внедрения OSS во многом определяется также степе­нью взаимопонимания между заказ­чиком и исполнителем. Здесь особен­но важным является желание и умение интегратора своевременно привлечь заказчика к совместному выполнению ряда работ в рамках проекта внедре­ния OSS. Для интегратора - это спо­соб своевременно понять, насколько адекватно и четко сформулированы требования к проекту, и минимизиро­вать риски. Для заказчика такой под­ход является эффективным способом снижения стоимости проекта, уменьшения рисков и скорейшего получение его специалистами знаний для после­дующей эксплуатации и поддержки.
И наконец, предоставления но­вых услуг посредством сетей ново­го поколения могут потребовать серьезных изменений организационно-функциональной среды и процессов оператора связи. Как минимум инте­гратор должен обладать соответствую­щими знаниями и навыками, чтобы инициировать и поддержать правиль­ное и своевременное проведение изменений, необходимых для внедрения предлагаемых OSS-решений.

Александр Куник