Эта новость, в целом, не новость - многие вендоры купили сервисные компании: история Google и Mandiant, Microsoft и RiskIQ, Palo Alto Networks и Crypsis. В целом, это развитие отмеченного ранее тренда на то, что специализирующиеся на ИБ компании были куплены ИТ-шными - IBM и ISS, BT и Counterpane.
Но я следил за Red Canary, так как их бизнес-модель близка тому, к чему я лично причастен в текущей позиции, поэтому и решил в очередной раз посотрясать воздух на тему зачем вендору приобретать сервисные компании.
1. Операционная история. Чем более современные и эффективные решения хочет выпускать вендор, тем по факту эти решения сложнее. Чтобы заставить сложные решения работать эффективно нужны эффективные и результативные процессы вокруг - операционная история. Не имея у себя штатного подразделения, работающего на своих же решениях, построить такие решения хорошо невозможно - никакие списки клиентских требований и квадранты\волны аналитических агенств здесь не помогут! Нужна своя практическая информация из первых рук, причем обратная связь от собственного операционного подразделения должна обрабатываться в приоритете. А если операционное подразделение постепенно обрастает собственной автоматизацией - это значимый повод задуматься над роудмапом своего продукта, может, на практике оно не пригодно к использованию...
2. Комплексное решение "под ключ". Картина, что мы сделали продукт, и кто-то его абсолютно правильно использует - идеальна. Я упоминал, что "принцип Алана Кея" работает и в случае поставщиков решений, поэтому, никто не будет давать лучший результат, чем вендор со своей правильной операционной командой. Это несложно для понимания, поэтому среди CISO, ориентированных на результат, решение "под ключ" популярно, так как оно, собственно, ориентировано на конечный результат, и за него есть единая точка ответственности - поставщик решения. Ну действительно, зачем покупать лопаты и воспитывать своих землекопов, когда можно сразу нанять землекопов с лопатами, и вопрос совместимости землекопов и лопат пропадет как класс и не будет моей самой большой головной болью.
3. Открытие дверей для поставщика, и оценка качества для потребителя. Сервисы типа Security Assessment и Compromise Assessment - позволяют объективно оценить эффективность используемых механизмов ИБ. Для вендора - это способ начала диалога о поставке своих решений, а для потребителя - возможность получения независимой (наверно, когда вендор свои решения оценивает с помощью своих сервисов - не самый лучший сценарий) оценки. Ну и опять же, наличие таких сервисов в портфеле позволяет постоянно повышать качество: синие решения должны ловить свои красные команды, а красные - должны уметь обходить свои синие решения - и где-то в перспективе эти кошки-мышки сходятся в ничью.
4. Выход на новые рынки. Если клиентские базы не пересекалась (это, кстати, может быть значимым аргументом при оценке M&A), то результирующая компания получит объединение клиентских баз.
5. Инвестиции в стратегию. Чем более комплексное решение мы предлагаем, тем шире наш взгляд на рынок, тем совершеннее наша стратегия. Стратегия принципиально важна для выживания в конкурентной среде, обеспечивает долгое и уверенное существование бизнеса. Ну а еще - это и диверсификация бизнеса: затруднения в одном направлении можно будет смягчить успехами в другом.
В общем, на мой взгляд, одни плюсы. Но вопрос, как всегда, в деталях и конкретных людях. В сервисной компании сервис был core business, соответственно, потребности delivery-команды выполнялись с максимальным приоритетом. Попав в огромного производителя, сервисная команда должна будет состязаться за ресурсы автоматизации с продуктовыми роудмапами. Маржинальность сервисов - ничтожна по сравнению с продуктами, так как сервис - это всегда униальная работа людей, а продукт, написанный однажды, можно потом продать 100500 раз. Поэтому, исходя из прибыли на инвестицию сервис всегда будет проигрывать, и с точки зрения примитивной оценки на основе максимальной прибыли, не получать должного внимания, как следствие - развития, т.е. стагнировать, загибаться и умирать. Сервисные предложения делаются людьми и значительно более динамичны, так как, заказчик в большинстве случаев готов подождать новую фичу в течение нескольких релизов (а пока этой фичи нет, продукт может обладать некоторой "несовременностью"), в случае сервиса результат всегда должен быть максимально адекватен ситуации ("современен"), а для этой современности сервисного предложения также нужна разработка, в случае отставания которой, сервис сразу теряет конкурентноспособность. Неконкурентноспособный сервис, скажем проще, "плохой" сервис, не несет всех описанных выше преимуществ, а в ряде случае, напротив, негативно отражается и на продуктах. Получается не очень очевидная связка: если мы приобретем современный сервис, то это даст новые возможности для развития наших продуктов, особенно, если мы максимально сынтегрируем сервисы и продукты в единое решение. Однако, если мы не будем выделять ресурсы на развитие сервиса, он очень быстро потеряет конкурентноспособность (устареет, протухнет, он, в отличие от продукта, быстропортящийся) и утянет за собой продукты, тем быстрее, чем глубже наша интеграция продуктов и сервисов.
Но ситуация еще хуже, так как в современных условиях какие-то продукты вовсе невозможно развивать без наличия связанных сервисов, и драйвер здесь все та же потребность в комплексном решении... но об этом, как-нибудь, в другой раз.
