Корпоративные мессенджеры и воркспейс‑комбайны. Разбираем вендорский капкан

“I must create a system, or be enslaved by another man's. I will not reason and compare: my business is to create”

William Blake, Jerusalem The Emanation of the Giant Albion

Мы сегодня не можем из мессенджера «А» написать адресату в мессенджер «Б», это как‑то само собой разумеется. Но, одновременно, из одного почтового сервиса в любой другой — можем без проблем, в этом смысл почты. Тоже само собой разумеется. И разве это не странно? Не знаю, как вас, а меня давно мучает этот парадокс.

30 июня на Cnews вышел обзор рынка корпоративных мессенджеров, в котором отмечено «...превращение мессенджера в операционную среду сотрудника..». Это, на мой взгляд, самый ценный инсайт обзора Cnews, и он заслуживает отдельного серьезного обсуждения. 

Почему это важно? Мы живем в эпоху постоянной доступности. По данным Microsoft Work Trend Index, около 60% рабочего времени в цифровой среде уходит на коммуникации (созвоны, чаты, письма). При этом, около 70–80% ежедневного объема взаимодействий (не чистое время, а количество коммуникационных актов) приходится на корпоративные мессенджеры и почту — они покрывают оперативную координацию и регулярные апдейты. 

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

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

Все изложенное в моих статьях является моей частной точкой зрения.

Содержание:

1. До начала времен. Огороженные сады для электронной почты

2. 3G и бум мессенджеров

3. Slack. Первый и последний полноценный корпоративный мессенджер

4. Почему корпоративные мессенджеры это не про конфиденциальность?

5. Звоночки

6. Teams. Опоздал к началу, но успел испортить праздник

7. Россия. Клинч закрытых экосистем в красном океане

8. Кейс МойОфис. Похмелье после бума импортозамещения

9. On‑prem закрытых экосистем — концентрация рисков, вместо снижения

10. Оцениваем Vendor Lock‑In корпоративных мессенджеров

11. Отрицательный RnD импортозамещения

12. Matrix. Паровозик, который смог

13. Мы напилили закрытых экосистем ровно к моменту, когда в остальном мире их стали разбирать

14. Суверенная архитектура предприятия и рабочая среда без границ

15. Фокус на массовый сегмент, чтобы вывести Matrix из тени X.400

* Компания Meta Platforms Inc. и принадлежащие ей социальные сети Facebook и Instagram признаны экстремистскими организациями и запрещены на территории Российской Федерации. Мессенджер WhatsApp принадлежит компании Meta, но его использование гражданами для личного общения не запрещено.

Начну с истории.

До начала времен. Огороженные сады для электронной почты

В августе 1982 года Джон Постел опубликовал спецификацию RFC 821 — SMTP. Мы все до сих пор его используем ежедневно в мэйлах, а тогда CompuServe, Prodigy и Telemail, первые платные телекоммуникационные сети, которые появились в США с развитием ПК, предпочитали игнорировать SMTP и оставаться закрытыми экосистемами. Пользователь CompuServe не мог отправить письмо пользователю Prodigy.

Коммерческие сети намеренно не строили мосты, чтобы удерживать клиентов внутри своей подписки. Их поэтично называли «Walled Gardens» — закрытые сады. Письма, форумы, новости и котировки акций циркулировали исключительно внутри серверов конкретного провайдера.

Каждая сеть работала на базе своего закрытого программного обеспечения и проприетарных протоколов. Пользователи подключались к их центральным мейнфреймам через телефонные модемы с помощью специальных терминальных программ. У каждой сети — изолированная адресация. На CompuServe вместо привычного email‑адреса использовался цифровой идентификатор (например, 77777,123). На Prodigy адреса выглядели как уникальные буквенно‑цифровые коды (например, ABCD12A).

Однако клиенты начали требовать возможность отправлять сообщения за пределы одной сети. К началу 1990-х коммерческие сети поняли, что теряют клиентов. Они начали строить шлюзы, прокси‑сервера с трансформацией данных (Data Mapping). Шлюз брал внутреннее проприетарное сообщение CompuServe, конвертировал его формат в стандарт SMTP и отправлял в Интернет. Именно тогда у пользователей CompuServe появилась возможность получать письма извне на адрес формата 77777.123@compuserve.com (запятую пришлось заменить на точку, так как SMTP не поддерживал запятые в адресах). И уже к середине 1990-х, со взрывным ростом Всемирной паутины (WWW) изолированные сети потеряли смысл. Проприетарные почтовые системы Prodigy и CompuServe были полностью демонтированы или переведены на стандартные интернет‑протоколы (SMTP для отправки, POP3/IMAP для приема).

Так вендор‑лок сетей из 80-х пал под натиском SMTP.

3G и бум мессенджеров

К 2013 году индустрия и пользователи уже успели освоить 3G мобильные сети, по всему миру началось массовое развертывание сетей 4G. Это был год, когда на мировом рынке произошел исторический перелом: продажи смартфонов впервые официально превысили продажи кнопочных телефонов — 55,1% от всех проданных мобильных устройств в мире, по данным IDC.

WhatsApp* в 2013 году преодолел отметку в 400 миллионов активных пользователей в месяц, обрабатывая по 50 миллиардов сообщений в день. Созданный в 2010 году Viber, к маю 2013 года преодолел отметку в 200 миллионов пользователей по всему миру, а уже к концу декабря 2013 года 280 миллионов. Павел Дуров в августе 2013 года запустил Telegram. 

До 2013 года мобильные операторы зарабатывали на поштучной оплате: абонент платил за каждую минуту разговора и за каждое SMS. Мессенджеры разрушили эту модель.
Мобильные операторы пытались встроить функции мессенджера (чат, передача файлов, видеозвонки) прямо в стандартную телефонную книгу смартфона, чтобы пользователю не нужно было скачивать сторонние приложения. Главной коллективной надеждой операторов стал глобальный стандарт RCS и бренд Joyn, созданный под эгидой ассоциации GSMA. Проект захлебнулся из‑за бюрократии. Операторы годами не могли договориться о совместимости сетей между собой, в то время как WhatsApp* обновлялся каждые две недели. К тому же в 2013 году Joyn тарифицировался отдельно, что отпугнуло пользователей.

Локально операторы запускали свои приложения (например, МТС позже создал МТС Connect, а МегаФон продвигал МультиФон), но они не смогли конкурировать с глобальными игроками. 

Операторы начали массово внедрять тарифные планы, куда уже были включены безлимитные или огромные пакеты SMS и фиксированный объем интернет‑трафика,
все с той же идеей — снять у абонента стимул уходить в сторонние приложения. Но эта стратегия лишь ускорила переход пользователей на мобильный интернет, который они тратили на тот же WhatsApp*.

Тогда мобильные операторы во всем мире стали лоббировать регуляторные ограничения, жалуясь на «недобросовестную конкуренцию» со стороны IT‑компаний. В Латинской Америке, Европе и на Ближнем Востоке операторы переходили к прямым техническим ограничениям, например, шейпингу (занижению скорости) интернет‑трафика конкретно для протоколов VoIP (Skype, Viber) и текстовых мессенджеров, из‑за чего сообщения доставлялись с задержкой, а звонки постоянно обрывались.

В конечном итоге, сотовые операторы проиграли эту войну и были вынуждены смириться. Уже к 2014–2015 годам они окончательно переориентировали свой бизнес с продажи минут и SMS на продажу гигабайт мобильного интернета.

В 90-е закрытые экосистемы проиграли SMTP. Через +/‑ двадцать лет открытый, но стремительно устаревший за пару лет протокол SMS, с его жестким ограничением в 140 байт, проиграл новым закрытым экосистемам. Все «взлетевшие» мессенджеры — чистая реализация «Walled Gardens».

Вы привязаны к платформе, интероперабельности нет. Вы не можете из официального приложения Telegram написать пользователю в WhatsApp*. Чтобы общаться с друзьями, вы обязаны установить именно их приложение и согласиться с условиями использования конкретного вендора. Каждая платформа обладает полным контролем над клиентом: сама решает, какие функции внедрять, кого банить и какие правила модерации устанавливать. 

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

Slack. Первый и последний полноценный корпоративный мессендеж

В августе все того‑же 2013 года, в режиме закрытого предварительного тестирования вышел Slack. Вообще, изначально это был инструмент для внутреннего общения команды Стюарта Баттерфилда, которая создавала онлайн‑игру Glitch в 2009–2012 годах. Но игра провалилась, и сделать пивот было понятной идеей на фоне бума потребительских мессенджеров. 

До Slack корпоративное общение строилось вокруг ICQ, Skype, Microsoft Lync или Email.
Все эти инструменты создавались по принципу p2p. Они копировали логику обычных писем или телефонных звонков. Slack предложил концепцию shared space (общего пространства), где во главе угла стоит не конкретный отправитель, а проект, отдел или тема (каналы). 

Именно Slack задал моду на каналы и треды, что позже скопировала Microsoft и остальные. Диджитал‑командам нравилось продвинутое форматирование кода в чатах и неформальный дизайн. Slack позволял связывать в один чат уведомления из GitHub, Trello, Zendesk и сотен других сервисов. Но все это вторично для нашей истории. 

Ключевое в Slack сама специфика digital‑команд. Для ИТ‑ и digital‑сферы изоляция от внешнего хаоса плюс, а не минус.

Внутри команды общение происходит ежесекундно, в то время как клиенту или внешнему подрядчику достаточно написать одно письмо по итогам недели и сделает это специальный человек — продакт или проджект. Отсутствие спама из внешнего мира позволяет командам держать фокус на продукте и внутреннем взаимодействии, снижать когнитивную нагрузку на переключение контекста. В отличие от личных переписок в Skype, открытые каналы Slack позволяли любому новому разработчику мгновенно войти в курс дела, просто прочитав историю сообщений. Это помогало формировать культуру прозрачности и обеспечивать общий контекст для команды. Название Slack в какой‑то момент стали расшифровывать как Searchable Log of All Conversation and Knowledge (Журнал всех обсуждений и знаний с функцией поиска). 

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

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

Кроме них, пожалуй, еще военные и специальные службы, но это уже решение специальных, а не бизнес‑задач.

Диджитал‑команды — прекрасный сегмент. Но это небольшой сегмент. 2-х миллионов активных пользователей в день Slack достиг только к концу 2015 года. Сравните с динамикой пользовательских мессенджеров, стартовавших одновременно со Slack.

В январе 2015 года сооснователь WhatsApp* Ян Кум объявил о планке в 700 млн, в апреле мессенджер пробил 800 млн, а к сентябрю 2015 года официальная аудитория достигла 900 миллионов человек. Всего через несколько месяцев (в феврале 2016) WhatsApp* взял историческую отметку в 1 миллиард пользователей. 

Почему корпоративные мессенджеры это не про конфиденциальность?

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

Компании в России ежегодно тратят миллиарды рублей на лицензии корпоративных мессенджеров. Вся реальная работа внутри компаний и тем более с внешними контрагентами, оперативное решение проблем, обмен «живой» информацией ведутся в Telegram.

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

Telegram — классический «Walled Garden», такой же как ваш корпоративный мессенджер, просто очень большой.

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

Внутри компании, как только количество сотрудников достигает предела компании (например, 100 человек), полезность сети замораживается. График ценности превращается в горизонтальную прямую.

Число пользователей в Telegram превысило миллиард. Формула ценности сети () по закону Меткалфа (Квадратичная зависимость):

где

 — количество пользователей,
 — некоторый коэффициент ценности одного соединения.

По закону Меткалфа базовая ценность () Telegram колоссальна — триллион (10 в 18 степени). Даже если в вашей компании 100 тыс. сотрудников, базовая ценность вашего мессенджера не превысит десяти миллиардов (10 в 10 степени). Разница базовой ценности Telegram (триллион) и базовой ценностью крупнейшего внедрения российского корпоративного мессенджера (10 миллиардов) составляет ровно 8 порядков, то есть у Telegram она больше в 100 миллионов раз.

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

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

