Что нам стоит middleware построить
В целом, многие из участников нашей дискуссии согласились с тем, что middleware’ов стало много и что лишь немногие из них удовлетворяют современным требованиям операторов.
У меня есть ощущение, что слова презентаторов вроде: «интегрировать новую услугу просто! это же всё просто веб-приложение!» легли в уши не столько адресатам среди операторов, сколько разработчикам веб-приложений, типа CMS. Эти парни решили, что сейчас-то они возьмут свою зашибенскую CMS, которую писали для магазина подержанных автомобилей и, прикрутив тему под PAL-разрешение, охватят страшную толпу клиентов, которые не готовы будут платить за платформу услуг от десятков тысяч до миллионов долларов.
На нашем рынке обычно довольно неплохо срабатывала идея «народных» продуктов. Биллинги IP-телефонии и интернет за менее чем 10 тыс долларов, программные коммутаторы IP-телефонии за те же деньги. Есть ли перспективы у продукта с условным названием «народный middleware»?
Попробуем определить фундаментальные требования к middleware’у, который нужен оператору. Операторы, если у вас есть что добавить — не стесняйтесь.
- Операторского класса надёжность. Ожидания абонентов относительно надёжности телевизионного приёмника сформированы годами. Качество традиционной межгородской телефонной связи стало предметом массы классических шуток шутников и юмористов — от А. Райкина до безумцев из «Аншлага». Телевизор при этом, если уж работал, то работал.
- Функциональная расширяемость. Все кругом только и твердят о том, как просто разворачивать новые услуги на платформе IPTV. Платформа обязана обеспечивать возможность разработки приложений на её базе. Соответственно, иметь для этого открытый и документированный SDK.
- Широкие возможности по интеграции. Собственно, то, что делает middleware таковым. То есть, целая куча тщательно документированных API, которые позволят подключать новые услуги в BSS, провижнить их в middleware, а он, в свою очередь, будет проключать эти услуги в DRM, VoD, STB и рапортовать об успешности или неуспешности операций в OSS. Сюда же относится необходимость обеспечения максимально простой интеграции с STB.
- Достаточная интегрированность для начального запуска. То есть, система не должна быть «пустой», с торчащими наружу интерфейсами. Она должна успешно подставляться в матрицу компонентов решения, которую каждый оператор для себя составляет. Интегрироваться со всеми невозможно и не нужно, но интегрироваться с лидерами отрасли нужно обязательно.
Мы не говорим о базовых и очевидных требованиях, вроде «возможности импортировать EPG».
Сделать продукт дешёвым можно только за счёт унификации, создания из него «коробочного» решения. Код унифицирован, процесс его продажи тоже прост и понятен — полный вперёд. В случае с операторскими решениями IPTV такое получается крайне редко. Я б сказал, до сих пор ни у кого не получилось. IPTV пока ещё — штучный товар и довольно долгое время ещё будет им оставаться. Критическая масса операторов для того, чтобы решение стало commodity, в данном случае набираться будет довольно медленно — уж очень высока стоимость вхождения с качественным сервисом, если учесть затраты на апгрейд сети и закупку абонентских устройств. На эту «коммодитизацию» технологии и наработку бизнес-моделей для более явного окупания подобных проектов потребуется время, во время которого телекоммуникационный рынок, скорее всего, как раз консолидируется до того состояния, в котором он пребывает в большинстве цивилизованных стран. То есть, будет поделен между крупными игроками.
Это я к чему всё писал-то? Не к тому, чтобы все, кто берётся писать middleware сейчас, бросили это занятие, а к тому, чтобы операторы, которые озабочены выбором платформы сейчас, осознавали, с чем они могут столкнуться.
Тем не менее, рынок для небольших платформ IPTV, конечно же, есть. Я бы не рискнул, наверное, разворачивать на Anevia сеть IPTV в сотню тысяч абонентов, однако не могу представить более эффективного решения для организации, скажем, гостиничного сервиса IPTV. Разве что Nevotek. Кроме того, в предверии той же консолидации масса небольших операторов должна бы, по логике, бросится повышать собственную стоимость, в надежде продаться задорого. Небольшое решение IPTV и с шумом запущенная на его базе страшно модная услуга как нельзя лучше в этом смысле помогают.
И, не совсем в кассу, но мне напомнили, что мы обещали выдать PR-службе Корбины доступ к блогу в случае, если они запустят к марту сервис, а также съесть перед зайцем свой паспорт. Но объявлений о подобном запуске я не слышал. Так что дышу ровно. Справедливости ради замечу, что бурная движуха, которую развила Корбина, говорят, нашла подтверждение. Тот же ВимКом на CSTB, например, был полон оптимизма. Правда, отводя в сторону глаза, говорили, что во всём мире ставят MSTV 2, а в Россию привезли MSTV 1.3. Ну и вспоминали, что со времён DOS’а, у Microsoft всё окончательно налаживалось к версии 3 (вспоминаем историю MS DOS, MS Windows, MS Windows NT).
5 последних записей автора Павел Ребров
- IPTV Russia в Facebook - July 27th, 2010
- PirateBay против всех-всех-всех - February 16th, 2009
- CSTB 2009 - January 28th, 2009
- Ещё раз о контентной бирже - January 27th, 2009
- С Новым годом! - January 1st, 2009

