Кросс-бизнес-разработка и что о ней нужно знать: основное из опыта команды VK Tech

В сегодняшнем мире технологий связь между архитектурой программного обеспечения и бизнес-моделями стала очень тесной. Для RnD-подразделений крайне важно понимать бизнес-модель и компромиссы, связанные с каждым значительным архитектурным решением. 

При создании продуктов под разные среды исполнения и сегменты рынка обычно есть два пути: делать несколько продуктов из разных реализаций приложений и сервисов или разрабатывать единый продукт, который впоследствии должен учитывать все требуемое многообразие. Второй подход, который называется кросс-бизнес-разработка ПО (Cross-business software development), — это как раз то, чему следует команда VK Tech при разработке своих продуктов.

Меня зовут Александр Бычук. Я Director of Software Engineering в VK Tech. В статье я расскажу, что такое кросс-бизнес-разработка ПО (Cross-business software development), какие преимущества и недостатки она имеет, а также как мы в команде VK Tech реагируем на вызовы кросс-бизнес-разработки.

Начнем с простого примера

Представьте, что вы разрабатываете приложение, которое должно работать и на Windows, и на GNU/Linux. Чтобы приложение имело успех, мы должны понять:

• для кого мы создаем приложение;

• какую пользу/ценность несет приложение;

• как мы будем реализовывать приложение;

• будет ли приложение платным или бесплатным.

Для реализации мы сформируем функциональные и нефункциональные требования, выберем язык разработки и/или фреймворк и приступим…

При выборе языка мы можем прийти к следующим вариантам:

• использовать С++ и пересобирать/изменять код с учетом целевых операционных систем и компиляторов;

• применить более высокоуровневый язык, например Java. В таком случае мы напишем код один раз, а JVM обеспечивает работоспособность на обеих платформах.

Наш выбор повлияет на time-to-market, так как, например, отлаживать C++ код на разных платформах — это дольше, чем на Java. Повлияет на производительность, так как код на C++ в общем случае быстрее, чем на Java (тезис не холивара ради, а для формирования образа размышлений и выводов).

Теперь перенесем эту логику на разработку продуктов в интересах разных бизнес-сегментов по разным бизнес-моделям. 

Бизнес-модель — это набор решений о том, как создавать ценность и для кого. Она включает в себя сегменты клиентов, ценностные предложения, ключевые виды деятельности и источники дохода.

Если вы не знакомы, вот краткое определение основных элементов:

• для кого мы создаем ценность → бизнес-сегмент;

• какую ценность мы создаем → продукт;

• как мы создаем ценность → архитектура производства;

• источники дохода → деньги.

Допустим, что у вас есть крутой продукт, при этом вы хотите покрыть несколько бизнес-сегментов. Это будет выглядеть так, что одни клиенты хотят разворачивать ваш продукт и в публичном, и в приватном облаке, другие требуют коробочную версию. Как избежать разработки разных версий? Как удовлетворить всех клиентов из разных бизнес-сегментов? Ответ — кросс-бизнес-разработка. 

Кросс-бизнес-разработка ПО — подход, который подразумевает создание приложений для потребителей с разными запросами, поведением и паттернами работы. Например, разделение бывает:

• по размеру компании — High Enterprise, Small/Medium Business, Business to Government; 

• по формату поставки — Public SaaS, Private SaaS, Box.

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

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

Чтобы понять, как технически реализуется кросс-бизнес-разработка, можно сделать отсылку к кросс-платформенной разработке. Так, в случае кросс-платформенной разработки с использованием условного C++ алгоритм упрощенно следующий:

1. Пишется кодовая база приложения под определенную операционную систему и компилятор.

2. Код собирается под нужную операционную систему и тестируется.

3. По итогам тестов код чистится, продукт допиливается.

4. Далее полученный код собирается под следующую операционную систему и другой компилятор, после чего также тестируется.

5. По итогам тестов код чистится, продукт допиливается, и так по кругу.

При использовании высокоуровневых языков вроде Java, Python или Go алгоритм несколько проще, поскольку runtime языка сам адаптирует код под конкретные платформы. Но и тут не без нюансов — например, каждая операционная система имеет уникальный API для работы с правами объектов файловой системы и не каждый runtime делает над этим абстракцию.

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

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