Администратор должен выслать инвайт, пользователь должен зарегистрировать новый рабочий аккаунт, скачать отдельное приложение или открыть новую вкладку. В Telegram, узел (пользователь) уже находится внутри сети. Он уже авторизован, приложение открыто. Чтобы начать рабочий процесс, достаточно скинуть ссылку на контакт или группу. Транзакционные издержки — нулевые.

Ваш мессенджер проигрывает и в экономике внимания. В контексте интерфейсов, согласно закону Зипфа, человек минимизирует свои усилия. Telegram для пользователя стал «Супер‑сетью» (Super‑network), которая объединяет в себе три разных графа связей:

1. Личные связи (семья, друзья).
2. Потребление контента (новостные каналы, профессиональные блоги).
3. Рабочие связи (коллеги, чаты проектов).

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

На начальном этапе ценность сети растет медленно. После достижения «критической массы» () начинается взрывной рост по Меткалфу. В конце, когда рынок перенасыщен, рост полезности замедляется и стремится к максимуму ().

Функция (S‑образная кривая полезности), учитывающая Критическую массу (Кривую насыщения):

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

Cовременный бизнес — это открытая система. Telegram побеждает, потому что его математическая полезность как закрытой глобальной сети () на порядки выше полезности любой, даже самой удобной, но изолированной корпоративной
сети ( где ).

Корпоративные мессенджеры в существующем виде — это просто гарантированное теневое ИТ (Shadow IT) в компании. Telegram или WhatsApp* в корпоративной практике, параллельно с безопасными корпоративными мессенджерами — пресловутый «слон в комнате», его не принято замечать.

Будьте последовательны. Запретите внешнюю почту. Сделайте закрытый почтовый сервер, где сотрудники смогут писать только сами себе. Звучит как абсурд? Этот абсурд стал нормой корпоративных мессенджеров.

Когда речь заходит про информационную безопасность, обычно имеется ввиду Триада CIA (Конфиденциальность, Целостность, Доступность). Но если мы возьмем более современную гексаду Паркера (Parkerian Hexad), концепция закрытого контура начинает трещать по швам.

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

Навешивай на «ворота в чистом поле» любые дополнительные замки (DLP и тому подобное), это никак конфиденциальности не поможет.

Звоночки

Все в том же рубежном 2013 году Эдвард Сноуден раскрыл миру некоторые детали программы PRISM и тотальной слежки спецслужб США за миллионами людей, в том числе за главами государств. В числе прочего, выяснилось, что АНБ США просто жило в личном мобильном телефоне Ангелы Меркель. 

Все в том же рубежном 2013 году, аудитория мессенджера Threema мгновенно достигает 250 000 человек. Он был создан за год до этого тремя молодыми швейцарскими разработчиками. Facebook* в 2014-м покупает WhatsApp*, что вызывает вторую волну миграции пользователей в Threema. В том же 2014 году бывшие топ‑менеджеры и инженеры Skype (при поддержке сооснователя Skype Януса Фрииса) запускают мессенджер Wire со штаб‑квартирой в Швейцарии. 

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

Администрация Обамы в 2016-м году представила первый черновик, который лег в основу принятого в марте 2018 года CLOUD Act. Он обязывает технологические компании США выдавать данные по запросу властей, независимо от того, где физически находятся их серверы. Это определило требования европейских регуляторов, полиции и госструктур к цифровому суверенитету.

Threema Work, SaaS‑версия мессенджера с панелью администратора для управления пользователями появилась в 2016 году. Сразу после выхода корпоративной версии мессенджер начали точечно тестировать и внедрять городские администрации и муниципальные службы в Швейцарии и Германии. В 2018–2019 гг. начались крупные закупки для региональных госорганов и полиции. В июле 2021 года компания анонсировала, а к осени запустила продукт Threema OnPrem, позволяющий изолировать всю переписку на 100% внутри серверов заказчика.

Если Threema код не открывает, то Wire свой поход в гос. органы начал с того, что в 2016 году опубликовал исходный код всех пользовательских приложений под лицензией GPLv3, а в 2017 году и Wire открыл код своего сервера под лицензией AGPL. И затем, на два года раньше Threema, в 2019 году Wire полноценно запустил self‑hosted версию.

В 2021 году швейцарская армия перешла на Threema, а Wire в 2021–2022 стал официальным инструментом связи для федерального правительства Германии. Естественно, и этим внедрения Threema или Wire не ограничиваются, ни в гос. ни в коммерческом секторе. Данные по MAU Wire не раскрывает, но в Google Play количество скачиваний замерло на отметке в 1+ млн. Threema заявляет о 12 миллионах пользователей: около 3 миллионов приходится на корпоративный сектор. Threema Work и Threema OnPrem используют более 8 000 компаний и ведомств.

Это совсем немного. Сравните с показателями Microsoft Teams, доступным только SaaS. Его аудитория в ЕС и EMEA (Европа, Ближний Восток и Африка) оценивается примерно в 95–100 миллионов активных пользователей. В одной только Германии Teams используют более 285 000 компаний, а во Франции — более 132 000 предприятий. 

Teams. Опоздал к началу, но успел испортить праздник

Публичный релиз Zoom 1.0 состоялся все в том же рубежном 2013 году, на год опередив релиз Slack. Еще в 2011 году, Эрик Юань, вице‑президент по разработке программного обеспечения, Cisco WebEx представляет руководству Cisco новую систему видеоконференций, удобную для смартфонов. Идея не принимается, Юань покидает Cisco и основывает собственную компанию. 

И только спустя три года после запуска Slack, был представлен Microsoft Teams, созданный как его главный конкурент и на замену устаревшего Skype. 

Teams с самого старта упирал на большие видеоконференции, календари Outlook и онлайн‑совещания, позиционируясь больше как инструмент для менеджмента и бэк‑офиса. Если Slack завоевал рынок «снизу вверх», через диджитал‑команды, которые с его появлением обрели инструмент для совместной работы, то Microsoft заходила «сверху вниз» через топ‑менеджмент и ИТ‑отделы крупных компаний, предлагая соответствие комплаенсу, интеграцию с инфраструктурой Microsoft — все в пакете Office 365 (Microsoft 365). 

Главным козырем Zoom была простота: чтобы войти в созвон, не нужно было создавать учетную запись, регистрировать компанию или скачивать тяжелые программы. Достаточно было просто кликнуть по ссылке из браузера или телефона. 

В апреле 2019 года Zoom успешно выходит на IPO. Очень своевременно, потому что в конце 2019 года начали фиксировать первые случаи заболевания COVID-19. Когда весной 2020 года начались глобальные локдауны и миру срочно потребовалась видеосвязь, у Zoom уже были финансовые ресурсы, огромный штат инженеров и готовая публичная инфраструктура, способная выдержать наплыв пользователей (рост с 10 млн до 200 млн участников в день). В ходе IPO компанию оценили примерно в 9,2 миллиарда долларов. Всего через полтора года, в разгар пандемии (октябрь 2020 года), капитализация Zoom на пике превышала 140 миллиардов долларов.

Slack тоже вышел на IPO в 2019 году, но публичный статус только усугубил проблемы, создав давление со стороны инвесторов. Когда весной 2020 года весь мир ушел на удаленку, акции Zoom взлетели в космос, Slack не смог показать сопоставимого взрывного роста. 

Для Slack период середины 2019 — конца 2020 года стал классическим примером ситуации, когда стартап создал новую нишу, но проиграл войну за масштабирование.

«Фича, а не платформа».

Осенью 2019 года Slack гордо отчитался о 12 миллионах активных пользователей в день (DAU). Спустя месяц Microsoft объявила, что у Teams уже 20 миллионов пользователей. К середине 2020 года разрыв стал многократным. Инвесторы поняли, что Slack теряет корпоративный рынок. Выручка Slack росла, но компания столкнулась с «тупиком парадигмы». Как отмечали аналитики, в 2020 году Slack “достиг своего потолка” как независимый продукт. Это вынудило руководство Slack согласиться на поглощение со стороны Salesforce за $27,7 млрд в декабре 2020 года. 

На тот момент Slack оставался отличным, но изолированным мессенджером. У него не было сильной встроенной видеосвязи (приходилось интегрировать сторонний Zoom). Он выглядел уязвимым на фоне Teams, который предлагал звонки, чаты и редактирование документов Excel/Word внутри одного окна. 

Slack отлично подходил для ИТ‑команд и стартапов, но консервативный крупный бизнес (банки, госсектор, заводы) не понимал логику каналов и тредов. Им нужно было «просто созвониться», и они массово уходили в Zoom. В пандемию в Slack пришло много новых команд, но это был преимущественно малый и средний бизнесна бесплатных тарифах. Конвертировать их в платных клиентов в условиях кризиса было крайне тяжело. Покупка со стороны Salesforce спасла Slack: мессенджер получил доступ к гигантской базе корпоративных клиентов Salesforce, колоссальные бюджеты и новый фокус развития.

Если Teams опирается на экосистему Microsoft и закрывает офисную рутину: видеозвонки, почта, календари, текстовые документы и таблицы, то Slack, опираясь на Salesforce превратился в хаб управления бизнес‑операциями и задачами: продажи, CRM‑данные, IT‑поддержка и разаботка. Slack выступает кроме того как универсальный мост интеграции с Google Drive, Notion, Atlassian и тысячами других сервисов.

ИИ в Teams, пишет саммари созвонов, генерирует заметки, форматирует текст. Slack через протокол Model Context Protocol (MCP) управляет внешними инструментами (от баг‑трекеров до аналитики Tableau), запускает рабочие процессы, меняет статусы сделок, ищет по базам данных. Менеджер может закрыть сделку, выставить счет или обновить карточку клиента, просто написав текстовую команду в Slackbot, не открывая громоздкий интерфейс Salesforce. 

После того как корпорация Salesforce выкупила Slack, платформа перестала публиковать ежеквартальные отчеты по числу пользователей отдельно от материнской компании. Аналитическим агентствам (DemandSage, Statista и Business of Apps) приходится собирать данные на основе финансовой отчетности Salesforce и веб‑трафика. Slack удерживает сильные позиции в крупном бизнесе и демонстрирует слабый рост. Оценочно, около 47 миллионов человек ежедневно используют Slack, рост на 5 млн. за три года. Для сравнения, в 2019 году (предковидный период выхода на IPO) было 10–12 миллионов, в 2023 года примерно 42 миллиона.

В 2025 году Goldman Sachs отмечал, что коэффициент удержания чистой выручки (Net Expansion Rate, NER) в корпоративном сегменте Zoom зафиксировался на отметке в 98%. Показатель NER ниже 100% означает, что старые клиенты в совокупности начинают тратить на Zoom чуть меньше, чем раньше (сокращают лицензии).

Аналитики предполагают, это происходит потому что Бизнесу тяжело обосновать покупку Zoom Docs, когда у них уже есть оплаченные MS Word или Google Docs.

Сейчас, показатель активности использования Zoom (“ежедневные участники”) стабилизировался в районе 300+ млн (Teams 320+ млн), но есть важная деталь в метриках: Zoom всегда отчитывался в «ежедневных участниках» (один человек, зашедший на 3 разные встречи за день, считается как 3 пользователя). Teams считает «чистых» активных пользователей (DAU/MAU). Поэтому реальный отрыв Teams в бизнес‑среде еще сильнее, чем кажется по сухим цифрам. Весной 2020, на пике локдаунов, у Zoom было 300+ млн «ежедневных участников», у Teams 75 млн активных пользователей.

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

Zoom внедряет ИИ помощника, пытается диверсифицировать бизнес, например, Zoom Contact Center (решения для колл‑центров) показывают двузначные темпы роста. NER удалось поднять до 99%. И несмотря на все усилия, вынужден бороться с падением акций: Совет директоров Zoom увеличил программу обратного выкупа акций (Buyback) еще на $1,0 млрд, чтобы оказать поддержку котировкам.

В целом, Zoom сумел стабилизировать свою капитализацию. Если на пике, в октябре 2020 года, на фоне глобального локдауна и взрывного спроса на удаленную связь, она достигла ~139 миллиардов долларов США, взлетев с ~19,4 млрд долларов доковидного IPO годом ранее. То в минимальной точке (середина 2023 — 2024 годов) упала почти в восемь раз от пика до ~18 миллиардов долларов США. Сейчас (август 2026): ~30,6 миллиардов долларов США.