Мартынов Александр сказал,
Март 10, 2007 @ 8:29
Я думаю, что недостаточное качество middleware в России (да и в целом в мире) вызвано тем что область достаточно новая и нету просто достаточного опыта и представления о том как это должно быть сделано правильно. Так же сказывается реальное отсутвие мировых стандартов на стандартные сервисы (EPG напимер)
belovictor сказал,
Март 12, 2007 @ 14:39
Да кому нафиг нужны стандарты на EPG? На самом деле нужен только один стандарт - на расширения браузера для SetTopBox - стандарт на функции JavaScript, на тэги и тому подобную байду.
TaNGO сказал,
Март 12, 2007 @ 15:09
Павел, отличная статья
Позже добавлю комментарии
Roman сказал,
Апрель 26, 2007 @ 16:50
2 Виктор и Павел
Виктор, странно слышать про стандартизирование браузера, JS и т.д. Во первых, этим отсекается сегмент STB ориентированных приложений (например решение от эспил), а во вторых, если уж говорить откровенно, то визуализация (пользовательский портал) - это не MW. Тенденция объединения этих понятий, во многом связана с той тенденцией, которая была 2-3 года назад. На данный момент принцип “всё в одном” изжил себя, во первых в силу развития сервис ориентированных приложений, а во вторых по мере роста проектов. Как ты писал итогам CSTB, mw - много, но …….. попробуй найти хотя бы 5 отличий в бизнесс логике(БЛ). а ведь именно БЛ определяет сущность mw. Тот же форум в олимпии показал, что близнецы братья не только те mw, что ,что были представлены на cstb, но западные аналоги. Я провёл около часа у стенда Indastria, общаясь с их главным архитектором, было “очень интересно” узнать, что выпустив продукт, они “озадачились” - “но они все такие….”.
2 Павел, наверное ты прав, классифицируя mw, только я бы взглянул на это с другой стороны, а именно - сервисной. Давай попробуем разобраться - что что может обеспечить “дешёвый” mw и операторского класса. По моему как то странно сравнивать “жёлтое” и “сладкое”. каждый класс ориентируется на свой уровень сервиса. В первую очередь - опять же это связанно с БЛ. Ведь vod,btv, rss можно сделать даже на “коленках”, другое дело интерфейс провижининга, инвентори. Но ……. если говорить про контент, используемый в сервисах, то потребуется ещ
Roman сказал,
Апрель 26, 2007 @ 16:53
Но ……. если говорить про контент, используемый в сервисах, то потребуется ещё и ревенью менеджмент, менеджмент контента и т.д.
Сорри, что то глюканул комп, поэтому и получилось 2 части