Например, при реализации сценариев аутентификации и авторизации для клиентов, использующих только публичное облачное решение, достаточно, например, поддержки OIDC и упрощенной ролевой модели вида «пользователь, администратор и менеджер». Но для поставки в контур заказчика необходимо обогатить функциональность поддержкой WS-Federation и SAML2, а также научить интегрироваться с Active Directory и настраивать доступы не только по RBAC-, но и по ABAC-модели. При этом версии, поставляемые в госсектор, потребуют поддержки отечественной криптографии и выполнения других ИБ-требований. В итоге продукт будет обладать широким спектром возможностей и функциональной гибкостью.

Преимущества кросс-бизнес-разработки

Следование подходу кросс-бизнес-разработки дает ряд стратегических преимуществ.

• Расширение охвата. Способность продукта одинаково стабильно и предсказуемо работать в разных средах исполнения и в разных сценариях позволяет более гибко подстраиваться под текущие запросы пользователей. Разрабатываемый сервис можно сделать доступным для всех бизнес-сегментов.

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

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

• Консолидация ресурсов. Возможность переиспользовать один сервис/продукт для разных бизнес-сегментов позволяет командам разработки, тестирования и других инженеров не делать двойную или тройную работу. Соответственно, можно консолидировать ресурсы и экспертизу.

У подхода есть и недостатки. Выделю основные.

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

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

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

• Повышенные требования к экспертизе. Для создания продукта под пользователей из разных бизнес-сегментов и его последующего администрирования у команды должна быть продвинутая экспертиза с глубоким пониманием всех подводных камней.

VK Tech: кросс-бизнес-разработка облачных сервисов

Мы в VK Tech разрабатываем B2B-продукты для разных сегментов рынка и разных способов эксплуатации: в нашем продуктовом портфеле большой стек инструментов, которые представлены как сервисы в публичном облаке и On-premises-решения. И при разработке своих продуктов мы следуем именно принципу кросс-бизнес-разработки. Из этого следуют две особенности:

1. Независимо от варианта поставки (публичное/приватное облако или коробочное решение) у продукта единое «ядро» кодовой базы.

2. Команда разработки на каждое продуктовое направление у нас одна — мы не выделяем специалистов под каждый конкретный вариант поставки. 

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

• Технический вызов. Например, если продукт в публичном облаке работает на Kubernetes, то в On-premises необходимо, чтобы K8s у заказчика уже был. Если нет — нужно принести свою инфраструктуру с мониторингом, алертингом и полным обвесом сопутствующих сервисов. Соответственно, ко всем компонентам продукта предъявляются дополнительные требования к способам упаковки, конфигурирования и администрирования. И под каждый конкретный кейс, в зависимости от требований к развертыванию, мы должны учитывать свои критерии подготовки сервисов. Но и если Kubernetes есть, необходимо удостовериться, что версия и функциональная наполненность K8s соответствуют нашим требованиям, а иногда это серьезная проблема.

• Процессно-административный вызов. Разработка сервиса для публичного облака зачастую подразумевает типовой цикл действий: «быстрая выкатка — мониторинг — откат — выкатка следующей фичи». То есть основная метрика для нас — time-to-market. При этом любые баги мы можем безопасно и без влияния на пользователей отлавливать и устранять на лету. В случае с On-premises это невозможно, поскольку релиз On-premise-решения — большой проект с длительными этапами планирования и тестирования, практически без возможности быстрого отката. Соответственно, процессы производства для таких продуктов разные. Вместе с тем, как я уже упоминал раньше, команда разработки у нас одна. Поэтому процессы должны быть такими, чтобы ни один из вариантов исполнения не был ущемлен.

Преодоление вызовов кросс-бизнес-разработки

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

Решение технических проблем

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

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

Разработка общих компонентов

Разработка общих компонентов в кросс-платформенной разработке — процесс создания «многоразовых» элементов пользовательского интерфейса и логики приложения, которые могут использоваться на разных платформах (например, iOS, Android, web). 

Следуя этому принципу, при кросс-бизнес-разработке сервисов мы анализируем внутренние потребности, находим пересечения и выделяем общие/пересекающиеся потребности в общие компоненты, библиотеки и сервисы.

Такой подход помогает нам сократить дублирование кода, уменьшить количество ошибок, сократить нагрузку на команду и ускорить разработку новых продуктов.