Почему на самом деле Teams выиграл и придушил Zoom 

Продукты внутри комбайна (например, доска или таск‑менеджер в Teams) часто объективно хуже, чем специализированные аналоги типа Miro, Jira. Но админы и закупщики из крупного бизнеса все равно выбирают «комбайны», вместо того, чтобы следовать стратегии объединения в своей инфраструктуре самых сильных и специализированных программных продуктов от разных разработчиков. Почему?

Первый ответ на поверхности — иллюзия экономии: Вендоры продают «комбайны» с огромной скидкой. Купить всё единым пакетом всегда дешевле.

Ключевая причина в интеграции и администрировании: права и доступы пользователей отдельно для мессенджера, отдельно для доски, отдельно для хранения файлов и тому подобное. В комбайне увольнение сотрудника отключает его от всей экосистемы одним кликом. И рядом смежная тема — «одна шея для топора» (Single Point of Responsibility): если в связке самых прекрасных разрозненных сервисов что‑то ломается, ИТ‑директор должен искать, на каком стыке произошел сбой. Если ломается Teams, компания звонит в техподдержку Microsoft и требует починить.

В конечном итоге, мотивация и логика топ‑менеджера, покупающего Microsoft Teams, и психология обычного человека, сидящего в Telegram, абсолютно одинаковы. Называется она — стремление к минимальному трению.

Нобелевский лауреат Рональд Коуз и его фундаментальная теория трансакционных издержек идеально объясняют как это работает. В своей работе «Природа фирмы» (1937) Коуз задал гениальный вопрос: если рынок такой эффективный, почему вообще существуют компании (фирмы)? Почему люди объединяются под жестким административным началом, а не работают как независимые фрилансеры, ежеминутно заключая контракты? Ответ Коуза состоит в том, что пользоваться рынком дорого. Каждый раз искать контрагента, договариваться, проверять его честность и подписывать договор — это огромные трансакционные издержки (поиск, переговоры, контроль). Граница любой компании, по Коузу, пролегает там, где внутренние организационные расходы сравниваются с расходами на использование внешнего рынка. Как только внешняя трансакция становится дешевле внутренней, фирма аутсорсит задачу наружу.

«Комбайн», например Microsoft Teams, а шире — вся экосистема Microsoft — это классическая коузианская фирма. Подбор, взаимная интеграция и сопровождение комбинации сколь угодно превосходных решений порождает «рыночный хаос» с гигантскими трансакционными издержками. Покупка комбайна вроде Teams полностью обнуляет эти издержки. Бизнес выбирает административную директиву («всё внутри одного вендора»), потому что это радикально снижает трансакционные издержки. 

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

Индустрия думает, что конкурирует на уровне фич (у кого лучше видео, у кого красивее эмодзи или безопаснее шифрование). Рональд Коуз сказал бы: «Господа, вы конкурируете исключительно на уровне снижения издержек человеческого действия. »

Microsoft Teams победил Zoom сверху, потому что снизил трансакционные издержки закупки и администрирования для ИТ‑директора, а Telegram побеждает корпоративные мессенджеры снизу, потому что снижает трансакционные издержки общения с миром для обычного сотрудника«.»

Россия. Клинч закрытых экосистем в красном океане

Любой новый корпоративный мессенджер в мире и в России сегодня создается с оглядкой на интерфейс Slack, логику звонков Zoom и экосистему Teams. Стандарты того, как сегодня устроен рабочий процесс в ИТ, бизнесе и образовании по всему земному шару сформированы этим американским SaaS‑трио.

Teams зашел последний и подмял сегмент, своим успехом утвердив модель «вендорского комбайна» (All‑in‑One), как единственно жизнеспособную. Именно эту модель, с поправкой на On‑prem, воспроизводят российские вендоры, собирая свои закрытые проприетарные экосистемы.

Фокус, однако, в том, что стратегия «вендорского комбайна» не особо работает, если не опирается на уже достигнутое ранее экосистемное доминирование в инфраструктуре клиентов.

Вы можете «сшить» вместе чат, документы, звонки и облачное хранилище, добавить еще ИИ ассистента, но это не поможет повторить на российском рынке результат, который Microsoft Teams показал на глобальном. Или даже корректнее будет сказать, Microsoft показал. Дело потому что не в Teams.

В конкуренции закрытых экосистем решает разница в размерах. У Microsoft она в инфраструктуре рабочих мест подавляющая. Это похоже на игру ГО. Игроки захватывают территории, окружают зоны влияния и стремятся замкнуть корпоративного клиента внутри собственного контура — закрытой экосистемы. Вендоры платформ коммуникаций сначала борются за захват базовых камней — видеосвязь (ВКС) или текстовое общение (мессенджер). Затем, соединение линий, к базовому продукту начинают привязывать смежные сервисы — почту, календари, диски и задачи, интерактивные доски и далее по списку. Это все здорово, но дело в том, что корпоративная инфраструктура, обслуживающая рабочие места, всем перечисленным не исчерпывается. Доска шире.

Teams — это не просто программа, это навершие пирамиды Microsoft, результат тридцатилетней эволюции экосистемы Active Directory, Windows и MS Office. Рынок корпоративных коммуникаций (мессенджеры и ВКС) не вещь в себе, а глубоко зависимый, вторичный слой над рынком цифровых рабочих мест (Digital Workplace), фундаментом которого, в свою очередь, является инфраструктурное ПО: операционная система, служба каталогов и средства централизованного администрирования всеми компонентами рабочих мест, и это не полный перечень.

Teams победил не потому, что был идеальным, а потому что Windows, MS Office + Exchange и Active Directory де‑факто стандарт корпоративного мира.

В 1993-м, когда Microsoft выпускает заточенную под бизнес Windows NT 3.1 и начинает связывать операционную систему с офисным софтом в единый рабочий контур, или в 2000-м, когда вместе с Windows 2000 Server появилась Active Directory — тогда, на заре современного корпоративного ИТ, бизнес рос одновременно со слоем технологий. У компаний не было устоявшихся привычек, сформированной ИТ‑культуры и тяжелого цифрового наследия. Microsoft приходила на пустое поле и давала готовые ответы на вопросы, которые бизнес еще даже не успел сформулировать. Microsoft стала стандартом индустрии просто по праву первопроходца — «закрытый сад» строился органически, сверху донизу, на чистой цифровой целине.

В 2020-х годах повторить этот трюк в России — утопия. Рынок зрелый, заказчики искушенные и есть сразу несколько «претендентов на экосистемность», которые имеют принципиально разную «гравитацию» и блокируют экспансию друг друга на смежные уровни стека. Ввиду отсутствия явного перевеса в ресурсах и позиции, чтобы занять всю доску — они cцепятся в клинче и это будет надолго.

Группа Астра атакует «снизу вверх», она контролирует фундамент — операционную систему (Astra Linux) и службу каталогов (ALD Pro) и продвигает свои утилитарные коммуникационные сервисы (RuPost, WorksPad), создавая жесткую экосистемную привязку (Vendor Lock‑in). Если ты сидишь на их ОС, тебе «выгоднее и безопаснее» брать их софт. Яндекс и VK атакуют «сверху вниз» через экраны пользователей и отполированный продуктовый UX/UI (Почта, Мессенджеры, ВКС, Трекеры), доступные c любой базовой ОС. Астра не может ставить «палки в колеса» Яндекс и VK:** если Астра искусственно ограничит работу сервисов Яндекса или VK в своей операционной системе, коммерческий рынок её просто проклянет. Крупный бизнес выберет смену ОС, но сохранит привычные рабочие инструменты сотрудников. Яндекс и VK не могут обойтись без Астры: Астра контролирует реестры КИИ и госсектор. Любой серверный софт Яндекса или VK обязан безболезненно разворачиваться внутри Astra Linux и управляться через ALD Pro. Они вынуждены подчиняться правилам игры, которые диктует Астра на нижнем уровне. Это не просто конкуренция продуктов, это война за уровни контроля над инфраструктурой.

Независимые и более специализированные вендоры мессенджеров и ВКС «второго эшелона» (у которых стек поменьше) — TrueConf, IVA Technologies, Vinteo, Compass, Пачка, eXpress и др.) заслуживают отдельной главы в этой драме. Их судьба — классическая иллюстрация того, как чистый инженерный продукт зажимается тисками платформенных экосистем. Пик экстренного импортозамещения прошел. Рынок перенасытился, бюджеты заказчиков стабилизировались, и для независимых игроков наступил критический момент. Их динамику можно спрогнозировать через три жестких сценария.

Капсуляция в «Тяжелой Инженерии» (Кейс IVA, TrueConf, Vinteo)

Скрытый текст

Эти ребята выживают за счет того, что они отлично «держат» протоколы H.323/SIP, работают со стационарными аппаратными кодеками в переговорных (Cisco/Polycom) и умеют стабильно вещать на тысячи человек без задержек звука. У них нет своего полноценного повседневного мессенджера (то, что есть — часто утилитарно и неудобно) и нет офисного пакета. Чтобы их не сожрали, они вынуждены идти на интеграционный поклон к Астре. Именно поэтому IVA и TrueConf первыми побежали делать глубокие коннекторы в ALD Pro и RuPost. Они продают Астре свои «мускулы» (ВКС‑движок), получая взамен доступ к клиентам Астры. Это симбиоз выживания: Астра закрывает ими брешь в ВКС, а они прячутся за спиной инфраструктурного гиганта. При негативной динамике — выход в продажу одному из претендентов на экосистемное доминирование, или наоборот, вендору «железа».

ИТ‑отделы на аутсорсе у своих же якорных клиентов

Скрытый текст

Вендоры, которые успели закрепиться в закрытых контурах сверх‑крупных корпораций (РЖД, Росатом, Ростех), например eXpress, выживают в роли «цифровой крепости». Им не нужен массовый рынок. Они берут огромные деньги за кастомизацию под одного‑двух гигантов. Но это ловушка: их продукт становится настолько специфичным и перегруженным требованиями конкретной госкорпорации, что продать его кому‑то на открытом рынке становится сложно.

Смерть в сегменте SMB и поглощение (Кейс легких мессенджеров)

Скрытый текст

Небольшие, очень красивые и быстрые корпоративные мессенджеры (например, Compass, Пачка и аналоги) попали в самую жестокую зону воронки. Они пытались конкурировать за счет крутого UX (сделали «как в Slack, только лучше»). Но для коммерческого среднего и малого бизнеса Яндекс и VK предлагают свои мессенджеры практически бесплатно — бонусом в комплекте к корпоративной почте и облаку. Маленький вендор не может демпинговать бесконечно. Этих вендоров ждет либо банкротство, либо тихая продажа своих команд и наработок кому‑то из крупных игроков, из тех, что собирают свои супер‑аппы. У вендора, живущего только с продаж мессенджера, или ВКС минимальные шансы выдержать эту гонку.

Функционал у всех уже выровнялся. Уникальности в продуктах больше нет. На фоне экстремальной фрагментации и переизбытка игроков, борьбы за одних и тех же клиентов, преимущественно в ограниченном сегменте крупных коммерческих компаний (Enterprise) и госсекторе, который в ближайшее время подойдет к насыщению. Нас впереди ожидает вязкая толкотня в «красном океане», ценовые войны, слияния‑поглощения и внезапные альянсы.

Буквально месяц назад, стало известно, что VK Tech и Yandex B2B Tech обсуждают партнерство в решениях для бизнеса. Детали пока неизвестны. Возможно договорятся об интеграции ИИ моделей Яндекса в VK WorkSpace, возможно не только об этом, в любом случае, это интересная новость.

МТС. Джокер в колоде

МТС, пожалуй, самый непредсказуемый игрок в этом клинче, и его поведение может кардинально перетасовать всю колоду B2B‑рынка в ближайшие годы. По своему финансовому, технологическому и организационному ресурсу стоит МТС в одном ряду с Яндексом и VK. Но его текущая позиция в ИТ‑инфраструктуре (без своей ОС и полноценного офисного пакета) делает его позицию неустойчивой в этом сегменте. Возможно, МТС в обозримом времени осознает себя на распутье, выбирая из двух базовых сценариев.

