Заметки теоретика. Откуда растут платформы: «Снизу» vs «Сверху» — архитектура выбора

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

Платформы не возникают случайно — их создание всегда связано с осознанным выбором организационной стратегии. Два принципиально разных подхода — «снизу» и «сверху» — определяют не только техническую реализацию, но и культуру взаимодействия внутри компании. Разберём их ключевые отличия.

Первый подход «Снизу»: Органическая эволюция

Платформа формируется как ответ на повторяющиеся потребности разработчиков. Инициатива исходит от инженерных команд, которые сталкиваются с дублированием функционала в разных проектах. Это как грибы после дождя. Разработчики устали копировать код для авторизации, логирования и мониторинга в каждом новом проекте. Решили: «Давайте сделаем общую библиотеку!». Постепенно эти сервисы объединяются в платформу.

Этапы реализации:

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

2. Создание базовых сервисов: Разработка универсальных инструментов (логирование, API-шлюзы).

3. Интеграция в экосистему: Сервисы объединяются в единую платформу через общие стандарты.

4. Итеративное развитие: Платформа дополняется новыми функциями по запросам команд.

Организационные особенности:

• Горизонтальная коммуникация: Команды напрямую согласуют требования к платформе.

• Децентрализованное управление: Ответственность распределена между всеми участниками.

• Фокус на agility: Быстрые эксперименты и адаптация под текущие задачи.

Например, GitHub начался как инструмент для контроля версий, а стал платформой для всего цикла разработки.

В итоге мы имеем: 

✅Естественная эволюция — решаются реальные боли команды.

✅Меньше сопротивления — сами разработчики заинтересованы.

❌Риск «лоскутного одеяла» — сервисы могут быть несогласованными.

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

Второй подход «Сверху»: Стратегическое проектировани

Здесь у нас противоположность — Платформа создаётся как часть корпоративной стратегии. Решение принимается руководством, которое выделяет ресурсы и формирует дорожную карту.

Этапы реализации:

1. Определение целей: Например, ускорить вывод продуктов на рынок.

2. Архитектурный дизайн: Разработка единой схемы сервисов и API.

3. Создание выделенной команды: Наём или перераспределение сотрудников под задачи платформы.

4. Постепенное внедрение: Миграция проектов на новую инфраструктуру.

Организационные особенности:

• Вертикальное управление: Требования спускаются от архитекторов к разработчикам.

• Централизованный контроль: Все изменения в платформе согласуются через governance-процессы.

• Фокус на стабильность: Приоритет — надёжность и соответствие стандартам.

Как пример, Salesforce — изначально задумывался как облачная платформа для CRM, и это было стратегическим решением.

В результате:

✅Чёткая дорожная карта — все знают, куда идти.

✅Ресурсы и поддержка — не нужно выпрашивать серверы.

❌Риск «платформы ради платформы» — решение может не отвечать реальным нуждам и Разработчики воспринимают платформу как навязанное решение

❌Долгий старт — Долгий цикл согласований тормозит внедрение новых функций, пока всё согласуют, рынок уже ушёл вперёд.

Для простоты восприятия опишем сравнение в виде таблицы с критериями выбора подхода 

Как итог сравнения могу предложить направления в которых стоит рассматривать тот или иной подход:

• «Снизу»:

  • Стартапы или компании с Agile-культурой.

  • Проекты, где скорость важнее перфекционизма.

  • Ситуации, когда нет чёткого видения конечной цели.

• «Сверху»:

  • Крупные предприятия с compliance-требованиями (банки, госсектор).

  • Долгосрочные инициативы (цифровая трансформация).

  • Организации, где критична стандартизация процессов.

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

• Пилотные проекты: Разрешить командам экспериментировать с модулями платформы.

• Обратная связь: Регулярно собирать фидбэк от разработчиков для корректировки roadmap.

• Гибридные команды: Создать cross-functional группы из архитекторов и инженеров продукта.

Поэтому итоговое решение должно приниматься с учётом специфики вашей конкретной ситуации.

Mini fact: Название Apache появилось как шутка. Первая версия веб-сервера собиралась из «заплаток» (patches) к коду NCSA HTTPd. Разработчики называли его A PAtCHy Server, что позже сократилось до Apache. К племени апачей это не имеет отношения.