Технический совет

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

Примечание: Практика организации технических советов есть и в кросс-платформенной разработке. В задачи таких команд, как правило, входит принятие решений о выборе технологий, инструментов, архитектурных решений и стандартов разработки для обеспечения совместимости и эффективности работы продукта на нескольких платформах (например, iOS, Android, web).

InnerSource

Поскольку время, затраченное на поиск решения, — важный показатель, влияющий на time-to-market, нам важно следовать концепции InnerSource. 

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

В контексте кросс-бизнес-разработки мы в VK Tech применяем InnerSource именно как инструмент переиспользования готовых наработок. Такой подход помогает нам:

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

• оптимизировать процессы — InnerSource позволяет минимизировать дублирование усилий по написанию кода, тестов, документации;

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

Решение процессно-административных проблем

Для ответа на процессно-административные вызовы мы также выстроили подход на основе комплекса мер и практик, которые применяем в производственных процессах VK Tech. Приведу некоторые из используемых методов.

Использование CMMI как общего фреймворка

Capability Maturity Model Integration (CMMI) — модель зрелости процессов компании, которая используется для оценки и совершенствования процессов разработки ПО. Она охватывает широкий спектр аспектов, включая управление требованиями, проектирование, тестирование, интеграцию и развертывание. В рамках статьи рассказывать про CMMI не буду, иначе статья получится слишком большой. 

В нашем случае применение CMMI служит для стандартизации и оптимизации производственных процессов, а именно:

• предоставляет четкую структуру для управления всеми этапами жизненного цикла разработки;

• помогает минимизировать риски и улучшать предсказуемость результатов;

• позволяет своевременно выявлять и устранять проблемы.

Но главное — CMMI формирует понимание зрелости текущих процессов и целей для достижения следующего уровня.

Таким образом, применение CMMI позволяет создать устойчивую основу для успешной кросс-бизнес-разработки облачных B2B-сервисов.

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

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

Благодаря следованию практике управления обещаниями:

• все участники проекта знают, какие задачи перед ними стоят и какие результаты ожидаются;

• четко устанавливаются зоны ответственности всех специалистов;

• в случае возникновения непредвиденных обстоятельств легче оперативно реагировать и корректировать планы, снижая возможные негативные последствия;

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

В результате управление обещаниями помогает команде VK Tech синхронизировать действия команды при разработке инсталляций облачных сервисов под разные варианты их развертывания.

From Cloud to On-Prem Adoption

Создание сервисов под публичное облако подразумевает простой и быстрый релизный цикл. Это позволяет нам оперативно выпускать нужные решения, тестировать их с привлечением реальных пользователей и быстро дорабатывать сервисы с учетом обратной связи. В условиях On-premise-инсталляций это усложнено: таких клиентов меньше, степень доступа к их ИТ-ландшафту ниже, а специфических особенностей в пользовательских сценариях больше. 

Поэтому, чтобы снизить порог входа в разработку сервисов под On-premises, мы следуем концепции From Cloud to On-prem Adoption. Она предполагает, что мы сначала готовим сервис для публичного использования (Public SaaS), а только потом делаем реализацию под частное облако или коробочное решение. При этом технические требования к сервисам таковы, что если сервис им соответствует, то «приземление» будет дешевым либо бесплатным.

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

Вместе с тем надо отметить, что циклы наших релизов выстроены таким образом, что задержки между выкаткой новых фич в публичные сервисы и в On-premise-инсталляции минимизированы. Клиенты VK Tech регулярно информируются о порядке получения новых возможностей продукта в каждом бизнес-сегменте.

Что в итоге

Надеюсь, что сравнение кросс-бизнес-разработки и кросс-платформенной разработки помогло мне рассказать об опыте VK Tech. 

Кросс-бизнес-разработка — это решение не для всех. Очевидно, что не каждый производитель программного обеспечения хочет или может выпускать продукты в интересах разных клиентов: кому-то достаточно облачного B2C-сервиса, кому-то — standalone-приложения по подписке. Кросс-бизнес-разработка — это решение для вендоров ПО с широким портфелем продуктов.

Вместе с тем опыт команды VK Tech наглядно показывает, что профит, получаемый от кросс-бизнес-разработки сервисов, с лихвой оправдывает затраченные ресурсы.