Сценарий 1. «Агрессивная экспансия» (Купить то, чего не хватает)

Скрытый текст

Если МТС решит играть по‑взрослому и достраивать свой Walled Garden, ему жизненно необходимо закрыть брешь в инфраструктурном ПО и офисном стеке. Без этого «МТС Линк» так и останется просто хорошей надстройкой, которую, условные, «Астра и Яндекс» постепенно вытеснят на глубокую периферию.

Покупка Vinteo уже показала, что МТС умеет покупать технологических лидеров, чтобы закрывать свои инженерные дефициты.

Какие здесь могут быть идеи? Купить российскую операционную систему второго эшелона — например, «Ред Софт» (Ред ОС) или «Базальт СПО» (Alt Linux). Если МТС купит одного из них, они мгновенно получат свой инфраструктурный фундамент и службу каталогов. Купить, например «МойОфис», возможно, Kaspersky устал его нести. Cобрать очередной аналог Microsoft 365 и закрыть «Workspace‑петлю». Клинч станет еще крепче. Косты и неопределенности у МТС выше — эти бизнесы не в ДНК МТС.

Сценарий 2. «Фиксация» (Продать или закрыть)

Скрытый текст

Самый вероятный сценарий. Телеком‑гиганты исторически обладают специфической корпоративной культурой. Они легко загораются идеей «стать ИТ‑экосистемой», вливают туда миллиарды, но если продукт в течение 3–5 лет не выходит на операционную окупаемость или упирается в потолок рынка, топ‑менеджмент так же легко принимает решение зарезать проект или продать его конкурентам.

Почему МТС может выйти из игры? Если общая динамика рынка будет такой, как описано в этой статье — это уже причина. Или, например, МТС увидит, что затраты на R&D и содержание DevOps‑армии поддержки On‑Prem сжирают всю маржу от лицензий. «МТС Линк» как бизнес, с его огромной клиентской базой, с радостью купят те, кому не хватает зрелого ВКС/вебинарного движка. Даже можно будет выбирать среди потенциальных покупателей.

Для клиентов Сценарий 2 станет абсолютным кошмаром. Вы внедрили On‑Premise, потратили миллионы на интеграцию, а через два года вендор меняет стратегию, закрывает продукт или продает его структуре, с которой у вас нет контракта.

Кейс МойОфис. Похмелье после бума импортозамещения

Мы стоим на пороге жесткого похмелья после импортозамещающего бума. 2026-й и далее 2027–2028 заставят всех радикально приземлить свои инвестиционные ожидания. Период с 2022 по 2025 года был для российских вендоров «золотой лихорадкой», когда клиенты хватали любые отечественные решения просто потому, что нужно было срочно закрыть дыры после ухода западных гигантов.

Все, кто должен был испугаться, побежать и купить, уже испугались, побежали и купили. Рынок подошел к тупику экстенсивного роста и замедлению темпов: крупный бизнес и госсектор уже распределили основные бюджеты и выбрали базовые ИТ‑стеки.

Пересадить клиента, который только что потратил сотни миллионов на развертывание одной российской системы, на другую «чуть более качественную» практически невозможно. В отличие от Microsoft, Zoom и т.д, которые окупают свои R&D‑затраты миллиардными продажами по всему миру, российские вендоры заперты внутри локального рынка. Потолок выручки здесь ощутимо ближе. С завершением первой волны миграции, темпы роста выручки у всех очень серьезно просядут.

Ножницы OPEX разрушат иллюзии высокой маржинальности софтверного бизнеса. Выяснится, что On‑Premise импортозамещения максимально не похож на клондайк с высокой чистой рентабельностью. Рост затрат будет опережать доходы: индивидуальные внедрения, кастомная поддержка, «допиливания» софта, бесконечные интеграции.

