Революция платформ. Как сетевые рынки меняют экономику – и как заставить их работать на вас

Мы утверждаем, что фундаментальная архитектура, лежащая в основе всех платформ, по существу одна и та же: система разделена на набор «ядерных» компонентов с низкой вариативностью и дополнительный набор «периферальных», высоковариативных. Низковариативные компоненты составляют платформу. Это долгоживущие элементы системы, которые таким образом скрыто или явно определяют интерфейс системы и правила, управляющие взаимодействиями между разными участниками[44].

Почему же модулярность эффективна? Потому что, когда системы явно поделены на подсистемы, они могут работать и как целое, объединяясь и взаимодействуя через четко прописанные интерфейсы. Следовательно, подсистемы могут разрабатываться индивидуально, если подчиняются общим стандартам разработки и совместимы с остальной системой с помощью одного стандартного интерфейса. Вы, наверное, встречали термин «программный интерфейс приложений» (Application Programming Interface, API). Это стандартные интерфейсы таких систем, как Google Maps, New York Stock Exchange, Salesforce, Thomson Reuters Eikon, Twitter и многих других, используемые для облегчения доступа внешних участников к корневым ресурсам[45].

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

Рис. 3.1. У Amazon куда больше комплексов API, чем у Walmart. Это единые платежи, онлайн‑торговля, облачные сервисы, сообщения, распределение рабочих задач и др. Пока Walmart оптимизирует логистику, Amazon разрешает третьим сторонам создавать ценности с помощью своих модулярных сервисов. Источник: Эванс и Басоль, с использованием данных ProgrammableWeb[46]. Воспроизводится с разрешения авторов

Возможности модулярности — одна из причин, почему индустрия персональных компьютеров так быстро выросла в 1990‑е. Ключевыми компонентами систем ПК были: центральные процессоры, которые отвечали за вычисления; графические процессоры, которые создавали красочные изображения на экране; оперативная память, обеспечивающая рабочую память; жесткий диск, который обеспечивал большие объемы под долгосрочное хранение данных. Каждая из этих подсистем объединялась с другими, используя четко прописанный интерфейс, который допускал невероятные инновации, по мере того как Intel (CPU), ATI и Nvidia (GPU), Kingston (RAM) и Seagate (HD) независимо работали над улучшением качества своих продуктов.

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

Переработка архитектуры платформы

Проделать фокус с преобразованием архитектуры системы в сторону модулярного дизайна возможно. Первый шаг — анализ степени модулярности, которой система уже достигла. К счастью, есть ряд инструментов, позволяющих достичь этой цели, и ключевой среди них — «матрицы структуры дизайна», которые допускают визуальное исследование зависимостей в сложных системах[49].

В статье 2006 г. в Management Science Алан Маккормак и Карлисс Болдуин описали пример продукта, архитектуру которого успешно преобразовали из интегральной в модулярную[50]. Когда программное обеспечение перешло в публичный доступ как открытый исходный код, коммерческая компания, обладавшая авторскими правами, инвестировала существенные ресурсы в обеспечение перехода. Это было крайне важно, потому что ПО невозможно было поддержать силами разбросанных команд разработчиков, если бы оно не было разделено на более мелкие подсистемы.