Давление со стороны стоимости капитала есть уже и будет расти. В условиях текущих макроэкономических реалий (высокие процентные ставки, дорогой кредит) инвесторы будут все меньше готовы годами ждать «светлого будущего» и оценивать инициативы и стартапы по безумным мультипликаторам к выручке (P/S). Буквально завтра инвесторы перестанут давать деньги под обещания «мы заменим Microsoft/SAP/Zoom». Многим фаундерам придется пережить болезненный Downround (когда при следующем раунде инвестиций или оценке акционерами их компания будет стоить дешевле, чем год назад.

Наступает эпоха жесткого прагматизма. Рынок не прокормит десятки едва отличимых друг от друга изолированных мессенджеров, ВКС‑систем и операционок.

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

Эпитафия

25 марта 2025 года гендиректор «МойОфис» Вячеслав Закоржевский на пресс‑мероприятии рассказал, что «у компании уже есть много продуктов, отдельных „кубиков“, и теперь стоит задача свести это всё воедино, чтобы те, кто приобретает продукты „МойОфис“, могли получать бесшовное взаимодействие между всеми ними». Он также отметил, что «эта концепция развития идёт в тренде с развитием западного рынка офисного ПО, где этот сегмент называется productivity suite».

7 августа 2026 года Cnews сообщил, что в ООО «Новые облачные технологии», вендоре офисного пакета «МойОфис», реструктуризация, убытки и массовые увольнения.

В марте 2026 г. в компании числилось 1073 сотрудника (около 800 из них — разработчики, уверен, одни из лучших), к августу осталось около 250–270 человек. Компания закрывает свои офисы. Ведомости сообщают, что в 2025 г. выручка компании снизилась на 50% до 1 млрд руб., а чистый убыток достиг 8,82 млрд руб., увеличившись в 7 раз. Задолженность перед мажоритарным акционером выросла до 24,96 млрд руб., при этом с 2026 г. приостановлена разработка продуктов. Попытка «Лаборатории Касперского» (главный акционер) «залить деньгами» закрытую экосистему провалилась.

«МойОфис» бросил все силы на воплощение идеи «больше комбайн — больше успех»: офисный пакет + почтовый сервер Mailion + корпоративный мессенджер и платформу для видеоконференций Squadus. И это не все. Еще доска, схемы, даже BI аналитика. Задачи, проекты, заметки. И даже это не все. Взгляните на пустые квадратики. «И дальше мы будем эту линейку расширять и связывать друг с другом, так чтобы покупалось не одно решение, а сразу всё вместе с единым центром лицензирования, развёртывания и установки», объяснял Вячеслав Закоржевский.

Меня этот слайд 2025 года со стратегией «Мой офис» потрясает. Ребятам никто не сказал «горшочек не вари», или они не захотели услышать. Это не презентация развития — это настоящий посмертный эпикриз, составленный самим пациентом ещё при жизни.

«Мой офис», в строительстве своей закрытой экосистемы, естественно не был озабочен интероперабельностью с внешними сервисами, но и внутри собственных продуктов вызывает стойкое ощущение непростой задачи.

Но нас больше интересует судьба живых. Уже в 2023 год было более 10 тыс. корпоративных клиентов, более миллиона корпоративных пользователей «МойОфис». В том числе, ВТБ в 2022 году приобрел 100 тыс. лицензий «МойОфис», «Росатом» с 2020 по 2022 годы поэтапно закупил 100 тыс. лицензий.

Клиенты, которые успели развернуть у себя «МойОфис» оказались «заперты в мертвом саду».

On‑prem закрытых экосистем — концентрация рисков, вместо снижения

В 2022 году все увидели, доступ к SaaS функционалу может быть прекращен в любой момент. Вообще, риски использования зарубежных сервисов стали кристально ясны уже в 2014–2015 гг. c первыми блокировками (ИТ‑блокада Крыма). И естественно нет большой разницы, кто повлияет на непрерывность вашего бизнеса, местный вендор, или вендор зарубежный. Нет разницы, закрыл ли вендор продукт вообще, или конкретно для вас, из политических или из коммерческих соображений, «со зла» или «извини, так получилось».

И крупный, и малый бизнес требует On‑Premise не потому, что боятся утечек (облака Яндекса или VK защищены зачастую лучше, чем сервера среднего банка). Бизнес боится «рубильника».

Бизнес выбирает On‑Prem ради безопасности и независимости, но на практике получает не снижение, а концентрацию рисков. Клиент убегает от одной воронки зависимости (облачной), а прибегает в другую (инфраструктурную).

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

Владение дистрибутивом без владения исходным кодом — это владение кирпичом.

On‑Premise как защита от вендора — главная иллюзия. Физическое владение байтами на своих дисках не равно технологической независимости. Покупая On‑Premise закрытого софта, клиент думает, что застраховался от ситуации, когда вендор «выключит рубильник» в облаке. Да, софт останется на ваших серверах. Но без постоянного потока обновлений, патчей безопасности и адаптации под новые версии смежного стека (ОС, СУБД, браузеры), закрытый софт «превращается в тыкву» за 12–18 месяцев. Это не защита, а гарантия небольшой отсрочки исполнения приговора. Тоже неплохо, но давайте разберем, что идет «в пакете» с этой отсрочкой, поймем, хорошая ли это сделка.

Для крупного российского бизнеса, особенно на объектах КИИ, on‑premise стал стандартом по умолчанию. При этом современный программный стек рабочих мест критически усложнился как горизонтально, так и вертикально. Локального развертывания внутри периметра, со всеми технологическими зависимостями, теперь требуют все слои: от компонентов прикладного ПО и распределенных сервисов самих ОС до управляющей инфраструктуры (систем UEM/MDM, управления конфигурациями, мониторинга, контроля доступа и логирования)

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

Так рождается настоящий праздник эксплуатации для российского бизнеса.

Требование тотального On‑Premise умножается на мультиплатформенность и возводится в степень вендорских мутаций опен‑сорса, получаем «инфраструктурный взрыв» на стороне клиента: архитектурный оверхед, интеграционный кошмар и постоянный «налог на совместимость». И смерть DevOps‑инженеров на поддержке: «пришлите логи... нет, эти логи не те... а какая у вас версия Kafka? а почему у вас порты закрыты?».

Базовые открытые протоколы оказались фрагментированы и приватизированы. «Наш LDAP» перестал бесшовно понимать «их LDAP». Механизмы групповых политик у одного вендора «перпендикулярны» механизмам другого. Пакет прикладного софта, оптимизированный под одну закрытую экосистему, начинает сыпать ошибками при попытке развернуть его в инфраструктуре конкурента, или при обновлении «родной».

Давайте теперь взглянем на продуктивную среду Яндекс360 в конфигурации Small для небольших организаций до 2 000 пользователей и конфигурации Large до 10 000 пользователей. Предполагаю, требования еще подрастут: до конца 2026 года в on‑premises‑версии планируется запустить уже 11 сервисов, включая Мессенджер и Телемост.

Итак, что мы видим. Масштабирование в 4 раза при росте базы в 5 раз — это посредственный результат.

Выглядит так, будто разработчики не стали переписывать код под оптимизацию локальных мощностей, а просто развернули «как есть» в контуре заказчика облачный стек Яндекс 360, который изначально создавался как гигантский облачный B2C/B2B‑сервис (SaaS) для миллионов людей, оптимизированный под огромные дата‑центры.

Судя по требованиям, on‑prem версия — это буквальный слепок облачной архитектуры, упакованный в Kubernetes.

Скрытый текст

Если конфигурация Small заставляет приподнять брови в изумлении, то конфигурация Large на 10 000 пользователей наглядно демонстрирует линейный тупик масштабирования облачных микросервисов в локальном контуре (On‑Premise).

Эффект масштаба (Scale Effect) отсутствует. Огромный базовый оверхед (те самые 840 ГБ RAM на старте) должен был сработать как «фундамент». Можно было бы ожидать, что раз система уже со старта сожрала терабайт памяти под запуск сотен своих микросервисов, то новые пользователи будут просто утилизировать этот фундамент, но этого не происходит. Система продолжает требовать память и процессоры почти линейно (коэффициент 0.8 к росту аудитории).

Прирост RAM составляет 4.1 раза. Память тает на глазах. Это значит, что каждый новый пользователь, добавленный в систему после первых двух тысяч, обходится компании практически в те же 330 МБ оперативной памяти. Для веб‑сервисов совместной работы это огромный показатель. Архитектура не умеет эффективно переиспользовать кэши и сессии между пользователями.

Архитектура Яндекс 360 on‑premises требует колоссальных инвестиций в железо (вам потребуется около 3.5 ТБ оперативной памяти только под приложения на 10 000 человек), и сэкономить за счет эффекта масштаба практически не удастся.

Из закрытых «коробок» нельзя собрать эффективный корпоративный ландшафт.

Безусловно, кейс Яндекс 360 — это экстремальная точка. Яндекс исторически развивался как чистокровный, классический Hyperscale SaaS. Их софт рождался в условиях бесконечных ресурсов публичного облака, поэтому их On‑Premise “космолет” объективно самый тяжелый, прожорливый и сложный для приземления в локальный контур.

У других отечественных вендоров (будь то VK WorkSpace, МойОфис, eXpress или CommuniGate) “коробки” конструктивно поменьше, а системные требования — полегче. Но для корпоративного клиента итоговая беда абсолютно одна: из этих закрытых проприетарных коробок даже теоретически невозможно построить enterprise‑архитектуру с нормальной утилизацией аппаратных ресурсов.

Здравствуй множественный инфраструктурный налог (на автономию).

Каждая закрытая экосистема — эгоистичный «сад в себе». Она не умеет и не хочет делить ресурсы с соседями. В итоге, если вы покупаете три разные коробки от трех разных вендоров, вы платите тройной инфраструктурный налог. Каждая коробка притащит с собой собственный кластер баз данных, брокер сообщений, стек логирования и систему полнотекстового поиска. Вместо одного эффективного общекорпоративного кластера хранения и поиска, вы получаете три изолированных «зоопарка», которые параллельно и вхолостую жрут ядра и терабайты RAM.

Нулевой шеринг ресурсов (Zero Resource Sharing).

В закрытой проприетарной модели клиент не может «выковырять» из коробки вендора её внутренние компоненты. Вы не можете сказать продукту: «Слушай, у меня в КИИ уже развернут и идеально пропатчен отказоустойчивый кластер PostgreSQL/Kafka, используй его». Нет, вендор жестко завязан на свою специфичную (часто форкнутую) версию компонента. Из‑за этого ИТ‑департамент КИИ вынужден плодить микро‑инстансы СУБД и шин данных под каждую чих‑систему, размазывая CAPEX тонким слоем по неэффективным изолированным виртуалкам.

Пиковые запасы под каждую изоляцию.

Поскольку коробки закрыты и не общаются между собой на уровне планирования ресурсов, сайзинг каждой из них приходится закладывать «с запасом на худший день» по пиковой нагрузке. В итоге в масштабах корпорации тысячи ядер vCPU простаивают 90% времени просто потому, что проприетарный софт А не может отдать излишки мощности проприетарному софту Б в момент, когда у того идет тяжелая индексация.

Оцениваем Vendor Lock‑in корпоративных мессенджеров

В конце 2024 года был опубликован интересный фреймворк — Cloud Vendor Lock‑In Prediction Framework (CVL). Это модель, разработанная для прогнозирования величины риска вендор‑лока. 

В чем смысл. В классическом TPRM (Third‑Party & Vendor Risk Management Framework) вендоров оценивают по «статическим» рискам (кибербез, финансы, комплаенс). Такие проверки показывают надежность партнера только в момент аудита. Классический VRM делит управление рисками на фазы: Due Diligence и Onboarding (Входной аудит), Continuous Monitoring (Непрерывный мониторинг) и Offboarding & Exit Strategy (Стратегия выхода).

Cloud Vendor Lock‑In Prediction Framework (CVL), как прогнозная модель, позволяет уточнить чек‑листы на этапе Due Diligence и Onboarding (Входной аудит) и яснее учитывать вендор‑лок. И кроме того, помогает яснее формулировать Offboarding & Exit Strategy (Стратегию выхода) — традиционно самый провальный пункт в ИТ‑картах рисков.

Компании редко закладывают стоимость «развода» с вендором в момент покупки. Хотя, казалось бы, «Прежде чем входить, подумай о том, как ты выйдешь…». Известное житейское правило.

Модель CVL оценивает вендор‑лок через Индекс Зависимости (Dependency Score). Он складывается из весов нескольких факторов. Чем выше итоговый балл, тем сильнее компания заперта в «клетке» вендора.

Попробуем рассчитать вендор‑лок по модели CVL для корпоративных мессенджеров. Я свел известные мне корпоративные мессенджеры в несколько ключевых групп по типам развертывания и открытости/закрытости кода, тем параметрам, что интересуют нас в контексте Vendor Lock. Интересует именно типизация, а не сравнение всех существующих мессенджеров.

Тип 1. Закрытый SaaS
Тип 2a. On‑Prem (Закрытый код)
Тип 2b. On‑Prem + Эскроу
Тип 3. On‑Prem Open‑Core
Тип 4a. On‑Prem Open‑Core на открытом протоколе (Matrix)
Тип 4b. SaaS Open‑Core на открытом протоколе (Matrix)

Авторы фреймворка отмечают, что в нем присутствует высокая чувствительность к субъективному выбору весов. Сложно не согласиться. Поэтому, предложения и комментарии по оценке факторов горячо приветствую, будет интересно получить 𝐷𝑒𝑝𝑒𝑛𝑑𝑒𝑛𝑐𝑦 𝑆𝑐𝑜𝑟𝑒 уточненный и верифицированный сообществом Хабр.

Формула из CVL:

где

вес, присвоенный фактору (от 0 до 1), отражающий его важность.

нормализованная оценка фактора провайдера (от 0 до 1), текущий уровень привязки.

Dependency Score (CVL) для корпоративных мессенджеров (v 1.0)

Зависимости клиентских приложений от вендора мессенджера и от вендора ОС учтены в оценке фактора TL. Зависимости Push‑уведомлений, критическая часть в доступности сервиса, учтена в SL. Интеграции и боты учтены в EL.

Закрытый SaaS — просто полная зависимость. Жизнь в шаге от блокировки по какой‑нибудь внезапной причине в рандомный четверг. Добавить нечего.

Корпоративный мессенджер с закрытым исходным кодом, развернутый On‑Prem (2a/2b) защищает компанию только на уровне хранения данных.

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

Скрытый текст

Мы видим минимальный разрыв Эскроу (Тип 2b) с решением без эскроу (2a) — всего 0.05. Оба не защищают от большинства реалистичных рисков (снижение темпов развития, ухудшение техподдержки), то есть не от смерти вендора или закрытия продукта, а именно от деградации вендора, или его продукта. И при этом, если вендор умрет или закроет продукт, «мертвый» код сервера из эскроу не оживит мобильные пуши и не предотвратит затраты на интеграции и адаптацию ботов на проприетарном API. Плюс сложности с обновлением мобильных приложений в публичных сторах. Вы не сможете оперативно пересобрать и переопубликовать мобильные приложения в App Store/Google Play. Разбор не‑Open‑Source кода силами ваших инженеров почти гарантированный кошмар.

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

Главная проблема традиционных закрытых On‑Premise мессенджеров в том, что они представляют собой монолитные вертикально‑интегрированные экосистемы (proprietary end‑to‑end stacks). С точки зрения управления рисками третьих сторон (VRM) — это не снижение рисков, а их концентрация.

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

Интерфейс «намертво» прибит к серверу: Вы не можете взять сторонний open‑source клиент и подключить его к этому On‑Premise серверу. Если официальное приложение вендора для iOS/Android морально устарело, криво обновляется или вылетело из сторов — ваши пользователи остаются без связи. Заменить клиентское приложение аналогом невозможно.

Инфраструктурная монополия: Сервисные компоненты (вроде шлюзов Push‑уведомлений или модулей кастомизации интерфейса) вшиты в проприетарное ядро. Вы не можете «выковырять» модуль пушей и заменить его на собственный независимый сервис, если шлюзы вендора начнут сбоить или попадут под санкции.

В итоге получается парадокс: данные лежат на ваших серверах, но вся экосистема вокруг них полностью монополизирована вендором. Стоит «выбить» из этой вертикальной цепочки хотя бы одно звено (например, доставку пушей или дистрибуцию мобильных приложений) — и вся On‑Premise крепость превращается в тыкву, потому что ни один компонент системы не умеет работать независимо от создавшего его вендора.

Тип 3. On‑Prem Open‑Core — вариант, если исключить из рассмотрения Matrix. За счет того, что базовый API и ядро кода открыты, API обычно стандартизированный, риски по клиентам, ботам и пушам остаются под вашим контролем. Поддержка кода сообществом дарит надежду, что не произойдет остановки в развитии функционала, исправлениях, и что вы сможете в разумные сроки найти кого‑то кто понимает как эта штука устроена. Клиентские приложения можно кастомизировать, но Push‑уведомления часто требуют использования официального прокси‑сервера вендора (хотя у Mattermost, например, есть инструкции по сборке собственного Push‑шлюза, это требует усилий).

Наиболее защищенными от вендор‑лока архитектурами являются Тип 4a и Тип 4b, которые за счет открытых интерфейсов лишают вендора монополии на экосистему. Стоимость и риски выхода стремятся к нулю.

Тип 4a. On‑Prem Open‑Core на открытом протоколе (Matrix)
Полная стабильность. Открытый и децентрализованный протокол изначально проектировался так, чтобы боты, мобильные приложения и Push‑сервера (через стандарты типа UnifiedPush) могли заменяться как детали конструктора без участия конкретного коммерческого вендора.

Тип 4b. SaaS Open‑Core на открытом протоколе (Matrix)
Поскольку протокол открытый, все ваши внутренние боты и интеграции пишутся под стандартный API. Если облачный вендор начинает завышать цены или плохо отвечать в тикетах, вы можете переключить ваших ботов и те же самые клиентские приложения сотрудников на любой другой сервер этого протокола за считанные часы. Зависимость по Push‑уведомлениям остается умеренной, так как облако берет их на себя, но архитектурного тупика здесь нет. По сути, SaaS на открытом протоколе позволяет переложить головную боль с Push‑уведомлениями и хостингом на вендора, но при этом защищает компанию от кабалы проприетарных ботов и интеграций.

Матрица VRM‑рисков для мессенджеров

Переход на Matrix снижает расчетный показатель зависимости до минимальных значений, так как вы больше не привязаны ни к вендору, ни к конкретному клиенту — только к открытому протоколу.

Отрицательный RnD импортозамещения

Это простая история. Вендоры реализуют и продвигают архитектуру решений, полезную для своих закрытых экосистем. Их «голубая мечта» — создать максимально устойчивый, неизвлекаемый вендор‑лок и собирать с этого ежегодную ренту.

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

В классическом понимании R&D (Research and Development) — это инвестиции в создание принципиально новых технологий, оптимизацию процессов и повышение эффективности для завоевания рынков. Отрицательный R&D работает с точностью до наоборот.

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

С точки зрения экономики, классический R&D снижает TCO (стоимость владения) для клиента, а для разработчика повышает маржинальность. Отрицательный R&D импортозамещения заставляет клиента платить трижды: за лицензии, за монструозное железо под приземленный SaaS и за ФОТ DevOps‑команды, которая должна этот зоопарк администрировать. Деньги уходят не в развитие, а на удержание системы от коллапса.

R&D компаний вместо создания уникальных цифровых продуктов для своего бизнеса (финтех‑сервисов, систем предиктивной аналитики, систем управления) утилизируется на «налог на интеграцию», на починку стыков.

Этап «пожарного импортозамещения» (2022–2025 гг.) был эпохой тактических решений («заткнуть дыры», «купить хоть что‑то, что работает на Linux», «быстро развернуть On‑Premise копию»). В этой суматохе компании накупили лоскутное одеяло из не связанных друг с другом продуктов, повторив ошибки жесткой привязки, но уже к новым локальным вендорам. Сейчас, в 2026 году, наступает этап стратегического осмысления.

TOGAF (The Open Group Architecture Framework) — главный методический инструмент защиты бизнеса от вендорского диктата и деградации ИТ инфраструктуры и роста связанных с этим операционных рисков и барьеров для бизнеса.

Архитектура должна принадлежать клиенту, а не вендору и фреймворк TOGAF помогает корпоративному сектору забрать контроль над своей инфраструктурой обратно на всех слоях (доменах BDAT): Business (Бизнес), Data (Данные), Application (Приложения) и Technology (Технологии).

С точки зрения TOGAF, решения, которые продуктовые директора вендоров навязывают рынку — архитектурное варварство и разрушение ландшафта заказчика. Это мина замедленного действия под операционную устойчивость корпоративного сегмента, в том числе КИИ. Приверженцы коммерческой доктрины «вендорских комбайнов» (All‑in‑One) и закрытых экосистем заставляют свои команды тратить дефицитный R&D на возведение искусственных стен, вместо создания открытых шлюзов.

TOGAF, напротив, заставляет компанию, во‑первых, опираясь на открытые архитектуры и стандарты, в первую очередь интероперабельности, выстраивать суверенную, модульную, слабосвязанную (Loose Coupling) и легко масштабируемую архитектуру, где данные отчуждаемы, компоненты заменяемы. Во‑вторых, проводить постоянный аудит рисков зависимости и стратегии выхода с продукта до того, как его приобрести и развернуть у себя.

Это единственный эволюционный путь, который спасает Enterprise от инфраструктурного взрыва и удушающих костов проприетарного вендор‑лока.

В циклы TOGAF, в качестве специализированного слоя информационной безопасности и управления рисками, бесшовно интегрируется методология SABSA (Sherwood Applied Business Security Architecture), разработанная в 1995 году тремя британскими экспертами в области кибербезопасности: Джоном Шервудом (John Sherwood), Дэвидом Лайнасом (David Lynas) и Эндрю Кларком (Andrew Clark). 

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

В документе Integrating Risk and Security within a TOGAF® Enterprise Architecture приводится официальная сетка бизнес‑требований. Согласно методологии совместного применения TOGAF 10 и SABSA (на этапах Phase A / Requirements Management), любой элемент цифрового рабочего места должен оцениваться через матрицу SABSA Business Attribute Profile. В контексте современных коммуникаций двумя ключевых стратегическими атрибутами становятся Interoperable (Совместимый) и Architecturally Open (Архитектурно открытый).

«Изолированность в себе» российских корпоративных мессенджеров бьет по кросс‑корпоративным коммуникациям. Как мы разобрали ранее, изолированный мессенджер гарантированно проигрывает открытым платформам (например, Telegram) согласно закону Меткалфа о ценности сетей. Подобные «Walled Garden» мессенджеры прямо порождают риски теневого ИТ (Shadow IT). TOGAF 10 в Фазе B (Business Architecture) прямо указывает: если корпорация работает в экосистеме партнеров и подрядчиков, она обязана спроектировать Федерацию безопасности (Security Federation) для обеспечения доверенной сквозной коммуникации«.»

В разделе Phase B: Business Architecture официально закреплены понятия Security Federation (Безопасная федерация) и Trust Framework (Матрица доверия). Документ прямо указывает: если бизнес‑модель организации подразумевает интеграцию с внешним миром (подрядчики, клиенты, партнеры), «масштаб безопасности и федерации должен быть определен на этом этапе». Более того, TOGAF подчеркивает, что технология (например, закрытые сертификаты вендора) не создает доверие — его создают совместные соглашения и консистентность политик безопасности.

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

Phase B (Business Architecture) отвечает на вопрос: «Как бизнес зарабатывает деньги и с кем он взаимодействует?». Если бизнес‑модель компании включает внешних партнеров, то границы организации (Security Perimeter) размываются. То есть речь про любую компанию. Я не смог представить бизнес‑модель компании без внешних партнеров. И если отложить проектирование Security Federation до технологических этапов (Phase D/E/F), вы получите классическую ошибку: ИТ‑отдел развернет изолированный «мессенджер‑крепость», который бизнес не сможет использовать для работы с партнерами. Бизнес‑процесс сломается, и сотрудники уйдут в Shadow IT. Что и происходит сегодня.

То, что коммерческие тайны уходят в облако Дурова, это не баг, а фича архитектуры отечественных изолированных мессенджеров. В терминах Enterprise Risk Management (ERM / ISO 31000) и методологии TOGAF 10 этот феномен называется «архитектурно детерминированным риском». То есть система спроектирована так, что она физически не может функционировать иначе, кроме как выталкивая пользователей наружу.

Мы уже обсудили, что устойчивость инфраструктуры — забота исключительно клиента. Рынок бежал от облачного вендор‑лока и прибежал в локальный инфраструктурный лок.

Что говорит TOGAF 10: Руководство по безопасности прямо критикует классический ИТ‑подход: «Долгое время безопасность считалась изолированной дисциплиной... Риск‑менеджмент в старом TOGAF фокусировался только на рисках ИТ‑проекта. Это слишком узко». TOGAF 10 вводит Enterprise Risk Management (ERM) по стандарту ISO 31000, который оценивает Operational Risk (Операционный риск) — риски, с которыми бизнес сталкивается в ежедневной деятельности из‑за архитектурных решений. 

Переход от узкого «риска ИТ‑проекта» к стратегическому Enterprise Risk Management (ERM) — это визитная карточка TOGAF 10-й серии. Теперь архитектор обязан оценивать риски Run‑стадии (повседневной эксплуатации) еще на этапе проектирования. Неправильное архитектурное решение создает постоянный, хронический операционный риск для бизнеса на годы вперед.

Внедрение Walled Garden от отечественного вендора создает критический операционный риск внезапной остановки процессов при изменении политики вендора или падении его монолита.

Согласно Phase H (Architecture Change Management), если изменяется внешняя среда или обнаруживается уязвимость зависимости, Архитектурный комитет компании на основе ERM обязан инициировать новый цикл трансформации ландшафта.

Мы много говорили про блокировки, про «рубильник». Но риск операционной неэффективности и роста TCO вследствие технической деградации Vendor Lock‑in инфраструктуры даст последствия, растянутые по времени, но едва ли не более тяжелые.

Риск технической деградации вендор‑лок инфраструктуры комплексная угроза. В соответствии с методологией TOGAF 10 и стандартом управления рисками организации ERM (ISO 31000), этот риск необходимо классифицировать сразу на двух уровнях: стратегическом (для бизнеса) и архитектурном (для ИТ‑архитектуры).

На уровне Enterprise Risk Management (ERM / ISO 31000)

В общекорпоративном реестре рисков этот кейс относится к категории Операционных рисков (Operational Risks), а конкретнее — к двум его подкатегориям:

• Риск потери технологической гибкости и непрерывности бизнеса (Business Agility & Continuity Risk): Закрытая инфраструктура со временем теряет способность адаптироваться к изменениям рынка. Если вендор перестает развивать продукт, внедрять новые протоколы безопасности или поддерживать интеграцию с современными ОС, бизнес‑процессы компании начинают замедляться и деградировать.

• Риск изменения совокупной стоимости владения (TCO Escalation Risk): Техническая деградация означает, что поддержание системы в рабочем состоянии (поиск редких специалистов, написание «костылей», покупка завышенной техподдержки у монопольного вендора) будет стоить экспоненциально дороже с каждым годом.

На уровне архитектурных слоев TOGAF 10, в рамках разработки архитектуры предприятия (Architecture Development Method — ADM) этот риск распределяется по трем фазам:

• Phase B (Business Architecture): Риск неэффективности операционной модели. Бизнес‑экосистема компании (партнеры, клиенты) уходит вперед, используя новые открытые стандарты, а деградирующая внутренняя платформа не позволяет компании бесшовно с ними взаимодействовать.

• Phase C (Information Systems Architecture): Риск деградации приложений и данных. Устаревание проприетарных моделей данных, невозможность построения современных API, потеря совместимости с новыми корпоративными системами (CRM, ERP).

• Phase D (Technology Architecture): Риск инфраструктурного устаревания. Невозможность масштабирования, жесткая привязка к устаревшим версиям СУБД или операционных систем, которые сам вендор уже не обновляет.

Скрытый текст

В матрице SABSA Business Attribute Profile техническая деградация жестко бьет по следующим бизнес‑метрикам, переводя их в статус «критическая угроза»:

• Архитектурная открытость: показатель падает до нуля.

• Интероперабельность: риск потери совместимости с внешним миром.

• Пригодность к обслуживанию и устойчивость: риск невозможности поддерживать систему в долгосрочной перспективе силами собственной команды.

Давайте разберем отечественный воркспейс через призму четырех доменов TOGAF.

На уровне бизнес‑архитектуры (Business Architecture), по TOGAF Бизнес‑требования должны диктовать автономию процессов. Монополия одной экосистемы внутри бизнеса — это стратегический риск единой точки отказа. Вендор продает функции, клиенту нужны непрерывные процессы.

• Вендорская логика: Предложить бизнесу «готовый цифровой день сотрудника». Из мессенджера можно запустить ВКС, из ВКС — открыть документ в облаке, из календаря — назначить встречу. Это удобно для пользователя («UX‑монолит»).

• Для корпорации «Коммуникации» — это критическая бизнес‑возможность (термин, которым оперирует TOGAF), которая не должна зависеть от капризов одного поставщика. Walled Garden создает риск: если у вендора падает или радикально меняется один элемент (например, почта), у бизнеса парализуются смежные процессы (например, документооборот).

На уровне архитектуры данных, по TOGAF, корпоративный воркспейс обязан иметь открытую модель данных и документированные механизмы отчуждения данных. Корпорация должна иметь возможность в любой момент «выгрузить всё» без потери связей. Следуя вендорской логике, клиент вряд ли однажды получит «Данные как корпоративный актив».

• Вендорская логика: Хранить историю чатов, записи ВКС, файлы и письма внутри своей СУБД, часто зашифрованной или закрытой для прямого внешнего аудита, чтобы «обеспечить безопасность внутри контура».

• Взгляд по TOGAF: Нарушается фундаментальный принцип Data Independence и Shared Data. Данные принадлежат корпорации, а не мессенджеру. Извлечь терабайты переписки, метаданных и вложений из закрытого отечественного мессенджера для передачи, например, в корпоративную систему ИБ (DLP, SIEM) или в аналитическое хранилище (DWH) — часто превращается в кошмар.

На уровне архитектуры приложений (Application Architecture), приложения воркспейса должны общаться между собой через жестко регламентированные, открытые API. Попытки вендоров делать «скрытые» внутренние интеграции, недоступные для сторонних разработчиков, должны блокироваться архитектурным комитетом заказчика. Компоненты инфраструктуры рабочих мест должны обладать слабой связанностью (Loose Coupling), а не быть монолитной экосистемой.

• Вендорская логика: «Наш мессенджер идеально работает только с нашей почтой и нашим диском». Вендоры сознательно урезают функционал интеграций с внешними решениями, чтобы клиент покупал весь пакет целиком.

• Это прямое нарушение принципов интероперабельности и модульности. Согласно TOGAF, компоненты должны быть взаимозаменяемы. Если завтра корпорации разонравится встроенный офисный пакет вендора, она должна иметь возможность бесшовно «выщелкнуть» его из экосистемы и «вставить» другой, сохранив мессенджер и календарь.

В технологической архитектуре (Technology Architecture) у нас сейчас вендорский диктат инфраструктуры. Но по TOGAF платформенные службы воркспейса должны соответствовать Technical Reference Model (TRM) заказчика. Они обязаны переиспользовать уже существующие в корпорации службы (единый IAM/IDP для авторизации, корпоративный S3 для хранения, общую систему логирования), а не притаскивать свои дублирующие компоненты.

Инфраструктура должна быть эффективной и масштабируемой. Когда клиент вынужден разворачивать под один корпоративный мессенджер целую инфраструктурную «Вселенную» со своими балансировщиками, логированием и мониторингом (которые не интегрируются с общекорпоративным Zabbix/Prometheus), эффективность падает до нуля.

TOGAF TRM (Technical Reference Model) требует выделять унифицированные платформенные службы (Platform Services), которые стоят между «железом/ОС» и «бизнес‑приложениями». Платформенные службы должны быть ОС‑агностическими (независимыми от операционки). Push‑уведомления, корпоративные магазины или MDM/UEM должны предоставлять сервисы через универсальные API, а не быть зашитыми внутрь проприетарного стека вендора ОС.

То, что делает рынок (строит инфраструктуру под каждую ОС отдельно) — это сильная связанность (Tight Coupling). Приложения и обеспечивающие сервисы намертво привязываются к конкретной операционной системе.

По TRM инфраструктура эффективна, когда исключено дублирование. Сейчас на рынке происходит тотальное узаконенное дублирование.

Matrix. Паровозик, который смог

Мы опять возвращаемся в 2013 год. Мэттью Ходжсон и Амандин Ле Пап создают первый набросок Matrix. 

Если Threema — редкий пример стабильного развития на собственные средства, а Wire — проект с «золотым билетом» от сооснователя Skype Януса Фрииса, то Matrix прошел через яркую драму. Threema и Wire создавались как классические продукты — приложения, обещающие безопасность и контроль. Matrix сразу создавался не просто как приложение или коммерческий сервис, а как открытый, бесплатный общественный протокол: как SMTP или HTTP, но для мгновенных сообщений.

Threema сразу вышла как платное приложение. Пользователи покупали его в App Store/Google Play за пару долларов. Доход полностью покрывал разработку, сервера и зарплаты. Им просто не нужны были внешние инвесторы первые 8 лет существования. Только в 2020 году, когда потребовалось масштабироватьcя на государственный и корпоративный сектор (Threema Work), основатели без спешки продали долю немецко‑швейцарскому фонду Afinum. А в январе 2026 года они так же планово и спокойно перешли под управление франкфуртской Comitis Capital. 

Инженерам Wire тоже не приходилось собирать донаты на зарплаты — у них было стабильное и щедрое венчурное финансирование с первого дня. Когда личных денег Януса Фрииса стало не хватать для глобальной экспансии, привлекли крупные раунды от сторонних фондов (например, €24 млн в Series C). Единственная мини‑драма Wire была чисто репутационной, когда в 2019 году они перенесли холдинг в США (вот это поворот) ради американских B2B‑клиентов, что привело в изумление клиентов в ЕС.

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

Это архитектурный ад на старте и отложенная в неопределенное будущее монетизация. Бесплатный протокол невозможно продавать пользователям (как Threema). В него сложно привлекать классических венчурных инвесторов на ранних этапах, так как код принадлежит всему миру. Именно поэтому, когда якорный спонсор (Amdocs) внезапно ушел, Matrix оказался на грани закрытия, его спасали сначала пожертвования обычных людей, а затем, в самый критический момент в январе 2018 года, грант в $5 млн от Status.im. 

Грант позволил разработчикам Matrix сохранить команду, расширить штат, а затем, в том же 2018 году, Межминистерское цифровое управление Франции (тогда DINSIC, сейчас DINUM) обратилось к разработчикам Matrix для создания суверенной, децентрализованной сети для госслужащих. Целью был полный отказ чиновников от использования WhatsApp* и Telegram в служебных целях. В 2019-м году создан Фонд Matrix.org Foundation и протокол Matrix юридически отделяется от коммерческого создателя — компании Element (New Vector Ltd). Уже в апреле 2019 года приложение, получившее название Tchap, было официально запущено во всех министерствах и ведомствах страны (более 600 000 чиновников и министров). В 2025 году цифровое ведомство Франции (DINUM) официально вступило в Matrix.org Foundation, став первым в мире государственным органом в составе этой организации. 

В 2024 году Международный вычислительный центр ООН (UNICC), отвечающий за цифровые технологии и кибербезопасность внутри организации, заключил официальное соглашение с компанией Element (основным разработчиком софта на базе Matrix). Платформа была внедрена по подписке Element Enterprise, как безопасная альтернатива электронной почте и коммерческим мессенджерам для внутренней связи между агентствами ООН.

Германское национальное агентство цифровой медицины gematik использует Matrix для безопасного общения миллионов врачей, аптек и страховых компаний по всей стране, а Бундесвер разворачивает BwMessenger. Брюссель (Еврокомиссия) официально тестирует Matrix как суверенную замену Microsoft Teams для резервной и защищенной внутренней коммуникации.

Швеция выбрала подход, который раскрывает главную фишку Matrix — децентрализованную федерацию. Вместо того чтобы заставлять всех госслужащих устанавливать одно конкретное приложение, шведская правительственная сеть eSam (включающая более 40 государственных ведомств) утвердила Matrix как единый стандарт связи для обеспечения цифрового суверенитета. Это позволило разным ведомствам использовать софт от разных поставщиков, но общаться друг с другом напрямую. Так, Агентство социального страхования (Försäkringskassan) развернуло защищенный чат на базе клиента Element (проект называется SAFOS Chatt), а транспортная администрация (Trafikverket) использует мессенджер Rocket.Chat. 

Скрытый текст

Status.im (Status Network) широко известен в блокчейн‑индустрии как один из старейших и наиболее идеологически последовательных разработчиков инфраструктуры для Ethereum и децентрализованного веба (Web3). Его спасительный для Matrix грант обычно называют идеологическим. И это конечно тоже. А еще, Франции, Британии и в целом ЕС срочно требовался готовый, криптографически защищенный, федеративный (децентрализованный) протокол, способный обеспечить цифровую независимость от Вашингтона. Matrix подходил идеально, но умирал без денег. Status.im — проект, находящийся в нейтральной Швейцарии, обладающий огромной «серой» подушкой ликвидности в криптовалюте после ICO, чьи идеи криптоанархизма и борьбы с американским надзором идеально совпадали с задачей. Matrix — открытый проект. Государство не может прямо спонсировать open‑source протокол общего назначения, который затем будут использовать гражданские лица по всему миру.

На сегодня, пул акционеров Element (New Vector Ltd, Великобритания) расширился, но в нем нет классических фондов Кремниевой долины — капитал компании собран преимущественно из европейских SaaS‑инвесторов и идеологов Web3. Это компании, которые инвестировали крупные суммы не просто ради финансовой выгоды, а из‑за совпадения идеологий децентрализации интернета. Ряд европейских венчурных технологических фондов зашли в капитал на этапах Seed и Series A: британский Notion Capital, созданный экспертами в области безопасной облачной почты, Dawn Capital — один из крупнейших в Европе специализированных SaaS‑фондов и Firstminute Capital. В качестве стратегических инвесторов выступила владеющая WordPress.com, Tumblr и WooCommerce Automattic Inc., которая влила в $4.6 млн, Protocol Labs, а также в 2021 году и Metaplanet — инвестиционный фонд Яана Таллинна (Jaan Tallinn), еще одного из сооснователей Skype.

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

В разных странах мира прямо сейчас бизнес и чиновники, выбирают между двумя вариантами: или исключить vendor‑lock как таковой и выбрать одно из решений на открытом протоколе Matrix, или заменить vendor‑риск глобального (как правило, американского) BigTech на vendor‑риск местного вендора. Threema и Wire — местные только для немцев, германо‑швейцарский vendor‑lock анклав Threema и Wire еще существует и возможно продолжит, но, что характерно, даже в гос.органах Германии не удержал эксклюзивности.

Фонд Matrix.org в октябре 2025 объявил о 190 миллионов пользователей всех решений в открытой федерации на протоколе Matrix (Element и др.)

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

С 2023 года в ЕС начали на практике применяться правила Закона о цифровых рынках (Digital Markets Act). Статья 7 DMA детально прописывает правила сквозной совместимости (интероперабельности) систем обмена сообщениями. 

Гейткиперы (WhatsApp* и Facebook* Messenger) обязаны по запросу сторонних разработчиков бесплатно настроить технические интерфейсы (API). Это позволяет пользователю условного Signal или Element написать пользователю WhatsApp*, не скачивая сам WhatsApp*. 

Телеграм пока не признан гейткипером и открываться сторонним сервисам не обязан, для этого требуется более 45 миллионов активных пользователей в Европе в месяц, Telegram декларирует чуть более 40 миллионов. Пока не признан.

Microsoft Teams тоже не включен в список регулируемых сервисов обмена сообщениями (CPS) в рамках Закона о цифровых рынках (DMA), но столкнулся с жестким антимонопольным расследованием ЕС по итогам которого в 2025 году обязался незамедлительно и в полном объеме выполнить обязательства интероперабельности и переносимости данных. Если Microsoft не выполнит свои обязательства, ЕС может наложить штраф до 10% от ее годового глобального оборота.

В конце 2022 года — начале 2023 года стартовал MIMI (More Instant Messaging Interoperability) в рамках IETF (Инженерного совета Интернета), чтобы создать единый открытый стандарт, который позволит пользователям разных мессенджеров безопасно общаться друг с другом напрямую.

Интероперабельность — идеология и смысл протокола Matrix. Он используется в рамках MIMI как готовый фреймворк. Вместо того чтобы придумывать обмен сообщениями с нуля, рабочая группа заимствует проверенные временем HTTP/JSON API и событийно‑ориентированную модель комнат Matrix. 

Когда IETF утвердит стандарты MIMI на базе наработок Matrix, это будет означать, что экосистема Matrix фактически станет индустриальным стандартом для объединения мирового рынка обмена сообщениями.

За кулисами этого благородного процесса сейчас разворачивается своя жесткая корпоративная дипломатия и техническая драма. Big Tech (Meta*, Google, Apple). Эти компании изначально не хотели никакой совместимости. Под давлением закона ЕС они пришли в IETF с позицией: «ладно, мы сделаем интерком, но стандарт должен быть максимально простым, линейным и не ломать наши текущие закрытые архитектуры». Классический Matrix использует для синхронизации комнат сложную структуру — направленный ациклический граф (DAG). Для MIMI это посчитали избыточным. В контексте рабочей группы разрабатывается спецификация Linearized Matrix. Она упрощает историю комнаты до линейной цепочки событий, что облегчает интеграцию для крупных коммерческих игроков.

На хакатонах IETF (в частности, на IETF 117 летом 2023 года) развернулась настоящая инженерная драма. Команда Matrix (Element) и инженеры Google объединились, чтобы доказать жизнеспособность Linearized Matrix. Они прилюдно заставили приложение Google общаться с сервером Matrix через новый протокол. Это был сильный политический жест в сторону Meta* (WhatsApp*), показывающий: «Смотрите, крупнейшая ОС в мире уже тестирует протокол на базе Matrix, вам придется подчиниться».

Европейские операторы (Orange, Vodafone), поддерживают MIMI/Matrix, чтобы вернуть себе рынок корпоративных коммуникаций, утерянный в пользу Big Tech. Google вступил в игру, чтобы потеснить Microsoft.

Скрытый текст

В Индии, крупнейшем рынке для WhatsApp в мире (более 500 млн пользователей), местный регулятор CCI (Центральная комиссия по конкуренции) внимательно следит за европейским опытом. Индийские власти уже используют conditional immunity (условный иммунитет): если платформа хочет работать в стране, она должна выполнять требования по прозрачности данных и интеграции. Индия активно подталкивает Meta к тому, чтобы европейские стандарты совместимости чатов были раскатаны и на индийский рынок, предотвращая монополию одной компании на цифровую жизнь граждан.

Бразильский антимонопольный регулятор CADE уже координирует свои шаги с европейцами и требуют от Meta, чтобы бизнес‑инструменты мессенджеров (WhatsApp Business) были открыты для интеграции локальных CRM‑систем и сторонних чат‑ботов, блокируя любые попытки Meta создать «закрытый контур» для коммерции.

WeChat, главный китайский мессенджер и «супер‑апп» был настолько закрытым, что внутри него нельзя было даже отправлять ссылки на конкурирующие сервисы (например, Alibaba). Китайский регулятор (Министерство промышленности и информатизации — MIIT) жестко прекратил эту практику, законодательно запретив блокировку внешних ссылок внутри мессенджеров. Государство обязало WeChat и другие платформы обеспечить сквозную совместимость, чтобы пользователь мог беспрепятственно переходить на любые внешние сервисы прямо из чата. Возможно первый шаг.

Мы подошли к очередной смене эпох, которая происходит раз в 20 лет: проприетарные протоколы сменяются открытыми, открытые проприетарными. И вот снова, пришло время открытых протоколов и архитектуры.

Каждая такая перемена — это шаг вперед, и это хорошо. Протокол SMS был открытым, но устаревшим. Поэтому проиграл. Какие‑то принципиально новые end‑to‑end функциональные сценарии конечно быстрее и проще реализовать в рамках одной компании, одного проприетарного решения. Естественно желать монетизировать свои разработки, естественно желать стабильного расширения своей позиции и выручки. Сейчас устарели проприетарные изолированные в себе мессенджеры, и публичные и корпоративные. Эта эпоха прошла. Речь не только про мессенджеры конечно, вообще про стек цифровых рабочих мест и личного пространства продуктивности.

Суверенная архитектура предприятия и рабочая среда без границ

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

Я без всякой иронии хочу поздравить российские инженерные команды: вы создали реально работающую альтернативу западному софту по всему стеку инфраструктуры рабочих мест. Да, замена получилась дорогой, неудобной и концептуально устаревшей. Но, реально работающей. В такие сроки — это колоссальное достижение и это максимум, что можно выжать из тупиковой парадигмы «закрытых коробок».

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

Мы воспроизвели архитектуру, какой она была последние 20 лет. Теперь нам нужно идти дальше, создать архитектуру рабочих мест, какой она должна быть следующие 20: с принципиально новым уровнем безопасности и гибкости.

Я начал статью с цитаты из Cnews про «...превращение мессенджера в операционную среду сотрудника..».

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

Мы выходим на принцип «рабочее место как абстрактная точка доступа», лишенная критических зависимостей от конкретных программных решений или аппаратных средств. С устройства и операционной системы фокус переносится на данные и легкие‑интерфейсы доступа к ним.

Означает ли это, что пользователькие ID мессенджера становятся корневыми? Мессенджер это просто интерфейс. Все и любые приложения это просто интерфейс. И операционная система смартфона или ноутбука тоже интерфейс. К чему же привязывать первичный ID пользователя? Ну, к самому пользователю.

У каждого пользователя скоро появится первичный, корневой ID.

Базовый стандарт W3C Decentralized Identifiers (DIDs) v1.0 был официально принят и опубликован в 2022 году, а в марте 2026 года опубликована версия 1.1 в статусе Candidate Recommendation Snapshot с приглашением к разработчикам тестировать и давать обратную связь. 22 июня 2026 года W3C (World Wide Web консорциум) опубликовал важный документ по модели угроз для децентрализованных удостоверений.

Идея децентрализованной идентификации очень простая — дать пользователям полный контроль над своими личными данными, избавив их от обязательного посредничества, контроля крупных корпораций. Вы должны сами владеть своим цифровым паспортом (ID) и никакая корпорация, будь то Google, Apple, Microsoft, Яндекс или другая, не должна иметь возможность ваш ID заблокировать, отозвать или шпионить за тем, где вы его предъявляете.

Корпоративный сегмент сейчас является одним из главных драйверов и потребителей стандарта W3C DID, рассматривая его не как «анархический Web3 без контроля», а как эффективную замену устаревшим и дорогим корпоративным системам идентификации** (Federated Identity / IAM / PKI).

В следующих статьях, мы об этом подробно поговорим.

Скрытый текст

И о возможностях интеграции протокола Matrix и W3C DID, и гораздо подробнее об Суверенной архитектуре предприятия (Self‑Sovereign Enterprise Architecture), свободной от риска вендор‑лока, а также о Децентрализованном рабочем месте и рабочей среде без границ (Decentralized Virtual Workspace / Boundaryless Enterprise) мы поговорим в следующих статьях.

Обсудим фундаментальные ограничения в парадигме и архитектуре наследников x.500 и телефонных справочников (AD и ее отечественных альтернатив на базе FreeIPA или Samba), а также тупик традиционных MDM/UEM‑платформ и в реальном администрировании корпоративной инфраструктуры. Вообще посмотрим на системы управления идентификацией, доступом, пользователями и устройствами, построенные на иерархических деревьях, помянем SQL, конфликты политик и «комбинаторный ад. Обсудим CQRS, Event Sourcing, и почему графы — будущее (а у кого‑то уже настоящее) этих систем.»

Поговорим про переход от устройство‑центричной (Device‑centric) модели к User‑centric и End‑user computing (EUC), и разберем как децентрализованная идентичность W3C DID (World Wide Web Consortium, Decentralized identifiers) ложится на корпоративную почву.

Обсудим в этом контексте новые возможности для реализации концепции сетевой безопасности ZTNA (Zero Trust Network Access).

Не пройдем мимо VDI, у нас тут тоже локальная и временная противофаза образовалась, у нас взлет, но вообще, у этой индустрии своя «глубокая вечерняя зорька», о чем ярко свидетельствует продажа дуплетом многолетних лидеров индустрии, и Citrix и VMware в 22 и 23 годах.

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

И обязательно в дальнейшем углубимся в вопрос, чем на самом деле является Matrix. Это открытый протокол децентрализованной синхронизации состояний (State Synchronization) в реальном времени, на базе распределенного криптографически защищенного направленого ациклического графа событий (DAG — Directed Acyclic Graph), копия которого хранится на каждом сервере‑участнике.

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

Обсудим возможность создания на базе Matrix не только мессенджеров, но и текстовых редакторов на Markdown c возможностью совместной работы, или, например, интерактивных досок и других решений.

И наконец, попробуем собрать всю это в единую архитектуру, полностью соответствующую TOGAF 10 и SABSA, в терминах которых Matrix выступает в роли технологического блока решения (SBB) и обеспечивает выполнение таких бизнес‑атрибутов SABSA, как «Независимость от поставщиков» (Vendor Independence) и «Эффективное межведомственное взаимодействие» (Seamless Collaboration), за счет своей сквозной открытой архитектуры на уровне всей операционной модели предприятия

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

Фокус на массовый сегмент, чтобы вывести Matrix из тени X.400

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

Кому нужно?

Отказ от строительства закрытых проприетарных экосистем и переход к принципам интероперабельности и открытости архитектур в общем доступен для любого российского вендора корпоративных мессенджеров, ВКС и воркспейсов. Но требует дополнительных затрат на RnD и переработку софта, а главное, смены бизнес‑модели. Есть минимальная вероятность, что кто‑то из существующих вендоров на это пойдет. Скорее всего, сработают эффект колеи (path dependency) и ловушка компетенций (competency trap). Вендоры продолжат рулить прямо в стену.

Скрытый текст

Текущая бизнес‑модель всех российских мессенджеров и ВКС и вообще воркспейсов, включая инфраструктурный слой, строится на капитализации закрытости. Как только вендор переходит на Matrix, его продукт превращается в заменяемый интерфейс. Вендоры продают «огороженные сады», а открытый протокол эти ограды сносит.

Переход на Matrix для условного Яндекса или VK — это не просто «прикрутить плагин». Чтобы переписать условный VK Teams или Яндекс Мессенджер, и далее по списку, под нативную поддержку Matrix‑событий, им нужно остановить разработку новых фич и перенаправить сотни дорогих разработчиков на полную переработку архитектуры.

Максимум, который можно ожидать, что однажды, может быть, поддержат бриджи или Linearized Matrix.

И наконец, психология. За 2022–2025 гг. у вендоров успела сформироваться и окрепнуть ментальность: «рынок горит, клиенты бегут, обещай On‑Premise, быстрее кастомизируй под запрос крупного клиента, пили фичи на коленке, главное — успеть освоить бюджет». В этом состоянии, у них физически нет горизонта планирования дальше, чем на два квартала вперед. Они едут на максимальной скорости, стараясь выжать из внезапного спроса на замещение зарубежных решений все что можно здесь и сейчас. И надеются, что праздник не закончится.

Но строго говоря, это не имеет большого значения. Феномен Too Big to Fail понятен, но работает исключительно внутри конкретного технологического цикла, эпохи. На переходе это не работает. Уahoo, Rambler, кто еще помнит старейший поисковик рунета — Апорт? Nokia продавала около 40% всех мобильных телефонов в мире. Kodak “прошляпила” цифру.

Объективно, главным корпоративным амбассадором Matrix и открытых архитектур могла бы стать ОС «Аврора» (ОМП, Открытая мобильная платформ), она находится в классической ловушке платформы: очень мало пользователей, потому что очень мало приложений, потому что очень мало разработчиков, потому что очень мало пользователей. Ростелеком (владелец ОМП) потенциально может увидеть даже больший интерес в Matrix, чем увидели Orange и Vodafone.

Для МТС «Disrupt через поддержку протокола Matrix» — доступный Сценарий № 3. Если МТС выступит амбассадором протокола Matrix, новых стандартов интероперабельности и открытой архитектуры в России, это будет асимметричным ходом, который переведет МТС из догоняющего игрока, в роль формирующего новые правила игры. Это самый маловероятный сценарий из трех, но у МТС есть реальный шанс развернуть рыночную гравитацию в свою пользу. Вместо того чтобы пытаться построить еще один, но заведомо уступающий по площади Walled Garden, МТС имеет уникальный позицию для лидерства в революции открытых стандартов, разрушении чужих воронок удержания, и главное — избавления российского корпоративного сегмента от серьезных рисков операционной устойчивости, которые формирует вендор‑лок.

Эшелон госкорпораций и первопроходцы импортозамещения заперты в ловушке прошлых затрат. Они будут сидеть в своих «мертвых садах» до последнего, пока TCO и деградация софта не станут невыносимыми. Регулятор мыслит иерархиями и мега‑облаками. Но через пару тройку лет, на фоне всего описанного в статье, на фоне действий коллег из зарубежных стран, сдвиг вполне может произойти.

Финтех‑лидеры, второй и третий эшелон импортозамещения, которым только предстоит перестраивать инфраструктуру, проявят прагматичный интерес значительно раньше. Они не побегут внедрять это завтра в промышленный контур, но вполне могут профинансировать профильные R&D‑лаборатории, войти в НКО или поддержать создание открытых прототипов, чтобы вырастить альтернативный стек для своих B2B‑экосистем. Сделать это можно уже сегодня.

В то время как закрытые офисные платформы упираются в потолок локального рынка (понятно почему и прямо подтверждается заявлением Евгения Касперского об отсутствии экспортного потенциала у «МойОфис»), у рассматриваемой нами открытой децентрализованной архитектуры открываются совсем другие горизонты.

Согласно руководству Всемирного банка GovTech Procurement Practice Note, глобальный технологический тренд направлен на построение сквозных, интероперабельных систем. Решения, построенные на открытых протоколах (как Matrix), изначально соответствуют международным критериям Всемирного банка: они исключают vendor lock‑in, оптимизируют совокупную стоимость владения (TCO) и позволяют бесшовно масштабировать продукт на любые регионы без необходимости годами переписывать закрытый код под требования конкретной страны. Экспортный потенциал здесь заложен на уровне самого архитектурного ДНК.

В России же главный спрос прямо сейчас могут дать малый и средний бизнес, а еще обычные люди. Для них легковесный и элементарный в развертывании local‑first и open‑source стек на базе открытых протоколов, разворачиваемый на копеечном железе или в гибридной среде — единственный способ получить контроль над собственными данными и коммуникациями. Именно здесь софт нового поколения докажет свою экономическую эффективность, пока гиганты «зреют».

Если опираться на Matrix, у нас главный инженерный вызов — преодолеть тень стандарта X.400 из 1980-х.

Тот получился академически идеальным. Как и Matrix, X.400 имел федеративную, децентрализованную архитектуру и не требовал единого центрального сервера. Как и Matrix, предлагал глобальную адресацию, то есть независимость от провайдера. Как и Matrix, он разрабатывался как открытый стандарт, на базе которого любой разработчик мог написать свой клиент или сервер. Наконец, как и Matrix, имел повышенный фокус на безопасности и надежности. Мало того, X.400, как и Matrix поддерживал передачу структурированных данных. Но X.400 получился сложным и тяжеловесным. В итоге мир наплевал на его строгую безопасность и выбрал простой, дырявый, но работающий здесь и сейчас текстовый SMTP.

И это вызов не для международных комитетов, а конкретно для нашего инженерного сообщества. В мире эту революцию начали не корпорации и не регуляторы. И в России ее первыми поддержат архитекторы и разработчики, которые устали от «отрицательного R&D» и готовы включиться в создание Open Core реализаций новой архитектуры рабочих мест на открытых протоколах с фокусом именно на массовый сегмент.